If it is urgent, I suggest the K root operator withdraw the route of the instance in Guangzhou immediately.
Davey On Mon, 8 Nov 2021 at 15:23, Davey Song <songlinj...@gmail.com> wrote: > Hi Manu, > > Is it still the case? I will try to outreach the people of AS4134 and > AS138457. > > Best regards, > Davey > > On Sat, 6 Nov 2021 at 12:18, Manu Bretelle <chan...@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 199.59.149.244.... 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 . >> inFOlh92Cxaf58/AdV/M4SZ37+MCm6PMOn6RNHDtE1MR6yvD0sfSPui9 >> YR3o9Yix/55zuodOWkCh7A0mMosbC5v2gMeiR9iw5jWko5dU7tPPSMnL >> MZNgsRvIjuR80RWOJnvEVZyz45BXtFWd6UcCIG3BahAUSOXAWhqhkNP4 >> gF6YeDsZHElhjvhWAzBA/44aFCJPT2nySKuzH4cGRulhO0remY6CHD4o >> 59fQooYT8lopP6SWdHOmDYhdb6/UBGDELd35QwGG0MDAMSie6jZGGkeb >> 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 31.13.67.19 >> ;; Received 51 bytes from 193.0.14.129#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: >> https://atlas.ripe.net/measurements/33184386/ >> ``` >> $ blaeu-resolve -m 33184386 -q A d.ns.facebook.com >> [] : 13 occurrences >> [202.160.128.195] : 1 occurrences >> [199.59.148.97] : 1 occurrences >> [185.89.219.12] : 2 occurrences >> [31.13.96.193] : 1 occurrences >> [208.77.47.172] : 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 185.89.219.12). >> >> 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 202.160.128.195 >> Probe #31355: 2021-11-05 13:37:01 NOERROR qr ra rd d.ns.facebook.com. >> 146 A 199.59.148.97 >> Probe #52013: 2021-11-05 13:37:01 NOERROR qr ra rd d.ns.facebook.com. >> 179 A 31.13.96.193 >> Probe #52660: 2021-11-05 13:37:00 NOERROR qr ra rd d.ns.facebook.com. >> 150 A 208.77.47.172 >> ... >> ``` >> >> Those probes will fail to reach 193.0.14.129 (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 193.0.14.129 >> https://atlas.ripe.net/measurements/33184807/ >> ``` >> >> 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 >> ns1.cn-ggz.k.ripe.net >> Probe #31355: 2021-11-05 14:08:55 NOERROR qr rd id.server. 0 TXT >> ns1.cn-ggz.k.ripe.net >> Probe #52013: 2021-11-05 14:08:55 NOERROR qr rd id.server. 0 TXT >> ns1.cn-ggz.k.ripe.net >> Probe #52660: 2021-11-05 14:08:55 NOERROR qr rd id.server. 0 TXT >> ns1.cn-ggz.k.ripe.net >> ... >> ``` >> >> Traceroute from those probes to k-root: >> https://atlas.ripe.net/measurements/33184963/ >> >> >> 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 >> path: >> >> 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) >> >> Thanks, >> >> Manu >> _______________________________________________ >> dns-operations mailing list >> dns-operations@lists.dns-oarc.net >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations >> >
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations