[Dnsmasq-discuss] Strange behavior when making the nameserver machine use dnsmasq

[Zack Little]

The problem is that we don't know what names users are going to try and resolve via their custom nameservers.  We just provide a way for them to tell us what their nameservers are.  We put their nameservers at the top of the reolve file.  By using the strict ordering we hit their nameservers first.

 

Agree that using all nameservers for those requests isn't appropriate.  The strict ordering gets around that.  If dnsmasq acted the same way when receiving requests via loopback as it did for anything else then the problem would be solved.  When receiving via loopback dnsmasq acts the same - i.e. it tries the first DNS, waits 10 seconds, retries the first DNS.  I tested with ping, traceroute, tracepath, and nslookup.  All of them cause the same behavior from dnsmasq accepting via loopback.

 

I am going to try and figure out what is going in in the dnsmasq code.
 


Date: Fri, 27 Mar 2009 13:56:55 -0500
Subject: Re: [Dnsmasq-discuss] Strange behavior when making the nameserver machine use dnsmasq


Can't you use

server=/internal.mycompany.com/135.54.66.254

to deal with those?


Using all nameservers isn't appropriate for those requests anyway.




2009/3/27 Zack Little <zacklitt at hotmail.com>


No worries about the shouting.  I appreciate you answering so quickly.  
 
I don't think the scenario you described is going to work for me.  Let me explain.  In the test I just ran I had three nameservers: 165.87.13.129, 165.87.194.244, 135.54.66.254.

The 165's are Internet servers and 135 is only accessible via a tunnel from the device dnsmasq is running on.
 
I removed the strict order arg and sent a ping to Google from behind the device.  As you described dnsmasq "ran the race" and sent the request immediately to all three nameservers.  A response was received from 165.87.13.129 just barely before one from 135.54.66.254 was received.
 
The next time I pinged Google (caching is off) the request was only sent to 165.87.13.129 (as expected).
 
The problem is when I try to resolve names that only 135.54.66.254 can resolve.  When I ping one of those names again only 165.87.13.129 is used.  165.87.13.129 doesn't know about the name so the lookup fails.  dnsmasq won't "run the race" again because 165.87.13.129 is responding and therefore the query isn't timing out.  135.54.66.254 is never used and therefore I can no longer resolve names only 135.54.66.254 knows about.

 

> No, but it provides me with a perfect opportunity for a public service 
> announcement, since this information needs to go to a wider audience.
> 
> Sorry about the shouting;
> 
> DON'T USE --STRICT-ORDER
> 
> Strict-order almost never does what people expect/want it to do, which 
> is to put a priority order on the list of servers in /etc/resolv.conf. 
> It mainly just disrupts dnsmasq's mechanism for dealing with broken or 
> down servers. If I could, I'd remove it. If there is ever dnsmasq-3, it 
> will go.
> 
> 
> If you remove --strict order, then dnsmasq will send the first query, in 
> parallel, top all the name servers. It will note that first one which 
> provides a good answer, and use just that until a query times-out, when 
> it will "run the race" over all the servers again.
> 
> BTW My guess is that the behaviour difference you are seeing in how the 
> queries are handled is because the repeated query from 127.0.0.1 doesn't 
> have the same transaction-id as teh first query, so dnsmasq doesn't 
> recognise it as a retry.
> 
> 
> Cheers,
> 
> Simon.
> 
> 




Windows Live™ SkyDrive: Get 25 GB of free online storage. Check it out.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss at lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



_________________________________________________________________
Quick access to Windows Live and your favorite MSN content with Internet Explorer 8.
http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B037MSN55C0701A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090327/522da686/attachment-0001.htm