<div dir="ltr">If it doesn't work when started at boot, but does if you started it manually, the most likely reason is that the boot scripts are passing command-line options such as a different config file.  If you edited the default config file, when you start dnsmasq by hand, that's the one it finds.<div><br></div><div>The command line arguments of the auto-launched dnsmasq instance should give further information (the 'ps' command should show the command lines of running processes)<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 6, 2017 at 1:07 PM, Anoop Ravi <span dir="ltr"><<a href="mailto:anoopravik@gmail.com" target="_blank">anoopravik@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That seems to be correct. That may be the reason why it is working<br>
when i give dhcp-option 6.<br>
<br>
Do you have any guess what could be going wrong? Is there any flag<br>
which I need to enable to make dnsmasq work as dns server as well?<br>
<br>
I have seen a strage behavior as well. Resolution wont work on bootup.<br>
But when I restart dnsmasq(killing PID and starting commandline) it<br>
works. Do you have any clue?<br>
<br>
Any help is much appreciated.<br>
<br>
Thanks,<br>
Anoop<br>
<div class="HOEnZb"><div class="h5"><br>
On 8/6/17, <a href="mailto:richardvoigt@gmail.com">richardvoigt@gmail.com</a> <<a href="mailto:richardvoigt@gmail.com">richardvoigt@gmail.com</a>> wrote:<br>
> One clear difference is that the query that succeeded is for a different<br>
> name than the one that failed.<br>
><br>
> But the bigger problem is that the reply is somehow going straight to the<br>
> client.  When dnsmasq is acting as a caching proxy, these steps happen:<br>
><br>
> 1. the client sends a query to dnsmasq<br>
> 2. dnsmasq checks its cache and doesn't find a match<br>
> 3. dnsmasq sends a query to the upstream server<br>
> 4. the upstream server sends a reply to dnsmasq<br>
> 5. dnsmasq adds the information to its cache<br>
> 6. dnsmasq sends a reply to the client<br>
><br>
> In your capture, #4 isn't happening -- the reply destination address is<br>
> wrong.<br>
><br>
><br>
><br>
> On Sun, Aug 6, 2017 at 12:47 PM, Anoop Ravi <<a href="mailto:anoopravik@gmail.com">anoopravik@gmail.com</a>> wrote:<br>
><br>
>> Hi Richard,<br>
>><br>
>> I dont want to use dhcp-option 6 to override nameservers. I took a<br>
>> packet capture on both local lan interface and the interface which<br>
>> talks to outside world. I could see that in both scenarios (working<br>
>> and nonworking), names are getting resolved at the outer interface.<br>
>> But somehow query is getting refused at the local interface. Do you<br>
>> have any clue why this is happening?<br>
>><br>
>> Attaching screenshot of comparison on local interface packet capture.<br>
>><br>
>> Thanks,<br>
>> Anoop<br>
>><br>
><br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Anoop.<br>
</font></span></blockquote></div><br></div></div></div>