[dns-operations] DNS NAT Translation Timeouts

Brian Dickson briand at ca.afilias.info
Thu Jul 31 00:01:55 UTC 2008

Ondřej Surý wrote:
> Hi,
> somebody correct me if I am wrong.
> If you have cache-only -> forwarder situation, you can stay with one
> source port for all queries
> and add TSIG between these two (and more) servers.  That way you can
> redirect the load to servers,
> where you can scale better.  (But of course it depends on your setup...)

Or one can observe:

The firewall in this case, will only block *incorrect* guesses to the 
"birthday" problem for
poisoning the cache.

It will, by definition, *allow* correct guesses, and thus, is not really 
adding any value.

Since the server is already on a DMZ, you may as well just bite the 
bullet, and drop a link
to the "outside the firewall" switch, add appropriate interface IP(s) 
and IPv6(s), and be done
with it.

Yes, it will give security guys conniptions,  but that is what DMZs are 
*for*. If the firewall
can't do blind forwarding of UDP with no state, it deserves to be 


> 2008/7/30 Jon Kibler <Jon.Kibler at aset.com>:
>> Hash: SHA1
>> All,
>> I have a couple of sites where we have upgraded caching-only servers
>> that forward all of their requests to external name servers. These
>> servers sit behind a NAT firewall in a DMZ. The firewalls have also been
>> patched for DNS and port randomization issues.
>> Problem: The firewalls have a default NAT translation timeout of 60
>> seconds. This results in HUGE translation tables, with thousands (if not
>> tens of thousands) of stale entries. These huge tables are apparently
>> starting to impact performance. (About 90% of all translation table
>> entries are for DNS.) I should add that the NAT translations remain in
>> the table even after the firewall has removed the ACL allowing return
>> traffic.

More information about the dns-operations mailing list