<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div class="gmail_quote"><div>Hi,</div><br><div>I'm using dnsmasq 2.85 on an Ubi Edgerouter, with DHCP hosts setup in dnsmasq.d. This is an ipv4 only setup. Here's an example of one of the hosts:</div><br><div> dhcp-host=<MAC>,set:LAN,192.168.122.2       </div><div> host-record=tv.home.lan,192.168.122.2,3600 </div><br><div>Here is a snippet of dnsmasq.conf, where <a href="1.1.1.1" title="1.1.1.1">1.1.1.1</a> is a public DNS server:</div><br><div>interface=eth4</div><div>cache-size=1000</div><div>server=1.1.1.1</div><div>no-resolv</div><br><div>My Ubuntu client sends both an A and an AAAA DNS query for tv.home.lan when I say ping it. If the router has internet connectivity and can access 1.1.1.1, everything works great and I am able to successfully resolve the device over LAN. I get a standard query response for A with <a href="192.168.122.2" title="192.168.122.2">192.168.122.2</a> and an expected blank standard query response for AAAA (no error).</div><br><div>Unfortunately, if my internet is down and I can't access 1.1.1.1, what happens is that I get a regular response for A but I get a "refused" standard query response for AAAA. That "refused" response causes programs like ping to hang if I say ping tv.home.lan as it keeps trying repeatedly to get a successful AAAA response from the server.  I have to use ping -4 to force only the A request to get it to ping successfully. I think dnsmasq refuses me because it's unable to resolve the ipv6 request on LAN (as the hosts are ipv4 only) but there is no upstream server for it to pass the request along.</div><br><div>My current workaround is to set "local=/lan/" to force dnsmasq to ignore the upstream servers entirely when responding to requests for .lan domains. In this case if <a href="1.1.1.1" title="1.1.1.1">1.1.1.1</a> is unavailable I get an IP address for the A request and a blank standard query response for AAAA, which is what I expect.</div><br><div>All of the requests and responses above were confirmed with Wireshark. I don't expect any patches for 2.85 and am unsure if this is fixed in future versions, but I would like to know if this is intended behavior or if there is a better workaround.</div><br><div>Thanks!</div></div>