Re: Are public DNS a good thing? (was: Re: 1.1.1.1)

[Javier J via NANOG <nanog () lists nanog org>]

You have to also account for user's downtime and their inability to
work. That depends on the number of users, what kind of work they do,
etc.

for my personal use at home, my setup looks like this:
https://postimg.cc/vgf2r1GM

I would just ramp up the hardware for a big org.

Regarding cloudflare and google and any other providers, if the
product is free, you are the product.

On Fri, Jul 18, 2025 at 11:51 AM Tom Beecher via NANOG
<nanog () lists nanog org> wrote:
> > As long as there is a “free” solution that doesn’t cause the implementer
> > pain (ignoring user impacts) , it will be popular :)
>
>
> Even when it does cause more user impact it sometimes still works out that
> way.
>
> Say a company has two options for a given service :
> 1. Run it themselves. Cost $100K a year,  5 9's uptime.  ( 5 down mins /
> year )
> 2. Use As A Service. Cost $50K a year,  4 9's uptime. ( 53 down mins/year.
> )
>
> Say that every minute this company is down, they lose $1K in revenue. That
> means :
> Option 1 total cost : $105K ( run + 5 mins lost rev )
> Option 2 total cost : $103K ( run + 53 mins lost rev )
>
> The technical person is going to say 'these costs are basically the same,
> let's take the higher uptime of option 1'.
> The MBA is going to say 'I can reduce our costs by 1.9% with option 2.'
>
> And we know who wins in most places.
>
> On Fri, Jul 18, 2025 at 10:31 AM Mel Beckman via NANOG <
> nanog () lists nanog org> wrote:
>
> > A situation I’ve seen often with SMBs is when they have two or more ISPs
> > using WAN failover or load balancing mechanisms built into their firewall.
> > This requires either running your own local caching resolver that queries
> > root name servers, paying for a third party DNS services, or somehow
> > ensuring DNS requests get routed to the appropriate ISP’s name servers,
> > because “crossing the streams” will fail every time.
> >
> > Or one can just use a public DNS server, the minimal-effort “free”
> > solution.
> >
> > As we all know, public DNS isn’t really free. You’re giving up your DNS
> > eyeball information in exchange, which the public DNS operator happily
> > sells to the highest bidder. And then there is the NXDOMAIN concession, in
> > which you tacitly agree to accept ads in place of name-not-found responses.
> >
> > As long as there is a “free” solution that doesn’t cause the implementer
> > pain (ignoring user impacts) , it will be popular :)
> >
> >  -mel
> >
> > > On Jul 18, 2025, at 7:03 AM, Marc Binderberger via NANOG <
> > nanog () lists nanog org> 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
> > > > <nanog () lists nanog org>
> > > > wrote:
> > > >
> > > > > On Thu, Jul 17, 2025 at 1:18 PM Paul Ebersman via NANOG
> > > > > <nanog () lists nanog org> 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/nanog () lists nanog org/message/IPQKD6S4BG5TFTMXEEARRUMZIJFUDH5M/
> > > > _______________________________________________
> > > > NANOG mailing list
> > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/PZ6X3FICURGGQAAA6V6MNMZ5XF57CXFK/
> > > _______________________________________________
> > > NANOG mailing list
> > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/MEUDCZZAC7CUNR5H3OW4H3EAVLUG2NY3/
> > _______________________________________________
> > NANOG mailing list
> >
> > https://lists.nanog.org/archives/list/nanog () lists nanog org/message/GZG3GUGAMDMFE4SNMTO5N7DX5CFV6N76/
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/IBITGNZE5KXTM4QJSUF5L6LRGHH4LNHS/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/OKNJATIZCUAHR263UDFBYWBI2PZIIXSW/