On Tue, 9 Mar 2021 22:26:29 -0800
Rick Moen <rick@???> wrote:

> Quoting Gabe Stanton via Dng (dng@???):
>
> > In the absence of a "community of dns server operators and users",
> > is the optimal option to have everyone run their own recursive
> > server? But then the upstream servers still get the birds-eye view
> > and will very likely abuse that information like the big companies
> > do now.
>
> Please pardon my being blunt, but I don't think you have a realistic
> understanding of how typical patterns of authoritative nameservice
> data and caching work. I rather suspect you haven't stopped to think
> about that.
>
> Let's say I run a local recursive DNS nameserver on my local LAN for
> use by my and all other local hosts. For the sake of discussion, let
> us assume that it has what is misleadingly called an 'ICANN' root
> hints file.
>
> At service startup time, the instance starts getting and caching TLD,
> SLD, etc. authoritative data and caching it for the duration of
> TTLs. Right, now, kindly tell me where on the planet is the network
> node that provides a "birds-eye view" of query traffic processed by
> my recursive server? The root nameservers? Nope, not hardly. All
> they have is the hits where my nameserver followed the RD-bit-marked
> queries to find various TLD nameservers. TLD zones' nameservers?
> Nope, not hardly. They have only analogous logfile data when my
> nameserver first located and then cached information about SLD
> nameservers.
>
> In fact, the very fact that I am operating a recursive nameserver
> means that I have greatly impoverished every possible spying vantage
> point. The best of the bad choices in places to spy on my network's
> port-53 activity is thus right on the far side of my network uplink,
> at my local bandwidth provider. And, even there, because of
> pervasive caching, even my uplink has extremely poor data about what
> the machines on my local LAN are looking up.
>
> Ideally, one has a contractual relationship with a reputable good
> provider who looks after customer interests in accordance to local
> business practices and law, such as (to cite the USA local legal
> concept) the implied covenant of good faith and fair dealing.
> However, that contract concept is (naturally) not a shield for
> privacy but rather a cudgel to wield in civil litigation, so the best
> thing to do is to limit what your immediate uplink can learn about
> your network traffic. Various crypto schemes help limit that data,
> but -- my point -- so does operating a local recursive nameserver,
> rather than outsourcing to -anyone- on the other side of the uplink.
Hi,
just for fast information, is it enough for unbound to remove:

forward-zone:
        #forward-first: yes
        name: "."
        forward-tls-upstream: yes
        forward-addr: 1.1.1.1@853#cloudflare-dns.com
        forward-addr: 1.0.0.1@853#cloudflare-dns.com
        forward-addr: 8.8.4.4@853#dns.google
        forward-addr: 8.8.8.8@853#dns.google
        forward-addr: 9.9.9.9@853#dns.quad9.net
        forward-addr: 185.222.222.222@853#dns.sb
        forward-addr: 185.184.222.222@853#dns.sb

Makes it sense to keep:

server:
        tls-upstream: yes
        tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

I ask because after reading the thread I've tried on one
of my home's net dns servers and it worked (I could browse the web)
but browsing speed was noticeably slower, does it improve
in the long run or do we have to choose between
privacy and speed?

Thanks in advance.

Ciao,
Tito