Description of problem: My home LAN worked fine with a number of hard-coded IPs for some of the hosts using a simple config in dnsmasq-2.80-10.fc31.x86_64. All LAN machines could resolve both each other in their own domain, and the outside world. Upgrading to dnsmasq-2.80-12.fc31.x86_64 broke this for the LAN's own domain -- no internal addresses resolve, but the outside world is still visible. The config in question, which worked OK before, has the following for /etc/dnsmasq.conf: no-resolv no-hosts conf-dir=/etc/dnsmasq.d The DNS config starts from /etc/dnsmasq.d/dns.conf : domain=my-lan-domain.tld local=/tld/ no-resolv server=(upstream 1 ip) server=(upstream 2 ip) addn-hosts=/etc/dnsmasq.d/dns/hosts-list expand-hosts proxy-dnssec and /etc/dnsmasq.d/dns/hosts-list is a straightforward ip/host name list: 192.168.0.1 gateway.my-lan-domain.tld. 192.168.0.2 server.my-lan-domain.tld. etc. (This wouldn't be the first time dnsmasq has silently gone and invalidated otherwise-working configs...) Version-Release number of selected component (if applicable): dnsmasq-2.80-12.fc31.x86_64 How reproducible: Always.
After updating to dnsmasq-2.80-12.fc31.x86_64 my server stopped resolving local addresses. A "Dig {valid internet URL}" responds with a message containing a valid question section and an answer section containing an address A "Dig {bogus local name} " responds with a message containing a valid question section and a Authority Section lookup error A "Dig {valid local name} " responds with a message containing a valid question section and a blank area, contains no answer section or authority section information Reverting to dnsmasq-2.80-10.fc31.x86_64 restores proper operation. Problem was 100% repeatable until previous version was restored.
WORKAROUND: I've just discovered that adding the lines auth-server=<my lan domain> auth-zone=<my lan domain> to the config seems to make things work. This should not be considered resolution of this bug, however. This change should not be necessary. dnsmasq should never silently break existing working configs like this. (And yes, this sometimes means accepting stuff which may be technically 'incorrect'.)
In my case I did add a "domain=lan" entry in my config file. However, all host names are captured from the dhcp server address assignment. All names are captured during the ipv4 DHCP address lease request. Info comes from the "hostname" of the system requesting the address. eg.."bilbo,frodo,merri...." No modifications to the dnf.conf file were made. Behaviour is strictly related to dnsmasq package version.
I have a similar issue with libvirt machines. dnsmasq-2.80-12.fc31.x86 stopped resolving any virtual machine hostname configured via dhcp reverting to dnsmasq-2.80-10.fc31.x86_64 fixes the problem without any other changes.
I'm experiencing the exact same issue w/ version dnsmasq-2.80-12.fc31.x86_64, no internal addresses resolve. Should be pretty easy to replicate. The last entry in changelog is: - Respond to any local name also withou rd bit set (#1647464) With refers to this bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=1647464 and this commit: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=29ae3083981ea82f535f77ea54bbd538f1224a9e
I am having the same issue of not resolving my local domain for FQDN requests after upgrading to dnsmasq-2.80-12.fc31.x86_64. I used the WORKAROUND from James Ettle and it worked. Wanted to confirm the workaround for others that are having the same issue. As James stated, this is NOT a resolution, it is a workaround. I can only hope that this is fixed ASAP.
Oh, it seems I made a mistake when modifying that patch for 2.80.
FEDORA-2020-b6287eafe3 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b6287eafe3
*** Bug 1815256 has been marked as a duplicate of this bug. ***
*** Bug 1814968 has been marked as a duplicate of this bug. ***
FEDORA-2020-b21d576a15 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-b21d576a15
I am sorry guys, the error was inside my latest patch. It affected just 2.80-12 build and similar on 2.80-13 in rawhide. I will have to improve my testing it seems. I tried it first on my own libvirtd, but have not found this issue. Might be related to missing update hook in libvirtd, which does not restart dnsmaq started by libvirt, even after package upgrade. I have tried it against it, but that instance was still running the old code. I am sorry for that.
*** Bug 1814404 has been marked as a duplicate of this bug. ***
FEDORA-2020-d85dcb2efc has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-d85dcb2efc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d85dcb2efc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-b21d576a15 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-b21d576a15` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b21d576a15 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-b6287eafe3 has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-b6287eafe3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b6287eafe3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Confirm fixed in dnsmasq-2.80-13.fc31.x86_64 with the auth-server and auth-zone options removed.
(In reply to James Ettle from comment #18) > Confirm fixed in dnsmasq-2.80-13.fc31.x86_64 with the auth-server and > auth-zone options removed. Thank you for verification. Please increase karma on bodhi update if you tested that build, it would move faster into stable branch.
FEDORA-2020-b21d576a15 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 1815014 has been marked as a duplicate of this bug. ***
FEDORA-2020-d85dcb2efc has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-b6287eafe3 has been pushed to the Fedora 30 stable repository. If problem still persists, please make note of it in this bug report.