Alternative upstream DNS (Unbound)

[msatter]

I was really enthusiastic after reading this blog posting and after some work I had implemented it and it seemed to work very well.

FTLDNS and Unbound Combined For Your Own All-Around DNS Solution

Then came the disappointment that some big firms do sabotage this way of resolving DNS requests.

Unbound does not offer a solution for that and point to Knot to do this. Having two upstream DNS servers next to Pi-hole on the same device is even to me a overkill.

So I want to request a possibility to have a alternative upstream server in Pi-hole.
This alternative upstream server is queried when there is a N/A or time out that can be set by the user starting at two seconds.

As a alternative can be one of the default DNS servers in pihole or added manually.

This is a unusual way of handling a problem but we are confronted by firms that do not like that we have this freedom.

[msatter]

I have found a way to work around this by adding each individual domain to a forward-zone to the unbound configuration.

forward-zone: name: "microsoft.com"	forward-first: yes forward-addr: 8.8.8.8
forward-zone: name: "microsoft.net"	forward-first: yes forward-addr: 8.8.8.8
forward-zone: name: "azure.com"		forward-first: yes forward-addr: 8.8.8.8
forward-zone: name: "azure.net"		forward-first: yes forward-addr: 8.8.8.8
forward-zone: name: "windows.com"	forward-first: yes forward-addr: 8.8.8.8
forward-zone: name: "windows.net"	forward-first: yes forward-addr: 8.8.8.8
forward-zone: name: "hotmail.com"	forward-first: yes forward-addr: 8.8.8.8 

On this page you can see the domain owned by Microsoft and the list is very long…almost 50.000 domains:

https://myip.ms/browse/sites/1/ownerID/198615/ownerID_A/1

[jfb]

Then came the disappointment that some big firms do sabotage this way of resolving DNS requests.

Please elaborate on this. Thanks.

[msatter]

Every time I encounter that this method does not work I see at the end of the string Microsoft.

Till now I did not see any other domain not being resolved by unbound spilitting up the information to authorized servers.

[jfb]

I’m confused. If you dig microsoft.com using unbound, you get several valid IP addresses back. What is the problem?

dig microsoft.com -p 5353

; DiG 9.10.3-P4-Raspbian; microsoft.com -p 5353
;; global options: +cmd
;; Got answer:
;; HEADER;- opcode: QUERY, status: NOERROR, id: 30379
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;microsoft.com. IN A

;; ANSWER SECTION:
microsoft.com. 3550 IN A 23.96.52.53
microsoft.com. 3550 IN A 191.239.213.197
microsoft.com. 3550 IN A 104.40.211.35
microsoft.com. 3550 IN A 104.43.195.251
microsoft.com. 3550 IN A 23.100.122.175

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Wed Sep 19 12:36:14 CDT 2018
;; MSG SIZE rcvd: 122

[msatter]

Do you used qname or a forward-zone to an upstream DNS server?

[jfb]

I use qname minimisation. Other than that, it’s the default installation of unbound per the guide.

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

[msatter]

That is really strange and I get no reply from that server but then I have to check with my firewall that it is not blocking requests to Microsoft. That would be a easy fix.

I found an interesting posting with a link to a document which is mentioning more domains that then would not resolve and according to how do. Microsoft was not mentioned in that document.

Unbound and QNAME minimisation

I ran a test on the web addresses listed in the referenced document (page 34 of 42 in the document) with QNAME minimisation enabled - I was able to resolve them all with dig. I suspect that since the date of that paper (May 2015) the noted problems at the authoritative name servers have been corrected. I am running two setups of unbound and Pi-Hole; identical but on different Pi’s. One has QNAME off, the other has QNAME on. I cannot see any different in DNS resolution between the two. I be…

[jfb]

I get no reply from that server

Which server is this?

[msatter]

One sec, I am now peeking an poking in the firewall and unbound…

The logs in the firewall is showing now the blocked IP addresses when querying for a Microsoft domain.

The addresses that where on the telemetry IP address list and where needed to resolve Microsoft domains are:

193.221.113.53
208.84.0.53
208.84.2.53
208.76.45.53

And confirmed by myip.ms

ns1.msft.net [1,268 sites] (208.84.0.53)
ns2.msft.net [1,223 sites] (208.84.2.53)
ns3.msft.net [1,285 sites] (193.221.113.53)
ns4.msft.net [1,284 sites] (208.76.45.53)

This was not a good day for me and thanks for helping me to solve this.

I am still standing behind the idea of having a alternative DNS server. Primary and secondary works differently.

ps. I am running Unbound 1.80 (Sid), on Jessie, released 10 September

[jfb]

Primary and secondary DNS work the same. A query goes to a DNS server, and an IP is provided in response. The DNS server does not know if it was a “primary” or “secondary” choice. It just receives a stream of requests and answers them.

Unbound works well because it directly queries the root and other authoritative servers, with no filtering on either the request or the reply.

It would make no sense for Microsoft or other companies to interfere with this process, since they want people to find their domains and use them. Additionally, the root and authoritative name servers are independent and not run by those same large corporations.

What is your purpose in using forward zones?

[msatter]

Primary and secondary in Pi-hole are selected on the speed they receive responses from the upstream server. After a time it is changed to the other upstream server to see how fast that one is. This is whart I am told here.

I only use one upstream server because that provides DNSSEC and the second one does not. I am sticking now with qname.

The forward-zone is needed if you use with unbound one or more upstream server instead of qname.

As soon you put a forward zone with a “.” then you are disabling qname because the forward-zone has priority. It is very rudimental I had to create for each domain.tld a zone. This zone luckily covers then also the subdomains.

forward-zone:
        name: "."	
        forward-addr: 8.8.8.8

Every domain will be send to upstream server 8.8.8.8

[jfb]

I am sticking now with qname.

I don’t understand this. qname is not a process, it’s a shorthand description of 'fully qualified name."

The forward-zone is needed if you use with unbound one or more upstream server instead of qname.

I don’t believe this is correct. With unbound setup per the guide referenced above, it communicates directly to the root and authoritative servers. This is not a function of qname minimisation.

The qname-minimsation option shortens the request to the higher level servers, as explained here (https://nlnetlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf). With this option enabled, your DNS resolver provides each level of authoritative name server with just enough information to get to the next server, instead of a complete domain request to each level.

What are you trying to achieve by having unbound talk to an upstream DNS server directly? That essentially defeats the reason most people use unbound (to avoid using third party DNS servers).

[msatter]

Name is the default way to resolve and before that it was optional. It is switched, I think from 1.73.

Unbound is more than only simple DNS server and I moved all local domains to unbound already.

The reason was that the upstream server was inside the VPN network so no reqeust I made was getting out the private network except for the traffic itself.

I have now workout for myself if I use my ISP network for resolving directly or multiple VPN connections and so scattering even more the DNS traffic.

[mrpink57]

I actually had a similar issue with unbound and this issue. I am not sure what fixed it out of the blue but I think your helping me resolve my root hints did a lot of it. I assume your other root resolves worked fine which mine did too. But after fixing NTP I do not have these issues anymore.

MS is always been a throne in my side with dns resolution. I would just throw them on a forward zone until resolved. I used to keep a copy of dnscrypt v2 running for forward zones if needed or keep cloudflared DOH running for these moments.

What you are suggesting is something I have thought about myself, if nxdoman is given try 8.8.8.8 . Is this described as a split-horizon DNS? Which I believe calomel.org talks about?

I’m still learning a lot of these configurations and terminology.

[jfb]

MS is always been a throne in my side with dns resolution. I would just throw them on a forward zone until resolved.

@mrpink57 What was the problem you were experiencing? Were you running unbound as a recursive, caching resolver (querying the authoritative name servers) and it was unable to resolve MS IP addresses?

[msatter]

Dnssec needs a correct time and it is a bit flexible if your own box is running a bit behind. If your box is running ahead of time then you can forget to have any resolving taking place.

I had here a user that could not even start unbound anymore because his box was way of time and the raspberry pi has no hardware clock.

The problems with Microsoft was due that the name servers were on the telemetry list in the firewall. Request were even not getting out of the router.

Split horizon that unbound does is the same as DNSmasq does and that overriding or creating domains with custom IP Adresses. This spoofing but a wished form of it.

[jpgpi250]

I had here a user that could not even start unbound anymore because his box was way of time and the raspberry pi has no hardware click

Install the NTP package:

sudo apt-get install ntp

Goto http://support.ntp.org/bin/view/Servers/NTPPoolServers
Select the region you are in, there will be a list of NTP servers for your region.

 sudo nano /etc/ntp.conf

Find the line # pool: <http://www.pool.ntp.org/join.html>
There are four (4) lines below this line. Replace the DNS names with the DNS names from the list. Example for Europe:

server 0.europe.pool.ntp.org iburst
server 1.europe.pool.ntp.org iburst
server 2.europe.pool.ntp.org iburst
server 3.europe.pool.ntp.org iburst

Restart the NTP service

sudo /etc/init.d/ntp restart

Check ntp servers synchronization status.

ntpq

At the ntpq prompt, enter pe.

ntpq> pe

You’ll get a list of servers, the primary server is marked with an asterisk (*). It may take a while for the synchronization to become active, repeat the command
To quit the ntpq prompt, enter quit

ntpq> quit

NTP can only do it’s thing if the raspberry pi’s time is somewhere near the real time. Once it has achieved time synchronization, it will keep the correct time for ever.

This, and more things that make your pi stable and manageable is described in my setup manual. You may have to whitelist users.telenet.be

[msatter]

Unbound is now on release 1.9.0 and the release log can be found here:

https://www.nlnetlabs.nl/svn/unbound/tags/release-1.9.0/doc/Changelog

It also available on Debian Sid.

It seems that thst is not yet starting correctly on its own and this a work-around:

It seems like chroot’ing to /etc/unbound is attempted. To workaround you
need to do this:

cat << EOF > /etc/unbound/unbound.conf.d/chroot.conf
server:
chroot: ""
EOF
service unbound restart

Regards,
Simon

[msatter]

Unbound build 1.9.0.2 is on its way and should solve the starting problem. You won’t need the chroot.conf file anymore.