>
> are we talking about BCP-140, aka RFC5358 ("Preventing Use of Recursive
> Nameservers in Reflector Attacks") ?
>
> Well, it's both, a BCP and RFC - which statement above wins? ... ;-)
>
>
> Joking aside, I don't see why this BCP would not be relevant today. If you
> run an open recursive DNS in the Internet, this still seems to me a valid
> document to consider.My stance on these (which I think mirrors the IETF's definitions) is that BCPs are a subset of RFCs, and are guidance , not standards. Which, over time, the 'current' part of the guidance is relevant to consider. With respect to BCP-140, sure, it's still generally applicable today. I didn't mean to imply it wasn't in my response. I was more generally commenting on the age of document bits, and that wasn't clear. So sorry about the confusion there. > > > And yes, I was wondering if the redundancy - or centralization - of the > Internet is something to consider. My personal read on all the comments is > that the N.N.N.N public servers are good backup forwarder solutions but for > the sake of a de-centralized, robust Internet one should implement a better > "Plan A". And don't forget BCP-140 when you implement the plan ;-) Everyone should be considering the impacts of centralization (not just with DNS) but a lot of people just don't. This recent CF event is a perfect example. These companies generally are very good at what they're doing, but the occasional catastrophic mistake happens. If someone wants to put all their eggs in one basket, they get to enjoy the pain when it bites them. On Fri, Jul 18, 2025 at 8:20 AM Marc Binderberger <[email protected]> wrote: > > On Thu, 17 Jul 2025 15:03:01 -0400, Tom Beecher via NANOG wrote: > > > With RFCs, no. > > With BCP, the middle letter is generally relevant to the discussion. > > are we talking about BCP-140, aka RFC5358 ("Preventing Use of Recursive > Nameservers in Reflector Attacks") ? > > Well, it's both, a BCP and RFC - which statement above wins? ... ;-) > > > Joking aside, I don't see why this BCP would not be relevant today. If you > run an open recursive DNS in the Internet, this still seems to me a valid > document to consider. > > But "to consider" does not mean "it's the law". Everyone who is willfully > running into these known problems (by setting up a public DNS, I mean) > simply > has to assign the necessary resources to handle the problems. And I assume > Google, CF & Co do this. > > In any case, my original question was not with BCP-140 in mind (but thanks > to > Rubens pointing it out!). I was wondering why one should or should not use > these DNS servers. Thanks for all the comments, I am always surprised how > complex even "basic" things like DNS turn out to be. > > And yes, I was wondering if the redundancy - or centralization - of the > Internet is something to consider. My personal read on all the comments is > that the N.N.N.N public servers are good backup forwarder solutions but > for > the sake of a de-centralized, robust Internet one should implement a > better > "Plan A". And don't forget BCP-140 when you implement the plan ;-) > > Regards, Marc > > > > > On Thu, 17 Jul 2025 15:03:01 -0400, Tom Beecher via NANOG wrote: > >> > >> RFC 1035 is still what defines DNS, hasn't been obsoleted and is from > 1987. > >> Perhaps age is not the main factor in defining obsolescence ? > > > > > > With RFCs, no. > > > > With BCP, the middle letter is generally relevant to the discussion. > > > > On Thu, Jul 17, 2025 at 2:40 PM Rubens Kuhl via NANOG > > <[email protected]> > > wrote: > > > >> On Thu, Jul 17, 2025 at 1:18 PM Paul Ebersman via NANOG > >> <[email protected]> wrote: > >>> > >>>> This raises my question: are public DNS like 1.1.1.1 or Google's > >>>> 8.8.8.8 actually a good thing? > >>> > >>> rubensk> According to BCP-140, no, not a good thing. > >>> > >>> That BCP is from 2015... > >> > >> RFC 1035 is still what defines DNS, hasn't been obsoleted and is from > 1987. > >> Perhaps age is not the main factor in defining obsolescence ? > >> > >> > >> Rubens > >> _______________________________________________ > >> NANOG mailing list > >> > >> > > https://lists.nanog.org/archives/list/[email protected]/message/IPQKD6S4BG5TFTMXEEARRUMZIJFUDH5M/ > > _______________________________________________ > > NANOG mailing list > > > > https://lists.nanog.org/archives/list/[email protected]/message/PZ6X3FICURGGQAAA6V6MNMZ5XF57CXFK/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/2C7V4NXOHB7SSKFLNDG7T36Y5R3LOTXV/
