Why not use default unbound dependency dns-root-data for root.hints file?

richie510 · April 7, 2020, 2:44pm

I was just scrolling through reddit and found this post:

In it someone mentioned this dns-root-data package that is a dependency of unbound. This package has the root hints file built in, and with no specific configuration, unbound will use this default root.hints file, which appears to be updated automatically by the system.

Why does the official pi-hole (and every other) user guide instruct to download the root hints manually, and specifically point to that file in the configuration files? Is there some concern about this officially included version? Is it just not well known?

Generally it just seems silly to me to add this extra step and manually download something that is already present, and already has a mechanism to keep itself updated.

DanSchaper · April 7, 2020, 4:48pm

Not everybody installs unbound via package manager.

richie510 · April 7, 2020, 4:52pm

But the official guide assumes you do, as it shows this command to install unbound:

sudo apt install unbound

https://docs.pi-hole.net/guides/unbound/

DanSchaper · April 7, 2020, 4:55pm

I guess we're just silly then!

DanSchaper · April 7, 2020, 5:06pm

github.com

pi-hole/docs/blob/eae316827f078625ad4568ebed2736583cf15c5b/docs/guides/unbound.md

### The problem: Whom can you trust?

Pi-hole includes a caching and *forwarding* DNS server, now known as *FTL*DNS. After applying the blocking lists, it forwards requests made by the clients to configured upstream DNS server(s). However, as has been mentioned by several users in the past, this leads to some privacy concerns as it ultimately raises the question: _Whom can you trust?_ Recently, more and more small (and not so small) DNS upstream providers have appeared on the market, advertising free and private DNS service, but how can you know that they keep their promises? Right, you can't.

Furthermore, from the point of an attacker, the DNS servers of larger providers are very worthwhile targets, as they only need to poison one DNS server, but millions of users might be affected. Instead of your bank's actual IP address, you could be sent to a phishing site hosted on some island. This scenario has [already happened](https://www.zdnet.com/article/dns-cache-poisoning-attacks-exploited-in-the-wild/) and it isn't unlikely to happen again...

When you operate your own (tiny) recursive DNS server, then the likeliness of getting affected by such an attack is greatly reduced.

### What *is* a recursive DNS server?

The first distinction we have to be aware of is whether a DNS server is *authoritative* or not. If I'm the authoritative server for, e.g., `pi-hole.net`, then I know which IP is the correct answer for a query. Recursive name servers, in contrast, resolve any query they receive by consulting the servers authoritative for this query by traversing the domain.
Example: We want to resolve `pi-hole.net`. On behalf of the client, the recursive DNS server will traverse the path of the domain across the Internet to deliver the answer to the question.

### What does this guide provide?

In only a few simple steps, we will describe how to set up your own recursive DNS server. It will run on the same device you're already using for your Pi-hole. There are no additional hardware requirements.

This guide assumes a fairly recent Debian/Ubuntu-based system and will use the maintainer provided packages for installation to make it an incredibly simple process. It assumes only a very basic knowledge of how DNS work.

A _standard_ Pi-hole installation will do it as follows:

This file has been truncated. show original

That's the file to edit with any proposed changes.

richie510 · April 7, 2020, 5:20pm

I believe I have suggested an edit.

My ignorance knows no bounds, however. In reviewing the original suggested config file it has this important clue:

# Use this only when you downloaded the list of primary root servers!

Based on your replies, it appears that there is no security or other issue with using the included file.

I hope it makes sense to steer new users to the most simple and straightforward solution.

jfb · April 7, 2020, 5:27pm

When you did a clean install of unbound from the package manager, where are the root.hints located on the SD card and what is the date of the file?

DanSchaper · April 7, 2020, 5:28pm

I can't say to security. We currently instruct users to download directly from the author of the file. I haven't looked at or reviewed the packaged version.

richie510 · April 7, 2020, 5:35pm

It is located in /usr/shared/dns/root.hints

I reviewed the history of the file here:

In the current unreleased version the date matches the latest February 2020 time, but the actual one in the stable version of the package manager is dated for 2019. Regardless, it appears that all of the changes in the last 2 years have just been to update the timestamp in the file, and 2 years ago one ip address was changed.

jfb · April 7, 2020, 5:43pm

I may not be following this argument. We start with "use what the package manager installs because it updates itself," but then the package manager doesn't update itself after all and you end up with an old root hints file.

Given that the package manager isn't updating it, wouldn't it be better to download and install a known fresh copy of the root.hints at the time of installing unbound?

Even though there were no changes between the two versions cited, that will not always be the case.

Should be /usr/share/dns/root.hints ?

richie510 · April 7, 2020, 5:56pm

It is my understanding that these systems take some time for anything to move through the system. The current suggestion is to update your root hints every 6 months. The package manager is well within that window. Also, the "unstable" version of this file matches the February 2020 timestamp.

jfb · April 7, 2020, 5:57pm

How is March 2019 within six months of the current root hints date March 31, 2020?

What about Stretch? That is a supported OS.

richie510 · April 7, 2020, 6:02pm

It is my understanding that March 2019 is the previous file version before February 2020. If not, I do not know how to check.

On the debian website it appears to me to be supported in jessie and stretch.

jfb · April 7, 2020, 6:03pm

Pi-hole supports Stretch (not Jessie), so users running unbound on Stretch may have a quite old root hints in the package manager.

richie510 · April 7, 2020, 6:15pm

It appears that stretch has the same time stamp in the stable version.

last update:     March 13, 2019 ;       related version of root zone:     2019031302

jfb · April 7, 2020, 6:35pm

My opinion - it is better to use the Pi-hole install guide as written and load the freshest copy of the root hints when you install unbound. Then, as recommended by the guide, update the file about every six months. That's about 2 minutes of work to do so. And, even if you don't update the file, it's still newer than the package manage was using.

DanSchaper · April 7, 2020, 6:37pm

richie510 · April 7, 2020, 6:41pm

This is all new to me, so I'm learning on the fly. As I dig deeper, it appears that stretch is no longer updating this file, but buster is keeping the file up to date with 4 commits in 2019 and one in 2020. These commits do not seem to be evenly spaced, so the maintainer must not be doing it automatically, unless they just trigger on file changes from the source.

jfb · April 7, 2020, 6:42pm

If this is the case, why is the file at /usr/share/dns/root.hints dated March 2019? What are they updating?

richie510 · April 7, 2020, 6:46pm

I may be wrong on this, but isn't there a lag between debian official and raspbian?