Description of problem: My provider forced me to change modem to Motorola Netopia 7640-47 ADSL Modem, and DNS resolving stopped working. It seems to be a variation of the A vs. AAAA record problem, maybe it is a duplicate, but I am not sure. And I have a feeling that the error is not completely on the modem side, however. Version-Release number of selected component (if applicable): Fedora 16 (testing), glibc-2.14.90-11 How reproducible: Always, firefox works only with network.dns.disableIPv6 set to true, other application works only with servers that have valid AAAA record. Additional info: $ getent ahosts bugzilla.redhat.com NO RESULT! running "#tcpdump -nn port 53" during this command gives tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 22:19:48.682393 IP 192.168.1.38.39395 > 192.168.1.1.53: 57390+ A? bugzilla.redhat.com. (37) 22:19:48.682437 IP 192.168.1.38.39395 > 192.168.1.1.53: 53968+ AAAA? bugzilla.redhat.com. (37) 22:19:48.805076 IP 192.168.1.1.53 > 192.168.1.38.39395: 57390 1/0/0 A 209.132.183.69 (53) 22:19:48.807040 IP 192.168.1.1.53 > 192.168.1.38.39395: 53968- 0/0/0 (37) Observe that the modem answers both queries: returns the A address and does not provide any AAAA address. ======================================== for comparison the same with www.fedoraproject.org, which seems to have an ipv6 address getent ahosts www.fedoraproject.org 213.175.193.206 STREAM wildcard.fedoraproject.org 213.175.193.206 DGRAM 213.175.193.206 RAW 66.35.62.166 STREAM 66.35.62.166 DGRAM 66.35.62.166 RAW 85.236.55.6 STREAM 85.236.55.6 DGRAM 85.236.55.6 RAW 140.211.169.197 STREAM 140.211.169.197 DGRAM 140.211.169.197 RAW 152.19.134.146 STREAM 152.19.134.146 DGRAM 152.19.134.146 RAW 209.132.181.16 STREAM 209.132.181.16 DGRAM 209.132.181.16 RAW 2610:28:3090:3001:dead:beef:cafe:fed4 STREAM 2610:28:3090:3001:dead:beef:cafe:fed4 DGRAM 2610:28:3090:3001:dead:beef:cafe:fed4 RAW and the tcpdump looks like tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 22:22:39.217576 IP 192.168.1.38.42268 > 192.168.1.1.53: 65364+ A? www.fedoraproject.org. (39) 22:22:39.217620 IP 192.168.1.38.42268 > 192.168.1.1.53: 6945+ AAAA? www.fedoraproject.org. (39) 22:22:39.277858 IP 192.168.1.1.53 > 192.168.1.38.42268: 65364 7/0/0 CNAME wildcard.fedoraproject.org., A 213.175.193.206, A 66.35.62.166, A 85.236.55.6, A 140.211.169.197, A 152.19.134.146, A 209.132.181.16 (158) 22:22:39.424452 IP 192.168.1.1.53 > 192.168.1.38.42268: 6945 2/0/0 CNAME wildcard.fedoraproject.org., AAAA 2610:28:3090:3001:dead:beef:cafe:fed4 (90)
$ dig @192.168.1.1 aaaa bugzilla.redhat.com
(In reply to comment #1) > $ dig @192.168.1.1 aaaa bugzilla.redhat.com ; <<>> DiG 9.8.1-RedHat-9.8.1-2.fc16 <<>> @192.168.1.1 aaaa bugzilla.redhat.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63318 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;bugzilla.redhat.com. IN AAAA ;; Query time: 17 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Oct 14 21:08:35 2011 ;; MSG SIZE rcvd: 37 For comparison, the same dig through VPN where everything works. $ dig aaaa bugzilla.redhat.com ; <<>> DiG 9.8.1-RedHat-9.8.1-2.fc16 <<>> aaaa bugzilla.redhat.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10388 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;bugzilla.redhat.com. IN AAAA ;; AUTHORITY SECTION: redhat.com. 600 IN SOA ns1.redhat.com. noc.redhat.com. 2011101000 3600 1800 604800 86400 ;; Query time: 131 msec ;; SERVER: 129.132.98.12#53(129.132.98.12) ;; WHEN: Fri Oct 14 21:17:58 2011 ;; MSG SIZE rcvd: 81 By the way, going through the glibc bugs again, it looks very much like duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=602396. The records of DNS packets in comments 1 and 4 look exactly the same as here, and comment 5 is as here when I try through VPN.
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 ***