Hide Forgot
Description of problem: Fedora is currently unable to use the recursive resolvers from Turk Telekom. Many lookups just result in "Name or service not known". Other resolvers like "host", "dig" and the resolver in Windows 7 (haven't tried other versions of Windows) work just fine. Version-Release number of selected component (if applicable): glibc-2.13-1.x86_64 How reproducible: Always (but see below). Steps to Reproduce: 1. telnet www.slashdot.org http Actual results: telnet: www.slashdot.org: Name or service not known www.slashdot.org: Host name lookup failure Expected results: Trying 216.34.181.48... Connected to www.slashdot.org. Escape character is '^]'. Additional info: I've been doing a lot of digging, and the problem seems to be related to the contents of the resolver response. The weird thing about these resolvers is that they will not include an authority section (except when there's a cache miss, which makes things work now and then). The lack of an authority section doesn't seem to be the key issue though, as other lookups work fine. What is key though is that lookups that only return a single A record in the response. If there are CNAME:s or multiple A records, then glibc gladly accepts the response. It would therefore seem it has something to do with the size of the response. A poorly implemented sanity check perhaps? One thing confusing this though is that domains that have AAAA records seem to work. The strange thing here is that glibc sends out two requests, one for A and one for AAAA. The A response is a short one, just like the ones that won't work. But the AAAA response coming just after it has something in it (unlike the broken stuff), and that for some reason makes glibc cope with both records. Some internal merging before validation? I'm just here for this week, so if you want further testing you'll have to request it in the coming days.
I've also verified several times that pointing my machine towards another recursive resolver fixes things. My resolver at home (via VPN): ~ [drzeus@mjolnir]$ dig www.slashdot.org ; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> www.slashdot.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50199 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;www.slashdot.org. IN A ;; ANSWER SECTION: www.slashdot.org. 3591 IN A 216.34.181.48 ;; AUTHORITY SECTION: slashdot.org. 84842 IN NS ns-1.ch3.sourceforge.com. slashdot.org. 84842 IN NS ns-2.ch3.sourceforge.com. slashdot.org. 84842 IN NS ns-1.sourceforge.com. ;; ADDITIONAL SECTION: ns-1.ch3.sourceforge.com. 2042 IN A 216.34.181.21 ns-1.sourceforge.com. 2042 IN A 208.122.22.23 ns-2.ch3.sourceforge.com. 2042 IN A 216.34.181.22 ;; Query time: 127 msec ;; SERVER: 10.8.0.1#53(10.8.0.1) ;; WHEN: Sun Feb 13 11:13:13 2011 ;; MSG SIZE rcvd: 174 The Turk Telekom resolver: ~ [drzeus@mjolnir]$ dig www.slashdot.org @195.175.39.39 ; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> www.slashdot.org @195.175.39.39 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23993 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.slashdot.org. IN A ;; ANSWER SECTION: www.slashdot.org. 2490 IN A 216.34.181.48 ;; Query time: 17 msec ;; SERVER: 195.175.39.39#53(195.175.39.39) ;; WHEN: Sun Feb 13 11:13:31 2011 ;; MSG SIZE rcvd: 50
~ [drzeus@mjolnir]$ dig version.bind chaos txt @195.175.39.39 ; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> version.bind chaos txt @195.175.39.39 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1101 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 0 CH TXT "9.6-ESV-R3" ;; AUTHORITY SECTION: version.bind. 0 CH NS version.bind. ;; Query time: 19 msec ;; SERVER: 195.175.39.39#53(195.175.39.39) ;; WHEN: Sun Feb 13 11:18:48 2011 ;; MSG SIZE rcvd: 67
Created attachment 478447 [details] Packet trace
More confusion. We tried using Google's DNS instead (8.8.8.8). That gives the same kind of short replies that Turk Telekom's is doing. But the problems do not appear there. The only obvious difference is the lack of the RA flag from Turk Telekom's servers. Seems a bit stupid to omit that as it is quite clearly a recursive lookup. Perhaps that's what's triggering something?
Can't reproduce. $ dig www.slashdot.org @195.175.39.39 ; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> www.slashdot.org @195.175.39.39 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42925 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;www.slashdot.org. IN A ;; ANSWER SECTION: www.slashdot.org. 3600 IN A 216.34.181.48 ;; AUTHORITY SECTION: slashdot.org. 10246 IN NS ns-2.ch3.sourceforge.com. slashdot.org. 10246 IN NS ns-1.ch3.sourceforge.com. slashdot.org. 10246 IN NS ns-1.sourceforge.com. ;; ADDITIONAL SECTION: ns-1.ch3.sourceforge.com. 1546 IN A 216.34.181.21 ns-1.sourceforge.com. 1546 IN A 208.122.22.23 ns-2.ch3.sourceforge.com. 1546 IN A 216.34.181.22 ;; Query time: 219 msec ;; SERVER: 195.175.39.39#53(195.175.39.39) ;; WHEN: Mon Feb 14 13:24:22 2011 ;; MSG SIZE rcvd: 174
Did you try multiple times? It seems there are several machines hiding behind that IP (5 from what I can tell). I can reproduce it here today from Turkey, as well as from a server in Sweden. Not seeing it from a machine in Boston though... Odd :/
A nameserver that does not allow recursion is not usable at all.
It allows recursion, it just doesn't set that bit in the reply. And since Windows handles these replies just fine, I don't think the whole high horse routine is going to fly. As long as Linux is a niche player we sometimes need to be bug for bug compatible with redmond.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** This bug has been marked as a duplicate of bug 505505 ***