Public DNS is just another basic service, no different than commercially-sold DNS services such as Amazon Route 53 or Cisco Umbrella. Yes, commercial DNS usually offers additional security and monitoring, which is really why you buy it, but is fails just as often as public DNS, although probably less often than the average internal resolver. Other than the right to yell at somebody, I haven’t seen any qualitative difference in DNS services of all stripes.
-mel > On Jul 17, 2025, at 7:40 AM, Marc Binderberger via NANOG > <[email protected]> wrote: > > >> On Wed, 16 Jul 2025 18:24:55 +0300, Saku Ytti via NANOG wrote: >> Any amount of redundancy can be fixed by automation. > > :-) > > This raises my question: are public DNS like 1.1.1.1 or Google's 8.8.8.8 > actually a good thing? > > I'm not talking about customers of the particular cloud services - you would > expect a well-run DNS system as part of the service offer. But for anyone > else? > > As Saku (implicitly) stated: these services are likely managed all in the > same manner with automation/scripts. I assume the underlying software is the > same too on the distributed servers behind one particular anycast address > (I'm not saying Google and CF use the same software). > > So how redundant is the DNS system then in reality? > > On the other hand, having some well-funded/well-staffed organizations dealing > with all the problems of security, attacks and other "nonsense" is a benefit > of using public DNS. > > > Personally I tend to run "unbound" for recursive resolving and close it > against outside use. But I may miss an important point - any reasoning that > points to the one or the other solution as being better? > (my setups/domains are for private use only these days, nothing big, nothing > important, so what do I know ... but I'm happy to learn & improve) > > Best regards, Marc > > > > >>> On Wed, 16 Jul 2025 at 17:15, Tom Beecher via NANOG >>> <[email protected]> wrote: >>> >>> Now that everyone has gotten the RPKI rage out of their system, Cloudflare >>> is taking responsibility for this event. Explicitly stated it wasn't a >>> hijack, but their own mistake. >>> >>> https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/ > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/[email protected]/message/ELUIQH7IN7RXNIRHXK64GBJBMEP65URB/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/AIBEEZ2CXSLF4N7IAW7KWHLBRSYWQQ2W/
