Mar 27, 2026 - For details about updated CVE-2025-53521 (BIG-IP APM vulnerability), refer to K000156741.

Forum Discussion

OATI_Network_S1's avatar
OATI_Network_S1
Icon for Nimbostratus rankNimbostratus
May 15, 2026

Functionality questions regarding commands that we're using in a DNS_REQUEST related iRule

I opened a ticket w/F5 regarding this but they recommended I try DevCentral instead, so here we are :)

 

We're currently in the process of creating and testing an iRule/configuration in a test environment with the intent of eventually applying it to the listeners in our F5 DNS/GTM production environment that will forward DNS requests made to our production F5 DNS/GTM environment with only specific criteria to a separate Windows DNS server to answer back through our production F5 DNS/GTM environment.

 

What we have so far which appears to be working:

 

when DNS_REQUEST {

# Check if the query is for a TXT record and matches a specific FQDN

if { ([DNS::question type] equals "TXT") and ([string tolower [DNS::question name]] contains "_acme-challenge") } {

# Forward to a specific pool of DNS servers

DNS::disable dns-express

snat automap

translate address enable

pool /Common/dns_fwdtxttest_pool

}

}

 

In order for us to get it to work we had to add the following commands to the iRule that we found online:

DNS::disable dns-express

snat automap

translate address enable

 

In both our test and production F5 DNS/GTM environments we:

-Do use dns-express

-Have source address translation set to none on our listeners

-Have address translation disabled on our listeners

 

My questions are in regard to how those 3 commands may/may not affect other requests/traffic made to our production F5 DNS/GTM environment NOT being processed by the iRule when it gets triggered during and post completion.

 

Will the features/settings affected by those commands only apply to the request/traffic that triggers and is processed by the iRule, or all traffic?

 

Will the features/settings affected by those commands automatically revert back to how they are currently set/functioning prior to implementation in our production F5 DNS/GTM environment (DNS Express - enabled, source address translation - none, address translation - disabled) again once the iRule completes processing the triggered request/traffic, or do they need to be toggled back manually at the end of the iRule in some way again as well?

 

We're just trying to make sure we have all our bases covered and are accounting for as much as we can before going live with it and potentially running into other unexpected issues with production requests/traffic upon implementation.

 

All that being said - is there anything else that we may be missing/overlooking?

 

Anyone out there have any thoughts/suggestions/guidance at all?

 

Thanks in advance and hope all is well!

1 Reply

  • ReganAnderson's avatar
    ReganAnderson
    Icon for Employee rankEmployee
    May 16, 2026

    Hi OATI_Network_S1​,

    Each virtual server connection starts with the settings as they are defined on the virtual server / listener. An iRule may modify the characteristics of the connection (ex. enabling SNAT, disabling dns-express, etc.) and when that is done, those changes remain for the rest of the connection or until the iRule modifies the characteristics again.

    In the context of DNS, you're usually looking at one DNS request / connection over UDP. So, the iRule you have would work for UDP-based DNS requests as each request is a new connection and will start with your default configuration.

    Where your iRule logic may not be sufficient is for DNS over TCP, as you may see a single TCP connection handle multiple DNS requests. In this case, if a TCP connection is opened to your DNS listener, and the first request matches your TXT condition, the virtual server characteristics for that connection would be modified as per your logic. If a second DNS request came in over that same TCP connection, say an A record request, it would not match the logic in your condition but the virtual server connection would still be operating under the modified state from the first request and that modified state would apply to this request too.

    To handle this scenario, all you need to do is add an else condition that sets the virtual server back to its defaults if the request doesn't match the ACME condition. It would look something like this:

    when DNS_REQUEST {
    # Check if the query is for a TXT record and matches a specific FQDN
    if { ([DNS::question type] equals "TXT") and ([string tolower [DNS::question name]] contains "_acme-challenge") } {
        # Forward to a specific pool of DNS servers
        DNS::disable dns-express
        snat automap
        translate address enable
        pool /Common/dns_pool
    } else {
        # Not ACME request, reset connection parameters
        DNS::enable dns-express
        translate address disable
        snat none
    } 
}