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