On Jun 3, 2013, at 3:58 PM, Stephane Bortzmeyer <[email protected]> wrote:
> Some instances of Google Public DNS cannot resolve ripe.net : > > % dig @8.8.8.8 MX ripe.net > > ; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 MX ripe.net > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6005 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;ripe.net. IN MX > > ;; Query time: 3343 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Mon Jun 3 15:57:00 2013 > ;; MSG SIZE rcvd: 26 > > But some can: > > % dig @8.8.8.8 MX ripe.net > > ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @8.8.8.8 MX ripe.net > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55124 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 512 > ;; QUESTION SECTION: > ;ripe.net. IN MX > > ;; ANSWER SECTION: > ripe.net. 252 IN MX 250 postlady.ripe.net. > ripe.net. 252 IN MX 200 postgirl.ripe.net. > ripe.net. 252 IN RRSIG MX 5 2 300 20130703100234 > 20130603090234 61825 ripe.net. > LA+iNlYx/wJPljhvQNQFVL1LisMjDnlNVVFoH/780HYcEIKFaJ5Wm4eD > C9FPJQKfX14ZD2T9i7R3qGx6GvFaKqSXhLtWlH4NGM/T4UYhl61L25FL > S6qiHDu20tJe4u2/xmmLuqBicj3kCmDuAk0j1Vc851/edBtqR+Kx1LXt HHM= > > ;; Query time: 7 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Mon Jun 3 15:57:18 2013 > ;; MSG SIZE rcvd: 255 > > Since Google Public DNS has apparently no NSID or version.bind, > besides traceroute, what are the tricks to find the extent of the problem? The problem is not google. You're testing from two different locations: the different DiG versions show this. I guess the first instance is running from a network in some conference room in Amsterdam. Reason 1: we are in the same conference room :-) Reason 2: a traceroute from my shell account shows the exact same path. Your queries have been capture by the local hotel network to maximise user experience :-) To be complete, I've just tested all the instances of google public DNS' unicast resolver source addresses (for a list see: https://developers.google.com/speed/public-dns/faq ) from outside the hotel network and all return with the same, correct, data. Hope this helps. Roy > > For the offending instance: > > % traceroute 8.8.8.8 > traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets > 1 192.168.48.1 (192.168.48.1) 0.972 ms 0.938 ms 1.858 ms > 2 87.213.29.57 (87.213.29.57) 4.524 ms 4.516 ms 4.495 ms > 3 ge-2-0-0-1334.ncr01asd2.versatel.net (217.16.40.97) 4.475 ms 4.456 ms > 4.455 ms > 4 xe-2-2-0-672.br04sara.versatel.net (212.53.22.82) 39.255 ms 39.279 ms > 39.248 ms > 5 core1.ams.net.google.com (195.69.144.247) 4.330 ms 4.321 ms 4.309 ms > 6 209.85.248.118 (209.85.248.118) 5.070 ms 2.973 ms 3.758 ms > 7 209.85.255.60 (209.85.255.60) 4.019 ms 209.85.255.72 (209.85.255.72) > 5.081 ms 5.081 ms > 8 216.239.49.30 (216.239.49.30) 33.150 ms 216.239.49.36 (216.239.49.36) > 7.485 ms 8.902 ms > 9 * * * > 10 google-public-dns-a.google.com (8.8.8.8) 8.725 ms 8.775 ms 8.689 ms > _______________________________________________ > dns-operations mailing list > [email protected] > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
