<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
The problem is that we don't know what names&nbsp;users are going to try and resolve via their custom nameservers.&nbsp; We just&nbsp;provide a way for them to tell us what their&nbsp;nameservers are.&nbsp; We put their nameservers at the top of the reolve file.&nbsp; By using the strict ordering we hit their&nbsp;nameservers first.<BR>
&nbsp;<BR>
Agree that using all nameservers&nbsp;for those requests isn't&nbsp;appropriate.&nbsp; The strict ordering gets around that.&nbsp; If dnsmasq acted the same way when receiving requests via loopback as it did for anything else then the problem would be solved.&nbsp; When receiving via loopback dnsmasq acts the same - i.e. it tries the first&nbsp;DNS, waits 10 seconds, retries the first DNS.&nbsp; I tested with ping, traceroute, tracepath, and nslookup.&nbsp; All of them cause the same behavior from dnsmasq accepting via loopback.<BR>
&nbsp;<BR>
I am going to try and figure out what is going in&nbsp;in the dnsmasq code.<BR>&nbsp;<BR>
<HR id=stopSpelling>
Date: Fri, 27 Mar 2009 13:56:55 -0500<BR>Subject: Re: [Dnsmasq-discuss] Strange behavior when making the nameserver machine use dnsmasq<BR><BR><BR>Can't you use<BR><BR>server=/<A href="http://internal.mycompany.com/135.54.66.254">internal.mycompany.com/135.54.66.254</A><BR><BR>to deal with those?<BR><BR><BR>Using all nameservers isn't appropriate for those requests anyway.<BR><BR><BR><BR>
<DIV class=EC_gmail_quote>2009/3/27 Zack Little <SPAN dir=ltr>&lt;<A href="mailto:zacklitt@hotmail.com">zacklitt@hotmail.com</A>&gt;</SPAN><BR>
<BLOCKQUOTE class=EC_gmail_quote style="PADDING-LEFT: 1ex">
<DIV>No worries about the shouting.&nbsp; I&nbsp;appreciate you answering so quickly.&nbsp; <BR>&nbsp;<BR>I don't think the scenario you&nbsp;described is going to work for me.&nbsp;&nbsp;Let me explain.&nbsp; In the test&nbsp;I just ran I had three nameservers: 165.87.13.129, 165.87.194.244, 135.54.66.254.<BR><BR>The 165's are Internet&nbsp;servers and 135 is only accessible via a tunnel from the device dnsmasq is running on.<BR>&nbsp;<BR>I removed the strict order arg and sent a ping&nbsp;to Google from behind the device.&nbsp; As you described dnsmasq "ran the race" and sent the request immediately to all three&nbsp;nameservers.&nbsp; A response was received from 165.87.13.129 just barely before one from 135.54.66.254 was received.<BR>&nbsp;<BR>The next time&nbsp;I pinged Google (caching is off)&nbsp;the request was only sent to 165.87.13.129&nbsp;(as expected).<BR>&nbsp;<BR>The problem&nbsp;is when I try to resolve names that only 135.54.66.254&nbsp;can resolve.&nbsp; When I ping one of those names again only 165.87.13.129&nbsp;is used.&nbsp; 165.87.13.129&nbsp;doesn't know about the name so the lookup fails.&nbsp;&nbsp;dnsmasq won't "run the race" again because 165.87.13.129&nbsp;is responding and therefore the query isn't&nbsp;timing out. &nbsp;135.54.66.254&nbsp;is never used and therefore I can no longer resolve&nbsp;names only 135.54.66.254&nbsp;knows about.
<DIV class=EC_im><BR>&nbsp;<BR><BR>&gt; No, but it provides me with a perfect opportunity for a public service <BR>&gt; announcement, since this information needs to go to a wider audience.<BR>&gt; <BR>&gt; Sorry about the shouting;<BR>&gt; <BR>&gt; DON'T USE --STRICT-ORDER<BR>&gt; <BR>&gt; Strict-order almost never does what people expect/want it to do, which <BR>&gt; is to put a priority order on the list of servers in /etc/resolv.conf. <BR>&gt; It mainly just disrupts dnsmasq's mechanism for dealing with broken or <BR>&gt; down servers. If I could, I'd remove it. If there is ever dnsmasq-3, it <BR>&gt; will go.<BR>&gt; <BR>&gt; <BR>&gt; If you remove --strict order, then dnsmasq will send the first query, in <BR>&gt; parallel, top all the name servers. It will note that first one which <BR>&gt; provides a good answer, and use just that until a query times-out, when <BR>&gt; it will "run the race" over all the servers again.<BR>&gt; <BR>&gt; BTW My guess is that the behaviour difference you are seeing in how the <BR>&gt; queries are handled is because the repeated query from 127.0.0.1 doesn't <BR>&gt; have the same transaction-id as teh first query, so dnsmasq doesn't <BR>&gt; recognise it as a retry.<BR>&gt; <BR>&gt; <BR>&gt; Cheers,<BR>&gt; <BR>&gt; Simon.<BR>&gt; <BR>&gt; <BR><BR>
<HR>
</DIV>
<DIV class=EC_im>Windows Live™ SkyDrive: Get 25 GB of free online storage. <A href="http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_skydrive_032009">Check it out.</A></DIV></DIV><BR>_______________________________________________<BR>Dnsmasq-discuss mailing list<BR><A href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk">Dnsmasq-discuss@lists.thekelleys.org.uk</A><BR><A href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</A><BR><BR></BLOCKQUOTE></DIV><BR><br /><hr />Quick access to Windows Live and your favorite MSN content with <a href='http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B037MSN55C0701A' target='_new'>Internet Explorer 8.</a></body>
</html>