5 ms·

I experienced how many good tech people don’t understand DNS and how this just solidifies control over DNS by the big players. What a ton of people don’t under

I experienced how many good tech people don’t understand DNS and how this just solidifies control over DNS by the big players. What a ton of people don’t understand is that you don’t need a DNS forwarder (google/cloud flare/ISP). If you setup your DNS right it just goes to the ROOT servers and you cut out those parties spying on DNS traffic. Initial requests are a bit slower because you don’t benefit from the forwarder’s cache, but after a while, most stuff is coached and it’s not a big deal. Maybe I’m totally wrong here, but this is how I understand it.

pw6hv 6y ago
Would you care to elaborate how one would start implementing a DNS that goes directly to the ROOT? Honestly interested here.
- znpy 6y ago
  If you don't specify a forwarder in the bind9 configuration it should query the root DNS servers directly, iirc.
- liv-io 6y ago
  I'd recommend you to use Unbound and specify the named.root or (root.hints) file: https://www.internic.net/domain/named.root https://www.internic.net/domain/named.root This Ansible role takes care of configuring it all (CentOS): https://github.com/liv-io/ansible-roles-centos/tree/master/unbound https://github.com/liv-io/ansible-roles-centos/tree/master/u... I have it for FreeBSD and OpenBSD too: https://github.com/liv-io/ansible-roles-bsd/tree/master/unbound https://github.com/liv-io/ansible-roles-bsd/tree/master/unbo...
- aeden 6y ago
  I think the post is suggesting running your own local resolver instead of using a public resolver or an ISP resolver.
- adrian_b 6y ago
  For example you may use the open-source program "dnscache" from Daniel Bernstein. I have been using this program on all my computers, during the last almost twenty years, without problems.
- louwrentius 6y ago
  I think just running bind without a resolver is enough. Make sure you keep bind and thus the roots.hints file up-to-date.
- quesera 6y ago
  To amplify other replies: DNS is very easy to run yourself. I use, and highly recommend, Unbound[1] as a caching resolver, and NSD[2] as an authoritative nameserver. A caching resolver is used for ordinary lookups. If the address for "ycombinator.com" isn't in the cache, the resolver starts at the root and recursively finds the authority for the domain, gets the answer, caches it, and returns it to you. You run this for general usage, and you point your desktop/laptop computers to this address. Google runs their public resolver at "8.8.8.8", etc. An authoritative nameserver is the ultimate authority on the lookup results for a specific domain. All lookups by other people eventually reach the authoritative nameserver for an answer. You run this for domains that you own, and configure it in your domain record. (Both can be a bit more complicated than that, but they don't need to be) These two services need almost zero care and feeding. Set them up once, and you can basically forget about them for years. This article only discusses resolvers, which are literally set-and-forget. Authoritative nameservers only need maintenance if you make changes to your domain. (And if you don't have your own domains, you don't need an authoritative nameserver at all). [1] Unbound: https://www.nlnetlabs.nl/projects/unbound/about/ https://www.nlnetlabs.nl/projects/unbound/about/ [2] NSD: https://www.nlnetlabs.nl/projects/nsd/about/ https://www.nlnetlabs.nl/projects/nsd/about/
  - jrnichols 6y ago
    This is also how pi-hole likes to be run. https://docs.pi-hole.net/guides/unbound/ https://docs.pi-hole.net/guides/unbound/
unilynx 6y ago
simply not using your ISP's DNS servers doesn't make your DNS traffic invisible to them. unless your ISP actively messes with the DNS responses, I'm not sure if you're gaining any privacy by going to the root directly
tie_ 6y ago
> I experienced how many good tech people don’t understand DNS... Totally agree there. Root DNS servers would not answer your computer's (stub resolver's) _recursive_ query. You do need a recursive resolver to do that - whether ran by an ISP or by yourself.
merlyn 6y ago
One of the problems mentioned in the article is that all major browsers are starting to automatically set your browser to ignore system settings and just go to Cloudflare or Google DoH servers. No matter what you do locally (unless you locally serve the do-not-auto-doh flag), you'll have to touch each of your browsers on each system to not have this behavior.

pw6hv 6y ago

Would you care to elaborate how one would start implementing a DNS that goes directly to the ROOT? Honestly interested here.

znpy 6y ago
If you don't specify a forwarder in the bind9 configuration it should query the root DNS servers directly, iirc.
liv-io 6y ago
I'd recommend you to use Unbound and specify the named.root or (root.hints) file: https://www.internic.net/domain/named.root https://www.internic.net/domain/named.root This Ansible role takes care of configuring it all (CentOS): https://github.com/liv-io/ansible-roles-centos/tree/master/unbound https://github.com/liv-io/ansible-roles-centos/tree/master/u... I have it for FreeBSD and OpenBSD too: https://github.com/liv-io/ansible-roles-bsd/tree/master/unbound https://github.com/liv-io/ansible-roles-bsd/tree/master/unbo...
aeden 6y ago
I think the post is suggesting running your own local resolver instead of using a public resolver or an ISP resolver.
adrian_b 6y ago
For example you may use the open-source program "dnscache" from Daniel Bernstein. I have been using this program on all my computers, during the last almost twenty years, without problems.
louwrentius 6y ago
I think just running bind without a resolver is enough. Make sure you keep bind and thus the roots.hints file up-to-date.
quesera 6y ago
To amplify other replies: DNS is very easy to run yourself. I use, and highly recommend, Unbound[1] as a caching resolver, and NSD[2] as an authoritative nameserver. A caching resolver is used for ordinary lookups. If the address for "ycombinator.com" isn't in the cache, the resolver starts at the root and recursively finds the authority for the domain, gets the answer, caches it, and returns it to you. You run this for general usage, and you point your desktop/laptop computers to this address. Google runs their public resolver at "8.8.8.8", etc. An authoritative nameserver is the ultimate authority on the lookup results for a specific domain. All lookups by other people eventually reach the authoritative nameserver for an answer. You run this for domains that you own, and configure it in your domain record. (Both can be a bit more complicated than that, but they don't need to be) These two services need almost zero care and feeding. Set them up once, and you can basically forget about them for years. This article only discusses resolvers, which are literally set-and-forget. Authoritative nameservers only need maintenance if you make changes to your domain. (And if you don't have your own domains, you don't need an authoritative nameserver at all). [1] Unbound: https://www.nlnetlabs.nl/projects/unbound/about/ https://www.nlnetlabs.nl/projects/unbound/about/ [2] NSD: https://www.nlnetlabs.nl/projects/nsd/about/ https://www.nlnetlabs.nl/projects/nsd/about/
- jrnichols 6y ago
  This is also how pi-hole likes to be run. https://docs.pi-hole.net/guides/unbound/ https://docs.pi-hole.net/guides/unbound/

unilynx 6y ago

simply not using your ISP's DNS servers doesn't make your DNS traffic invisible to them. unless your ISP actively messes with the DNS responses, I'm not sure if you're gaining any privacy by going to the root directly

tie_ 6y ago

> I experienced how many good tech people don’t understand DNS... Totally agree there. Root DNS servers would not answer your computer's (stub resolver's) _recursive_ query. You do need a recursive resolver to do that - whether ran by an ISP or by yourself.

merlyn 6y ago

One of the problems mentioned in the article is that all major browsers are starting to automatically set your browser to ignore system settings and just go to Cloudflare or Google DoH servers. No matter what you do locally (unless you locally serve the do-not-auto-doh flag), you'll have to touch each of your browsers on each system to not have this behavior.