After upgrading our forwarding DNS server to Fedora 11, we started getting a lot of name lookup failures. At the time of a failure, there seem to be a lot of error messages of this form: Jun 22 15:29:37 guru named[18178]: chase DS servers resolving 'mcnabbs.org/DS/IN': 128.187.80.20#53 Jun 22 15:29:37 guru named[18178]: not insecure resolving 'org/NS/IN': 128.187.80.20#53 Jun 22 15:29:37 guru named[18178]: not insecure resolving 'mcnabbs.org/A/IN': 67.207.145.27#53 The clients worked fine just a few days ago with a Fedora 10 DNS server with the same configuration. Is there any information I can provide that would be helpful?
There have also been errors of the following form in the logs: Jun 22 15:29:00 guru named[18178]: network unreachable resolving 'mcnabbs.org/DS/IN': 2001:500:f::1#53 Jun 22 15:29:00 guru named[18178]: network unreachable resolving 'mcnabbs.org/DS/IN': 2001:500:40::1#53
One last type of message I'm seeing a lot of is: Jun 22 17:40:59 guru named[19560]: success resolving 'mail.mcnabbs.org/A' (in 'mcnabbs.org'?) after reducing the advertised EDNS UDP packet size to 512 octets Jun 22 17:40:59 guru named[19560]: success resolving 'mail.mcnabbs.org/AAAA' (in 'mcnabbs.org'?) after reducing the advertised EDNS UDP packet size to 512 octets I also noticed that after adding -4 to the options for named, name resolution seems to be working.
DNSSEC validation has been enabled by default in F11 and it might cause that lookups take more time. Would it be possible to try set `DNSSEC=off` in /etc/sysconfig/dnssec and check if it "solves" the problem, please? Also please try this: run `dig @<your_server_ip> <name_which_often_fails> +dnssec` and check how long query takes in both cases - enabled and disabled DNSSEC validation. Make sure you run `rndc flush` command right before dig command to flush server's cache.
Since IPv6 is disabled, I'll have to reenable it to recreate the problem. I should be able to get to this tomorrow, but I'll need to warn a few users.
I don't see a problem on the mcnabbs.org domain. It resolves fine with DNSSEC and DLV enabled for me.
Oh, also make sure you have tcp port 53 open and not firewalled. DNSSEC can cause replies to require TCP uinstead of UDP.
There is a firewall upstream of the DNS server, but it is set to allow all outgoing connections and any established inbound connections through. Are any unusual firewall settings necessary for DNSSSEC?
Adam, I tried enabling/disabling dnssec and restarting the name server. With dnssec enabled, dig reported the query time as 4956 ms. With dnssec disabled, the query time was 1060 ms. I tried restarting a number of times (to clear the cache), and the results seemed pretty consistent: about 1 second without dnssec, and 5 to 6 seconds with dnssec.
Since comment #8, I've run this more times, and the times are actually pretty inconsistent. I even had one as long as 14 seconds (this one with DNSSEC disabled).
Make sure your firewall allows for DNS packets of larger size (say 4096) than most default (512). DNSSEC increases packet size, many firewalls will block these UDP packets, cause delay, and force failing back to TCP.
Jason, sorry for taking so long to respond to this. There are unfortunately several firewalls between the DNS server and the outside world. Do you happen to know whether iptables limits DNS packet size by default? I've tried googling for information and haven't found anything useful. If I'm sure it's not the iptables firewall, then I can report the packet loss further up the chain. Thanks for your help.
I don't believe iptables has a default limit for packet size. But Cisco's default and other protocol-inspecting firewalls often limit to 512. Here is a resource to test your firewall to see what size it is allowing: https://www.dns-oarc.net/oarc/services/replysizetest
Thank you very much for that tip. It looks like we have a campus-wide firewall that's dropping packets, so I'll see if we can get them to fix it. In the meantime, I think I'll try setting edns-udp-size as a workaround.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.