Created attachment 1137836 [details] dig_bugzilla_ipv6.pcap Description of problem: Hello, it seems that the DNS resolv in Fedora 23 would not switch to TCP if resolv over UDP not available. I have detected the issue with DNS over ipv6, but not sure how much it affects ivp4 - could be the same. This manifests as being able to use "nslookup bugzilla.redhat.com" and "dig bugzilla.redhat.com", while not being able to run commands like "ping bugzilla.redhat.com" and "wget https://bugzilla.redhat.com". Version-Release number of selected component (if applicable): How reproducible: - special conditions are needed - the DNS server should not give the response over UDP and force clients to get it over TCP - this happened today with Google public DNS on 2001:4860:4860::8844, that's how I encounter this issue Steps to Reproduce: 1. try "dig bugzilla.redhat.com" - this works because dig/host/nslookup tools if unsuccessful over UDP, will switch to TCP and try the same request over TCP - see attached pcap dig_bugzilla_ipv6.pcap which was captured while doing the "dig" command 2. try "ping bugzilla.redhat.com" - this doesn't work, because after unsuccessful response over UDP, system resolv will not try the same request over TCP - see attached pcap ping_bugzilla_ipv6.pcap which was captured while doing the "ping" command $ ping bugzilla.redhat.com ping: unknown host bugzilla.redhat.com Expected results: I would expect that if it is possible to resolv the DNS name over nslookup, dig, host commands, then it should be also possible to resolve it with the other commands and utilities as well. Additional info: $ cat /etc/resolv.conf # Generated by NetworkManager nameserver 2001:4860:4860::8844 nameserver 2001:4860:4860::8888 nameserver 8.8.8.8 $ nslookup bugzilla.redhat.com Server: 2001:4860:4860::8844 Address: 2001:4860:4860::8844#53 Non-authoritative answer: Name: bugzilla.redhat.com Address: 209.132.183.69 $ dig bugzilla.redhat.com ; <<>> DiG 9.10.3-P4-RedHat-9.10.3-12.P4.fc23 <<>> bugzilla.redhat.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64652 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;bugzilla.redhat.com. IN A ;; ANSWER SECTION: bugzilla.redhat.com. 299 IN A 209.132.183.69 ;; Query time: 48 msec ;; SERVER: 2001:4860:4860::8844#53(2001:4860:4860::8844) ;; WHEN: Fri Mar 18 13:02:21 UTC 2016 ;; MSG SIZE rcvd: 58 $ wget http://cepteknik.org/XXXXXXXXXXXXXXX --2016-03-18 13:02:11-- http://cepteknik.org/XXXXXXXXXXXXXXX Resolving cepteknik.org (cepteknik.org)... failed: No address associated with hostname. wget: unable to resolve host address ‘cepteknik.org’ Workaround: Workaround was to disable the "#nameserver 2001:4860:4860::8844" in the /etc/resolv.conf and switch to server which was giving the answers on both UDP and TCP (for example "8.8.8.8") I believe Google was testing some additional security features of the public DNS infrastructure (possibly something like mitigation of UDP flood by switching to TCP) on ipv6 clients. Best regards Michal Ambroz
Created attachment 1137837 [details] ping_bugzilla_ipv6.pcap pcap captured when trying "ping bugzilla.redhat.com"
The response has the TC bit set (requesting retry with TCP), but it lacks the RA bit, indicating that the server is not willing to perform recursion. This means that the glibc stub resolver will not use it. I asked on the dns-operations list for comments, but the message is currently stuck in the moderation queue.
The mailing list thread is here: https://lists.dns-oarc.net/pipermail/dns-operations/2016-March/014548.html
BTW the mentioned Google DNS behaviour was gone today cca 16:00 GMT. Now the ipv6 Google DNS (2001:4860:4860::8844) is responding again over UDP. Mik
This is arguably not a bug because the RFC clearly says that RA must be correct even for a TC response. But I understand that DNS has evolved from the original specification, so I have filed and upstream bug to come up with some enhancements in this area (although there is no quick fix). Google treats this as an operational issue for their public DNS service and is working on a modification to their servers: https://lists.dns-oarc.net/pipermail/dns-operations/2016-March/014551.html