Re: [dns-operations] most of root NS and com's NS fail from here
On 29 April 2014 03:43, Ken Peng kp...@terra.com wrote: I am from China, ISP telecom. Can you tell what happens? More than likely traffic was blocked/filtered by the Chinese firewall. Take a packet capture and see what happens when you do a single query, do you get a response at all, do you get any TCP reset packets? Also post the full dig output. Steve ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] most of root NS and com's NS fail from here
On 2014-04-28 19:43, Ken Peng wrote: Recent days I found most of the root nameservers, and com/net's nameservers can't work from here. When accessing to them I always got timeout. Beyond what the others said, IPv4 or v6? I vaguely recall some global routing problems on IPv6 with at least a couple root server... This might complicate matters. However, BIND (and others) should mostly keep track of which servers do and don't respond and tune appropriately. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] most of root NS and com's NS fail from here
于 2014-4-29 12:21, David Conrad 写道: Ken, On Apr 28, 2014, at 7:43 PM, Ken Peng kp...@terra.com wrote: Recent days I found most of the root nameservers, and com/net's nameservers can't work from here. When accessing to them I always got timeout. If you're querying from inside China, probably the first thing you should check is to see if the root server IP addresses you're querying match the following list (a-m): a.root-servers.net. - 198.41.0.4 b.root-servers.net. - 192.228.79.201 c.root-servers.net. - 192.33.4.12 d.root-servers.net. - 199.7.91.13 e.root-servers.net. - 192.203.230.10 f.root-servers.net. - 192.5.5.241 g.root-servers.net. - 192.112.36.4 h.root-servers.net. - 128.63.2.53 i.root-servers.net. - 192.36.148.17 j.root-servers.net. - 192.58.128.30 k.root-servers.net. - 193.0.14.129 l.root-servers.net. - 199.7.83.42 m.root-servers.net. - 202.12.27.33 I checked them, all seem correct. a.root-servers.net. 579835 IN A 198.41.0.4 b.root-servers.net. 579834 IN A 192.228.79.201 c.root-servers.net. 579843 IN A 192.33.4.12 d.root-servers.net. 579837 IN A 199.7.91.13 e.root-servers.net. 172815 IN A 192.203.230.10 f.root-servers.net. 579597 IN A 192.5.5.241 g.root-servers.net. 579591 IN A 192.112.36.4 h.root-servers.net. 579578 IN A 128.63.2.53 i.root-servers.net. 579587 IN A 192.36.148.17 j.root-servers.net. 579591 IN A 192.58.128.30 k.root-servers.net. 579599 IN A 193.0.14.129 l.root-servers.net. 172762 IN A 199.7.83.42 m.root-servers.net. 579603 IN A 202.12.27.33 and a.root-servers.net. - 2001:503:ba3e::2:30 b.root-servers.net. - c.root-servers.net. - 2001:500:2::c d.root-servers.net. - 2001:500:2d::d e.root-servers.net. - f.root-servers.net. - 2001:500:2f::f g.root-servers.net. - h.root-servers.net. - 2001:500:1::803f:235 i.root-servers.net. - 2001:7fe::53 j.root-servers.net. - 2001:503:c27::2:30 k.root-servers.net. - 2001:7fd::1 l.root-servers.net. - 2001:500:3::42 m.root-servers.net. - 2001:dc3::35 You then might want to do a traceroute to those IP addresses and see if it looks like they're going towards the right places (a little complicated given anycast routing, but if they all stay within China, you might be a bit suspicious). You then might want to try pinging those IP addresses to see the loss/latency stats. This is the traceroute info for one of the failed nameservers. $ traceroute h.root-servers.net traceroute to h.root-servers.net (128.63.2.53), 30 hops max, 60 byte packets 1 113.108.228.129 (113.108.228.129) 0.404 ms 0.886 ms 1.064 ms 2 121.14.46.93 (121.14.46.93) 0.475 ms 0.941 ms 1.227 ms 3 121.14.37.33 (121.14.37.33) 6.604 ms 6.958 ms 7.168 ms 4 121.14.37.6 (121.14.37.6) 0.369 ms 0.377 ms 0.393 ms 5 121.14.50.13 (121.14.50.13) 1.569 ms 1.615 ms 1.694 ms 6 113.108.208.97 (113.108.208.97) 4.362 ms 3.704 ms 3.624 ms 7 (202.97.34.202) 2.973 ms 2.976 ms 2.972 ms 8 202.97.61.234 (202.97.61.234) 1.429 ms 1.421 ms 1.297 ms 9 202.97.52.154 (202.97.52.154) 161.854 ms 161.380 ms 161.363 ms 10 202.97.49.158 (202.97.49.158) 157.784 ms 157.338 ms 157.326 ms 11 218.30.54.198 (218.30.54.198) 255.352 ms 255.432 ms 255.425 ms 12 los-edge-05.inet.qwest.net (67.14.22.130) 251.492 ms los-edge-05.inet.qwest.net (67.14.22.106) 256.656 ms los-edge-05.inet.qwest.net (67.14.22.130) 251.350 ms 13 65-126-18-214.dia.static.qwest.net (65.126.18.214) 360.808 ms 360.171 ms 360.426 ms 14 143.56.244.2 (143.56.244.2) 258.023 ms 254.128 ms 254.172 ms 15 ap-1-1-1-nd.level3-lax.core.dren.net (140.6.244.1) 249.144 ms 248.882 ms 249.567 ms 16 np-5-1-1-nd.sandiego.core.dren.net (140.6.0.1) 359.050 ms 358.964 ms 359.087 ms 17 138.18.190.89 (138.18.190.89) 349.903 ms 349.947 ms 349.974 ms 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * The ping info: $ ping -c 3 h.root-servers.net PING h.root-servers.net (128.63.2.53) 56(84) bytes of data. 64 bytes from 128.63.2.53: icmp_seq=1 ttl=45 time=355 ms 64 bytes from 128.63.2.53: icmp_seq=2 ttl=45 time=356 ms 64 bytes from 128.63.2.53: icmp_seq=3 ttl=45 time=257 ms --- h.root-servers.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 21549ms rtt min/avg/max/mdev = 257.609/323.121/356.333/46.325 ms Thanks! I am from China, ISP telecom. Can you tell what happens? Probably not definitively without more information... Regards, -drc ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] most of root NS and com's NS fail from here
于 2014-4-29 17:27, Dave Warren 写道: Beyond what the others said, IPv4 or v6? I vaguely recall some global routing problems on IPv6 with at least a couple root server... This might complicate matters. All our servers don't have IPv6 configured. So the queries were going with v4. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] most of root NS and com's NS fail from here
Emmanuel, On Apr 29, 2014, at 3:05 AM, Emmanuel Thierry m...@sekil.fr wrote: If i'm not mistaken, the Chinese filtering is performed on a per-service basis. The (presumably UDP) based traceroute appears to get stuck just after entering the DREN, not at the Chinese border... Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] most of root NS and com's NS fail from here
Hello, Le 29 avr. 2014 à 19:26, David Conrad a écrit : On Apr 29, 2014, at 3:05 AM, Emmanuel Thierry m...@sekil.fr wrote: If i'm not mistaken, the Chinese filtering is performed on a per-service basis. The (presumably UDP) based traceroute appears to get stuck just after entering the DREN, not at the Chinese border... A UDP traceroute is definitely not reliable as a network debugging tool. UDP is commonly filtered by firewalls in entreprise or managed networks. You need at least a ICMP traceroute or a mtr. As an example, the UDP traceroute gives exactly the same kind of results in my home or servers as Ken Peng, though i don't have any trouble in making DNS queries at it, even with a +notcp flag. What we may observe from tests is that some dns servers failed without an obvious connectivity problem (ping is OK). As a consequence, i think it would be really interesting to test for instance with an arbitrary dns server and see whether it fails or not. Best regards Emmanuel Thierry ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] most of root NS and com's NS fail from here
On Tue, Apr 29, 2014 at 2:18 PM, bert hubert bert.hub...@netherlabs.nl wrote: On 29 Apr 2014, at 20:55, Emmanuel Thierry m...@sekil.fr wrote: What we may observe from tests is that some dns servers failed without an obvious connectivity problem (ping is OK). As a consequence, i think it would be really interesting to test for instance with an arbitrary dns server and see whether it fails or not. Even root-servers that are down have been known to respond as observed from China. Sometimes within less milliseconds than it takes to reach the border. It is not internet as ‘we’ know it there. What would be interesting to see would be nsid, hostname.bind, etc from the NS to *do* resolve. E.g: dig -4 @l.root-servers.net hostname.bind CH TXT dig -4 @l.root-servers.net . SOA +nsid W Bert ___ dns-operations mailing list dns-operations@lists.dns-oarc.net 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 dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] most of root NS and com's NS fail from here
China has it's own root nodes is confirmed long ago, we published that in our paper https://ant.isi.edu/blog/?p=362 Just pinged H-root from CERNET of China: $ ping h.root-servers.net PING h.root-servers.net (128.63.2.53) 56(84) bytes of data. 64 bytes from 128.63.2.53: icmp_seq=1 ttl=55 time=9.63 ms 64 bytes from 128.63.2.53: icmp_seq=2 ttl=55 time=9.56 ms 9ms is faster than the speed of light, given the two H-root sites are both in US and the ping source is in Shanghai. For the failure in China telecom, one possible explanation is that somehow the route to the Chinese H-root doesn't propagate to some server in China telecom, while the GFW has already started to drop packets from real H-root. On Tue, Apr 29, 2014 at 12:15 PM, Warren Kumari war...@kumari.net wrote: On Tue, Apr 29, 2014 at 2:18 PM, bert hubert bert.hub...@netherlabs.nl wrote: On 29 Apr 2014, at 20:55, Emmanuel Thierry m...@sekil.fr wrote: What we may observe from tests is that some dns servers failed without an obvious connectivity problem (ping is OK). As a consequence, i think it would be really interesting to test for instance with an arbitrary dns server and see whether it fails or not. Even root-servers that are down have been known to respond as observed from China. Sometimes within less milliseconds than it takes to reach the border. It is not internet as ‘we’ know it there. What would be interesting to see would be nsid, hostname.bind, etc from the NS to *do* resolve. E.g: dig -4 @l.root-servers.net hostname.bind CH TXT dig -4 @l.root-servers.net . SOA +nsid W Bert ___ dns-operations mailing list dns-operations@lists.dns-oarc.net 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 dns-operations@lists.dns-oarc.net 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 dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] most of root NS and com's NS fail from here
On Tue, Apr 29, 2014 at 1:52 PM, Warren Kumari war...@kumari.net wrote: On Tue, Apr 29, 2014 at 4:45 PM, Xun Fan xun...@isi.edu wrote: China has it's own root nodes is confirmed long ago, we published that in our paper https://ant.isi.edu/blog/?p=362 Yup, believe me, I'm fully aware of that (and have read this, and many other papers, have done some of my own testing on a number of trips to Beijing, etc) -- unfortunately while I was there I didn't think to test NSID / hostname.bind / IDENTITY.L.ROOT-SERVERS.ORG, etc responses to see how convincing a lie^w optimization the servers provide. Oh, sure, I totally agree NSID/hostname.bind etc. will be very helpful. My experience is that if these query hit a masquerading root node, you mostly won't get an answer, by either no ANSWER section or empty string in ANSWER section. And another thing is the masquerading node is not always there. Sometimes our query hit the real root node and everything is correct (NSID, hostname.bind, etc.). But we didn't collect data continuously, so we don't know the exact pattern. Just pinged H-root from CERNET of China: $ ping h.root-servers.net PING h.root-servers.net (128.63.2.53) 56(84) bytes of data. 64 bytes from 128.63.2.53: icmp_seq=1 ttl=55 time=9.63 ms 64 bytes from 128.63.2.53: icmp_seq=2 ttl=55 time=9.56 ms 9ms is faster than the speed of light, given the two H-root sites are both in US and the ping source is in Shanghai. For the failure in China telecom, one possible explanation is that somehow the route to the Chinese H-root doesn't propagate to some server in China telecom, while the GFW has already started to drop packets from real H-root. Yup. W On Tue, Apr 29, 2014 at 12:15 PM, Warren Kumari war...@kumari.net wrote: On Tue, Apr 29, 2014 at 2:18 PM, bert hubert bert.hub...@netherlabs.nl wrote: On 29 Apr 2014, at 20:55, Emmanuel Thierry m...@sekil.fr wrote: What we may observe from tests is that some dns servers failed without an obvious connectivity problem (ping is OK). As a consequence, i think it would be really interesting to test for instance with an arbitrary dns server and see whether it fails or not. Even root-servers that are down have been known to respond as observed from China. Sometimes within less milliseconds than it takes to reach the border. It is not internet as ‘we’ know it there. What would be interesting to see would be nsid, hostname.bind, etc from the NS to *do* resolve. E.g: dig -4 @l.root-servers.net hostname.bind CH TXT dig -4 @l.root-servers.net . SOA +nsid W Bert ___ dns-operations mailing list dns-operations@lists.dns-oarc.net 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 dns-operations@lists.dns-oarc.net 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 dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] most of root NS and com's NS fail from here
Sorry, I forget to add, the hostname.bind query form CERNET to h-root got an reply with an empty string. On Tue, Apr 29, 2014 at 2:06 PM, Xun Fan xun...@isi.edu wrote: On Tue, Apr 29, 2014 at 1:52 PM, Warren Kumari war...@kumari.net wrote: On Tue, Apr 29, 2014 at 4:45 PM, Xun Fan xun...@isi.edu wrote: China has it's own root nodes is confirmed long ago, we published that in our paper https://ant.isi.edu/blog/?p=362 Yup, believe me, I'm fully aware of that (and have read this, and many other papers, have done some of my own testing on a number of trips to Beijing, etc) -- unfortunately while I was there I didn't think to test NSID / hostname.bind / IDENTITY.L.ROOT-SERVERS.ORG, etc responses to see how convincing a lie^w optimization the servers provide. Oh, sure, I totally agree NSID/hostname.bind etc. will be very helpful. My experience is that if these query hit a masquerading root node, you mostly won't get an answer, by either no ANSWER section or empty string in ANSWER section. And another thing is the masquerading node is not always there. Sometimes our query hit the real root node and everything is correct (NSID, hostname.bind, etc.). But we didn't collect data continuously, so we don't know the exact pattern. Just pinged H-root from CERNET of China: $ ping h.root-servers.net PING h.root-servers.net (128.63.2.53) 56(84) bytes of data. 64 bytes from 128.63.2.53: icmp_seq=1 ttl=55 time=9.63 ms 64 bytes from 128.63.2.53: icmp_seq=2 ttl=55 time=9.56 ms 9ms is faster than the speed of light, given the two H-root sites are both in US and the ping source is in Shanghai. For the failure in China telecom, one possible explanation is that somehow the route to the Chinese H-root doesn't propagate to some server in China telecom, while the GFW has already started to drop packets from real H-root. Yup. W On Tue, Apr 29, 2014 at 12:15 PM, Warren Kumari war...@kumari.net wrote: On Tue, Apr 29, 2014 at 2:18 PM, bert hubert bert.hub...@netherlabs.nl wrote: On 29 Apr 2014, at 20:55, Emmanuel Thierry m...@sekil.fr wrote: What we may observe from tests is that some dns servers failed without an obvious connectivity problem (ping is OK). As a consequence, i think it would be really interesting to test for instance with an arbitrary dns server and see whether it fails or not. Even root-servers that are down have been known to respond as observed from China. Sometimes within less milliseconds than it takes to reach the border. It is not internet as ‘we’ know it there. What would be interesting to see would be nsid, hostname.bind, etc from the NS to *do* resolve. E.g: dig -4 @l.root-servers.net hostname.bind CH TXT dig -4 @l.root-servers.net . SOA +nsid W Bert ___ dns-operations mailing list dns-operations@lists.dns-oarc.net 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 dns-operations@lists.dns-oarc.net 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 dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] most of root NS and com's NS fail from here
On Tue, Apr 29, 2014 at 5:06 PM, Xun Fan xun...@isi.edu wrote: On Tue, Apr 29, 2014 at 1:52 PM, Warren Kumari war...@kumari.net wrote: On Tue, Apr 29, 2014 at 4:45 PM, Xun Fan xun...@isi.edu wrote: China has it's own root nodes is confirmed long ago, we published that in our paper https://ant.isi.edu/blog/?p=362 Yup, believe me, I'm fully aware of that (and have read this, and many other papers, have done some of my own testing on a number of trips to Beijing, etc) -- unfortunately while I was there I didn't think to test NSID / hostname.bind / IDENTITY.L.ROOT-SERVERS.ORG, etc responses to see how convincing a lie^w optimization the servers provide. Oh, sure, I totally agree NSID/hostname.bind etc. will be very helpful. My experience is that if these query hit a masquerading root node, you mostly won't get an answer, by either no ANSWER section or empty string in ANSWER section. Ah, excellent. Thank you. W And another thing is the masquerading node is not always there. Sometimes our query hit the real root node and everything is correct (NSID, hostname.bind, etc.). But we didn't collect data continuously, so we don't know the exact pattern. Just pinged H-root from CERNET of China: $ ping h.root-servers.net PING h.root-servers.net (128.63.2.53) 56(84) bytes of data. 64 bytes from 128.63.2.53: icmp_seq=1 ttl=55 time=9.63 ms 64 bytes from 128.63.2.53: icmp_seq=2 ttl=55 time=9.56 ms 9ms is faster than the speed of light, given the two H-root sites are both in US and the ping source is in Shanghai. For the failure in China telecom, one possible explanation is that somehow the route to the Chinese H-root doesn't propagate to some server in China telecom, while the GFW has already started to drop packets from real H-root. Yup. W On Tue, Apr 29, 2014 at 12:15 PM, Warren Kumari war...@kumari.net wrote: On Tue, Apr 29, 2014 at 2:18 PM, bert hubert bert.hub...@netherlabs.nl wrote: On 29 Apr 2014, at 20:55, Emmanuel Thierry m...@sekil.fr wrote: What we may observe from tests is that some dns servers failed without an obvious connectivity problem (ping is OK). As a consequence, i think it would be really interesting to test for instance with an arbitrary dns server and see whether it fails or not. Even root-servers that are down have been known to respond as observed from China. Sometimes within less milliseconds than it takes to reach the border. It is not internet as ‘we’ know it there. What would be interesting to see would be nsid, hostname.bind, etc from the NS to *do* resolve. E.g: dig -4 @l.root-servers.net hostname.bind CH TXT dig -4 @l.root-servers.net . SOA +nsid W Bert ___ dns-operations mailing list dns-operations@lists.dns-oarc.net 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 dns-operations@lists.dns-oarc.net 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 dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] most of root NS and com's NS fail from here
Thanks for all your helps. The dig for version.bind and hostname.bind sometime works, sometime not. as you see: pyh@dwdns153:~$ dig txt chaos version.bind @h.root-servers.net ; DiG 9.6.1-P2 txt chaos version.bind @h.root-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 21537 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 0 CH TXT NSD 4.0.3 ;; Query time: 257 msec ;; SERVER: 128.63.2.53#53(128.63.2.53) ;; WHEN: Wed Apr 30 09:02:23 2014 ;; MSG SIZE rcvd: 52 pyh@dwdns153:~$ dig txt chaos hostname.bind @h.root-servers.net ; DiG 9.6.1-P2 txt chaos hostname.bind @h.root-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 29675 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;hostname.bind. CH TXT ;; ANSWER SECTION: hostname.bind. 0 CH TXT 003.nzy.h.root-servers.org ;; Query time: 256 msec ;; SERVER: 128.63.2.53#53(128.63.2.53) ;; WHEN: Wed Apr 30 09:02:37 2014 ;; MSG SIZE rcvd: 70 pyh@dwdns153:~$ pyh@dwdns153:~$ pyh@dwdns153:~$ dig txt chaos version.bind @h.root-servers.net +short ; DiG 9.6.1-P2 txt chaos version.bind @h.root-servers.net +short ;; global options: +cmd ;; connection timed out; no servers could be reached pyh@dwdns153:~$ pyh@dwdns153:~$ pyh@dwdns153:~$ dig txt chaos version.bind @h.root-servers.net +short ; DiG 9.6.1-P2 txt chaos version.bind @h.root-servers.net +short ;; global options: +cmd ;; connection timed out; no servers could be reached And this is the mtr info for h.root-servers.net: pyh@dwdns153:~$ mtr h.root-servers.net --report HOST: dwdns153.dns.yt.yygamedev.c Loss% Snt Last Avg Best Wrst StDev 1. 113.108.228.129 40.0%100.5 0.5 0.5 0.8 0.1 2. 121.14.46.93 10.0%100.5 0.5 0.5 0.5 0.0 3. 121.14.37.33 0.0%102.7 3.3 1.6 7.2 1.9 4. 121.14.37.6 0.0%100.4 0.4 0.3 0.7 0.1 5. 121.14.50.13 0.0%101.5 2.3 0.9 4.3 1.2 6. 113.108.208.970.0%104.8 3.9 1.6 5.9 1.5 7. 202.97.34.202 0.0%101.1 1.5 0.9 5.2 1.3 8. 202.97.61.234 0.0%102.1 1.6 1.3 2.2 0.3 9. 202.97.52.154 0.0%10 148.6 149.7 147.7 151.3 1.3 10. 202.97.49.158 0.0%10 151.5 150.7 148.6 151.8 1.2 11. 218.30.54.198 0.0%10 174.9 183.0 174.9 209.5 9.7 12. los-edge-05.inet.qwest.net0.0%10 169.8 175.9 169.8 180.5 3.4 13. 65-126-18-214.dia.static.qwe 0.0%10 172.7 179.4 172.7 186.4 4.5 14. 143.56.244.2 0.0%10 160.5 173.9 160.5 192.2 11.6 15. ap-1-1-1-nd.level3-lax.core. 0.0%10 160.7 167.6 160.1 173.4 4.7 16. np-5-1-1-nd.sandiego.core.dr 0.0%10 177.9 185.6 177.9 195.3 5.0 17. 138.18.190.8910.0%10 163.8 172.2 163.8 178.3 4.4 18. 138.18.190.114 10.0%10 163.2 163.4 163.1 164.8 0.5 19. 128.63.2.53 10.0%10 171.2 180.3 171.2 185.4 4.2 Regards. Ken 于 2014-4-30 5:16, Warren Kumari 写道: Oh, sure, I totally agree NSID/hostname.bind etc. will be very helpful. My experience is that if these query hit a masquerading root node, you mostly won't get an answer, by either no ANSWER section or empty string in ANSWER section. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] most of root NS and com's NS fail from here
Hi, Recent days I found most of the root nameservers, and com/net's nameservers can't work from here. When accessing to them I always got timeout. These are the test info for root NS: $ dig . ns +short |sort |while read LINE;do if dig . soa @$LINE /dev/null 21;then echo $LINE OK;else echo $LINE fail;fi;done a.root-servers.net. OK b.root-servers.net. fail c.root-servers.net. OK d.root-servers.net. fail e.root-servers.net. OK f.root-servers.net. OK g.root-servers.net. OK h.root-servers.net. fail i.root-servers.net. OK j.root-servers.net. fail k.root-servers.net. OK l.root-servers.net. fail m.root-servers.net. OK (5 o 13 failed) These are the test info for com's NS: $ dig com ns +short |sort |while read LINE;do if dig com soa @$LINE /dev/null 21;then echo $LINE OK;else echo $LINE fail;fi;done a.gtld-servers.net. fail b.gtld-servers.net. fail c.gtld-servers.net. OK d.gtld-servers.net. fail e.gtld-servers.net. OK f.gtld-servers.net. fail g.gtld-servers.net. OK h.gtld-servers.net. OK i.gtld-servers.net. fail j.gtld-servers.net. fail k.gtld-servers.net. fail l.gtld-servers.net. fail m.gtld-servers.net. OK (8 of 13 failed) I am from China, ISP telecom. Can you tell what happens? Thanks. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
