[dns-operations] K-root in CN leaking outside of CN

Manu Bretelle chantr4 at gmail.com
Sat Nov 6 04:13:53 UTC 2021

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 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 in 0 ms

;; expected opt record in response
d.ns.facebook.com.      65      IN      A
;; Received 51 bytes from 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
[] : 1 occurrences
[] : 1 occurrences
[] : 2 occurrences
[] : 1 occurrences
[] : 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

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
Probe #31355: 2021-11-05 13:37:01 NOERROR qr ra rd d.ns.facebook.com. 146 A
Probe #52013: 2021-11-05 13:37:01 NOERROR qr ra rd d.ns.facebook.com. 179 A
Probe #52660: 2021-11-05 13:37:00 NOERROR qr ra rd d.ns.facebook.com. 150 A

Those probes will fail to reach (k-root) over TCP.

Checking which id.server is returned by the k-roots reached by those probes:

ripe-atlas measure dns --query-argument id.server --query-type TXT
--query-class CHAOS --from-country MX --target

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: 138457)
Reseaux IP Europeens Network Coordination Centre (RIPE NCC) (AS PATH: 25152)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20211105/5b153ccf/attachment.html>

More information about the dns-operations mailing list