[dns-operations] K-root in CN leaking outside of CN
Manu Bretelle
chantr4 at gmail.com
Mon Nov 8 18:02:15 UTC 2021
Thanks Liman,
I really appreciate this bit of history/context.
> First, just to re-iterate: I-root servers operated by Netnod responds to
> all DNS queries we can handle, as we receive them, with unaltered
> answers from the true root zone. Period. We are, at the moment, not
> aware of any servers outside of our control operating on I-roots
> IP-addresses.
>
> What happens to the DNS packets beyond the first upstream router is at
> best difficult, and in many cases impossible, for us to control, though.
>
Yes, I am also going to re-iterate that this was not my intent to say that
${letter}.root was modifying those answers. But rather that a route leak
was apparently happening and content changed on the way by saying:
> How do we ensure that those are not advertised outside of China so DNS
answers are not poisoned by the GFW?
>
> As Ray Bellis notes, we had a similar incident with the I-root node in
> Beijing back in 2010. It was fixed blindingly fast and with profuse
> apologies when we reported it to our site host. My experience is that
> Chinese authorities have no wish to inflict problems on clients outside
> China, and that whatever impersonation/leakage happens is indeed due to
> configuration errors on networking equipment.
Also very much agreeing on this, and this was also my impression:
> 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.
>
>
There is no way to guarantee that any one ISP (inside China or not) does
> what you expect and hope with your BGP announcements and the traffic
> going to/from any server of yours (DNS root or other). Specifically, I
> expect that a country with more than a billion citizens has a network
> complexity of certain scale, which, in combination with the intricate
> large scale traffic filters, makes "playing" with NO_EXPORT even
> trickier than normal. Life with anycast is a constant challenge to
> deploy the right number of instances at the right points in topology in
> order to make the right thing happen given an existing budget.
>
Agreed this is a tricky problem and as we see, history repeats itself, old
problems become new again, mistakes will always happen, and it will
probably be very difficult to avoid them moving forward, but if we could
collectively come up with a way to monitor and detect such issues we will
probably be in a better spot to act faster.
>
> If you see any signs of problems with i.root-servers.net, please report
> them without delay to <noc at netnod.se>. Every such report is of great
> value to us, as it helps us understand what our service looks like to
> you. These observations are important fixpoints in our continuous
> efforts to improve our service.
>
I would definitely do it. It was very much luck though. The probabilities
of ISP needing to go back to root to the impacted domains and choosing the
affected one would have been pretty low. In this case, a particular ISP
being impacted and having user reports, managing to reproduce it and
eventually this got to us through partner channels which we ended up
looking into and here I am bringing this up here so this does not get fixed
in a silo but hopefully we can learn and be better prepared to detect those
issues in the future. This would be beneficial to all letters and their
users IMO.
>
> And finally to each and every one of you:
>
> Please turn on validation in your resolvers and sign your zones. DNSSEC
> is your friend.
>
Thanks Liman for the reminder. I appreciate you not making this the main
point of your reply and kept on topic.
Manu
>
> Best regards,
> /Liman
> hostmaster at i.root-servers.net
>
> #----------------------------------------------------------------------
> # Lars-Johan Liman, M.Sc. ! E-mail: liman at netnod.se
> # Senior Systems Specialist ! Tel: +46 8 - 562 860 12
> # Netnod AB, Stockholm ! http://www.netnod.se/
> #----------------------------------------------------------------------
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20211108/33ab607f/attachment.html>
More information about the dns-operations
mailing list