I have been having a similar sounding bug on one of my routers. It uses DHCP for the outside IP. The DNS does not resolve from the router itself (ie, from routers cli I "dig dailydata.net" and get a null return).
I changed the DNS server to 8.8.8.8 (to keep from using the providers DNS), rebooted (to hopefully clear any cache and restart dnsmasq), and have the same issue. However, doing "dig @8.8.8.8 dailydata.net" returns a valid result and, after that, I can resolve other sites.
This is low priority for me since I set the client machines (Windoze workstations) to 8.8.8.8 via the internal DHCP and they work fine. When I go to do the update, however, I have the one additional step of doing a "dig @8.8.8.8" first, then I can do pakfire upgrade/update.
If anyone can tell me something to do to try and track it down, I will be happy to do it. At the least, I guess I can follow the forum topic and see if I get similar results.
Rod
On 10/21/2014 08:11 AM, Michael Tremer wrote:
Hello fellow dnsmasq users,
there is a topic on the IPFire support forums I would like to point you to:
http://forum.ipfire.org/index.php?topic=11726.0
It appears that dnsmasq cannot verify resource records of a DNSSEC-enabled domain. That domain uses RSA/SHA1-NSEC3-SHA1 for its signatures. Although there is some code in dnsmasq that is supposed to handle this, it does not verify the records correctly.
Did anyone else experience this problem? Is it a bug with dnsmasq or the authoritative name servers of that domain?
Best, -Michael
Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development