NimbostratusAny time you use an iRule (over just built-in functionality), things will process more slowly, hence the need to make iRule code as efficient as possible. Here are a couple of observations:
Your iRule sets a lot of variables that it doesn't seem to need, since it never references these variables after setting them. These include ldns, gtm_ecs_source, and gtm_ecs_scope (unless they're used by another iRule on the same connection, which I suspect they're not since you're providing the query response in this iRule). If you don't need them, don't set them. It might also mean you really don't even need gtm_ecs_address as you can use [DNS::edns0 subnet address] on the CLASS MATCH command instead. Setting and referencing variables in an iRule causes overhead.
Also, I can't tell for sure but from your specs it looks like you are using a data group for what appears to be just three different IP address ranges (whatever a.a.a.a, b.b.b.b, and c.c.c.c are). If only three or so possibilities to check against, a compound IF statement will probably run faster. You could using timing statistics or, if v13.1, the new Rule Profiler to make that determination.
Having said all that, in BIG-IP v14.0, you can do this without an iRule (with a wide IP and topology load balancing, for example). For more information, see Eric Chen's article here: Using Client Subnet in DNS Requests
