[dns-operations] most of root NS and com's NS fail from here

[Xun Fan]

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 <xunfan at isi.edu> wrote:

>
>
>
> On Tue, Apr 29, 2014 at 1:52 PM, Warren Kumari <warren at kumari.net> wrote:
>
>> On Tue, Apr 29, 2014 at 4:45 PM, Xun Fan <xunfan at 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 <warren at kumari.net>
>> wrote:
>> >>
>> >> On Tue, Apr 29, 2014 at 2:18 PM, bert hubert <
>> bert.hubert at netherlabs.nl>
>> >> wrote:
>> >> >
>> >> > On 29 Apr 2014, at 20:55, Emmanuel Thierry <ml at 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 at 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 at 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
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140429/4185ba75/attachment.html>