[dns-operations] DNS prefetching, DLV and cheap NAT router state table overflow

Peter Dambier peter at peter-dambier.de
Wed Sep 22 10:47:11 UTC 2010

It smells like dnsmasq.

I suspected my ISP to block port 53 udp.

I have actually seen 53 udp blocked but tcp working with dig.
tracepath from inside and outside pointed to my WRT54G running
dd-wrt v23 SP2.

When you router has a shell like ssh or telnet, try

>> ps -elf | grep dnsmasq <<

to see the dnsmasq commandline. Most likely you will have to try

>> ps <<

kill dnsmasq with its process id and start it again like

>> dnsmasq -p 3001 #your old commanline <<


>> dnsmasq --port=3001 #your old commanline <<

to see if the trouble goes away.

Now your router should be transparent on port 53 and you can
still see dnsmasq from your pc with

>> dig -p 3001 ... <<

I don't like dnsmasq in the first place but I still need it
for dhcp for my neighbors.

Kind regards

Florian Weimer wrote:
> I've noticed that some time after switching on my home workstation and
> doing a bit web browsing, DNS resolution ceases to work for a minute
> or two.  Unbound (which runs locally and starts from a cold cache)
> shows a growing request list during that time.  Many of the requests
> are triggered by DNS prefetching, and cause subsequent DLV, A, AAAA
> and NS requests which are related to Unbound's hardening features and
> only indirectly caused by client queries.  When the phenomenon occurs,
> "dig" does not work, either, with or without DNSSEC, both from the
> workstation and other machines behind the same NAT router.  The DNS
> proxy on the NAT router ceases to work, too.
> I suspect that this might be caused by state table overflow in the
> cheap NAT box (an AVM Fritzbox 7390, which is supposed to forward
> non-proxied DNS requests unmolested).  Existing UDP flows continue to
> work fine.  I have yet to see if switching of source port
> randomization improves things.
> Has anybody else seen this behavior?  It is a bit difficult to
> attribute it to the NAT router because it's a black box for me right
> now.  It could also be some sort of DoS or enumeration protection in a
> transparent DNS proxy at the ISP (1&1 reselling VDSL from Deutsche
> Telekom).
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter at peter-dambier.de
ULA= fd80:4ce1:c66a::/48

More information about the dns-operations mailing list