[dns-operations] K-root in CN leaking outside of CN
songlinjian at gmail.com
Mon Nov 8 07:23:50 UTC 2021
Is it still the case? I will try to outreach the people of AS4134 and
On Sat, 6 Nov 2021 at 12:18, Manu Bretelle <chantr4 at gmail.com> wrote:
> Hi all,
> Based on https://root-servers.org/, there are a few root servers operated
> from Mainland China.
> How do we ensure that those are not advertised outside of China so DNS
> answers are not poisoned by the GFW?
> Are there any contracts that root in CN are supposed to follow to prevent
> this? Is the onus put on both the CN ASNs and their respective non-CN ASNs
> peers to not advertise/not accept the root range on those specific peering
> links? If so, how is it ensured that every operator knows about those rules?
> Is there any monitoring performed by root operators to ensure that leaks
> are being detected and possibly addressed?
> I don't believe this specific leak I am seeing is malicious, but rather is
> just a misconfiguration and I really wonder how this could be
> prevented/addressed early on.
> I have ran some probes in other regions and do not have proof that this is
> happening more widely than a specific AS, but this was not exhaustive and I
> could have very likely missed something.
> As for this specific problem, we have reached out to both the AS that is
> accepting the leak and RIPE NCC as we identified the issue, provided the
> ISP possible workaround in the meantime.
> Both DNSSEC and Qname minimization would have helped the resolver
> detecting bogus answers, or just getting to com. in the first place, while
> this would have helped, there is still an ongoing leak.
> Longer story for the ones that want to dig more into it....
> I am asking because we (FB/Meta) got reports from an ISP in MX which users
> were not able to access whatsapp.net. For instance, answer would be
> 126.96.36.199.... which is not quite the right answer....
> Some initial debugging from the ISP seemed to point to k-root acting up.
> e.g something alike:
> # dig +trace d.ns.facebook.com
> ; <<>> DiG 9.11.13 <<>> +trace d.ns.facebook.com
> ;; global options: +cmd
> . 518379 IN NS m.root-servers.net.
> . 518379 IN NS e.root-servers.net.
> . 518379 IN NS g.root-servers.net.
> . 518379 IN NS j.root-servers.net.
> . 518379 IN NS k.root-servers.net.
> . 518379 IN NS b.root-servers.net.
> . 518379 IN NS l.root-servers.net.
> . 518379 IN NS a.root-servers.net.
> . 518379 IN NS i.root-servers.net.
> . 518379 IN NS d.root-servers.net.
> . 518379 IN NS f.root-servers.net.
> . 518379 IN NS h.root-servers.net.
> . 518379 IN NS c.root-servers.net.
> . 518379 IN RRSIG NS 8 0 518400
> 20211117170000 20211104160000 14748 .
> DhAuTFRWzboxlbqQw3nyYlH0Ot8lSatzhx0Cl0rNIBTboFQiWIUMgtVi PeRj0Q==
> ;; Received 1125 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
> ;; expected opt record in response
> d.ns.facebook.com. 65 IN A 188.8.131.52
> ;; Received 51 bytes from 184.108.40.206#53(k.root-servers.net) in 231 ms
> Looking a bit more into it:
> Querying d.ns.facebook.com/A against k-root directly from MX probes:
> $ blaeu-resolve -m 33184386 -q A d.ns.facebook.com
>  : 13 occurrences
> [220.127.116.11] : 1 occurrences
> [18.104.22.168] : 1 occurrences
> [22.214.171.124] : 2 occurrences
> [126.96.36.199] : 1 occurrences
> [188.8.131.52] : 1 occurrences
> Test #33184386 done at 2021-11-05T20:36:59Z
> Getting an answer in the first place is kind of unexpected but I will not
> focus on the ones returning the correct answer (e.g 184.108.40.206).
> Checking the probes that return those results:
> ripe-atlas report --renderer dns_compact 33184386
> Probe #27558: 2021-11-05 13:36:59 NOERROR qr ra rd d.ns.facebook.com. 98
> A 220.127.116.11
> Probe #31355: 2021-11-05 13:37:01 NOERROR qr ra rd d.ns.facebook.com. 146
> A 18.104.22.168
> Probe #52013: 2021-11-05 13:37:01 NOERROR qr ra rd d.ns.facebook.com. 179
> A 22.214.171.124
> Probe #52660: 2021-11-05 13:37:00 NOERROR qr ra rd d.ns.facebook.com. 150
> A 126.96.36.199
> Those probes will fail to reach 188.8.131.52 (k-root) over TCP.
> Checking which id.server is returned by the k-roots reached by those
> ripe-atlas measure dns --query-argument id.server --query-type TXT
> --query-class CHAOS --from-country MX --target 184.108.40.206
> where the interesting snippet is:
> $ ripe-atlas report --renderer dns_compact 33184807
> Probe #27558: 2021-11-05 14:08:54 NOERROR qr rd id.server. 0 TXT
> Probe #31355: 2021-11-05 14:08:55 NOERROR qr rd id.server. 0 TXT
> Probe #52013: 2021-11-05 14:08:55 NOERROR qr rd id.server. 0 TXT
> Probe #52660: 2021-11-05 14:08:55 NOERROR qr rd id.server. 0 TXT
> Traceroute from those probes to k-root:
> Looking at the traceroutes
> ripe-atlas report --renderer traceroute --traceroute-show-asns 33184963
> shows that the last AS before reaching a CN AS and also the first
> transiting AS from the probe is AS32098
> which when checking their looking glass: https://lg.transtelco.net/ uses
> Transtelco Inc. (AS PATH: 32098)
> Asia Pacific Network Information Centre (AS PATH: 4134)
> Not found (AS PATH: 58466)
> China Academy of Information and Communications Technology (AS PATH:
> Reseaux IP Europeens Network Coordination Centre (RIPE NCC) (AS PATH:
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dns-operations