[Dnsmasq-discuss] Solution: failed DNS queries succeed on retry

Grant grant_nospam@dodo.com.au
Wed, 26 Jan 2005 21:20:25 +1100


Hi there,

Replying to my own post to add more info re: iptables and UDP 
'connections' -- iptables connection tracking.

On Mon, 24 Jan 2005 11:04:03 +1100, I wrote:

[snip]
>What was happening?  Iptables default settings remember a single 
>outgoing UDP event for only 30 seconds, the setting is here:
>
>  /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
>
>Therefore my old firewall settings saw DNS query replies delayed 
>by more than 30 seconds as unwanted 'NEW' connection attempts and 
>dropped them.
>
>The DNS query succeeds on retry as the nameservers already hold the 
>cached response, thus responding much faster to the retry query.
>
>Now I'm back to my ISP's two nameservers and the system is working 
>fine.
[snip]

Except that now there's a new twist. ;)

Been wondering for the last couple days why my firewall no longer 
reports any delayed nameserver replies.  Weather?  Holiday?

(A very warm Australia Day in Bendigo, Victoria, BTW)

The answer lies in returning to use only the two ISP provided DNS 
addresses.

Why?  The test I'm using is to open a set of pages in a tabbed 
web browser high graphic content (one page loads about 80 items).

Result is a stream of DNS requests to the nameservers.  Now that the 
dnsmasq query-port is fixed, this UDP stream traffic is recognised 
by iptables and given a much longer timeout, default is 180 seconds,
view here :

  /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream


Observe this behaviour by running something like:

while [ 1 ]; do grep udp /proc/net/ip_conntrack|grep -v 192.168.1.31; sleep 1; done

(The second grep only removes windows box NS lookups --> dnsmasq box).

So there's my latest story matching the observations.

Corrections or related information welcomed.

Cheers,
Grant.