SDN/SDDC Retreat in Miami, Florida (November 4th-6th)
Separate SDN hype from real life!

NAT-translated DNS responses are not cacheable

Slightly reworded on 2008-12-18. Not only is NAT (as implemented in Cisco IOS) very picky about the translation of IP addresses in the payload of DNS responses (it translates only addresses defined in IP-level NAT translations with no additional route-map filters), it also sets the TTL field in the DNS response to zero when translating an IP address in the DNS response payload based on an existing L3 NAT entry making the DNS response completely uncacheable.

The behavior makes some sense, as the L3 NAT entry might change before the DNS response expires, but the implementation is definitely overly aggressive. In my opinion, IOS should use some sensible (configurable?) value for static NAT translations and times comparable to NAT timeouts for dynamic NAT translations. What do you think?


  1. which IOS did you use exactly in your tests?

  2. Overloaded interfaces are working just fine for me.
    Dec 17 13:01:30.641: Answer section:
    Dec 17 13:01:30.641: Name=''
    Dec 17 13:01:30.641: RR type=1, class=1, ttl=7191, data length=4
    Dec 17 13:01:30.641: IP=

  3. @Xavier: 12.4(19) and 12.4(15)T(3 or 5?). Is there a recent fix to this part of the code?

    @Shopik: Would you be willing to send me more details? This is interesting.

  4. maybe you need

    no ip nat service dns-reset-ttl


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.