Pi-hole+Unbound constant SERVFAIL

Help
1

Set up

This is for a home network, using a GL.iNET Flint2 router, a Pi 4, and a few home devices (laptop, phones, tv, etc.).

I followed the set up guide for pi-hole and unbound and it all seemed to work as planned. Except when I actually set unbound as the DNS in pi-hole and then nothing worked. Now, I get SERVFAIL constantly. I looked around online quite hard and really tried to make it work, but to no avail. I made sure that the time is right on unbound. And, actually, I came to be pretty sure that the issues was with unbound, but now I also see that my router sometimes makes endless requests to the same servers and I now wonder whether this can be the source of the problem. I add a screen capture below that shows it happening even after changing pi-hole's DNS from unbound (127.0.0.1#5335) to Quad9. I kinda have the feeling that was not always happening, though. Any ideas?

Expected Behaviour:

Pi-hole and unbound would resolve DNS queries and dig should show "NOERROR"

Actual Behaviour:

All queries lead to "SERVFAIL"

Debug Token:

https://tricorder.pi-hole.net/fmwdPVYh/

sudo grep -v '#\|^$' -R /etc/unbound/unbound.conf*
/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:server:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:    auto-trust-anchor-file: "/var/lib/unbound/root.key"
/etc/unbound/unbound.conf.d/remote-control.conf:remote-control:
/etc/unbound/unbound.conf.d/remote-control.conf:  control-enable: yes
/etc/unbound/unbound.conf.d/remote-control.conf:  control-interface: /run/unbound.ctl
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf:    logfile: "/var/log/unbound/unbound.log"
/etc/unbound/unbound.conf.d/pi-hole.conf:    log-time-ascii: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    verbosity: 3
/etc/unbound/unbound.conf.d/pi-hole.conf:    interface: 127.0.0.1
/etc/unbound/unbound.conf.d/pi-hole.conf:    port: 5335
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-ip4: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-udp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-tcp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefer-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    harden-glue: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    harden-dnssec-stripped: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    use-caps-for-id: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    edns-buffer-size: 1232
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefetch: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    num-threads: 1
/etc/unbound/unbound.conf.d/pi-hole.conf:    so-rcvbuf: 1m
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 192.168.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 169.254.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 172.16.0.0/12
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 10.0.0.0/8
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: fd00::/8
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: fe80::/10

timedatectl
               Local time: Thu 2024-02-22 00:04:58 CET
           Universal time: Wed 2024-02-21 23:04:58 UTC
                 RTC time: n/a
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

dig dnssec.works @127.0.0.1 -p 5335
; <<>> DiG 9.18.24-1-Debian <<>> dnssec.works @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6136
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dnssec.works.			IN	A

;; Query time: 63 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Thu Feb 22 00:05:22 CET 2024
;; MSG SIZE  rcvd: 41

Screenshot 2024-02-22 alle 00.10.03
Screenshot 2024-02-22 alle 00.10.031792×1398 407 KB

2

There appears to be some related problems.

1/ Pi-hole is configured to use wireless wlan0 but only the wired eth1 has an IP address. To fix that, run

pihole -r

and select Reconfigure and then select eth1 when prompted.

2/ The router is the DHCP server and is giving itself out to clients to use as the DNS server. That means that the Pi-hole has to be configured in the router as the upstream "WAN" DNS in order to be used. This is fine but it means that Pi-hole sees all queries originating from your router, not the individual clients themselves.

This, in turn, can trip Pi-hole's rate-limiting feature, and this has happened in your case. Once that has tripped, all queries from the router are blocked.

The better choice is to reconfigure the router's DHCP so that it hands out the Pi-hole IP as the "LAN" DNS, and return the "WAN' DNS to its default setting (likely your ISP's DNS servers or a service such as Google's). Pi-hole will still see all the queries, but now they will be spread out and coming from the clients themselves, plus you will be able to see what each client is requesting, which is useful for better control.

If desired, or for testing, rate-limiting can be disabled in Settings > DNS and setting both values to 0.

3/ This ties in to the previous one. Pi OS has your router listed as the DNS server to use. This may cause a DNS loop in some cases. It is best to set the OS nameserver to be an external service, or, if the previous problem has been sorted out, leave it as the router.

1 Like
3

Hi chrislph, Thank you SO MUCH for the detailed reply. It's really useful for noobs to get some explanations about what might be happening. Let me try and get to the points in order.

1/ That would make sense. Initially, the pi was connecting via wifi, so it was set up with wlan0. Now it's plugged directly into the router on a lan port. But I didn't make subsequent interface changes because I am not yet really sure what they mean (I tried to play around but nothing changed so I reverted to wlan0). So, if I get that right, doing "pihole -r/reconfigure/eth1" is all that needed for this? Will this have an impact on the pi's ip address (which is currently static and set to 192.168.8.101 -- does that work with eth1?).

2/ That makes a lot of sense. So, if I get that right, I should keep the pi on the lan ethernet port as it is and keep the dhcp of the router (which currently handles it, not the pi). However, I should revert the change I made to the router whereby I gave the pi's static address as DNS because that's the WAN DNS, and it should therefore be something like NextDNS, for instance. I can do that. I am more confused about the DHCP configuration to set the pi as LAN DNS; how does this work? I do not remember seeing anything about LAN DNS in the router's settings? (incidentally: does this have anything to do with the "local DNS" in pi-hole settings?)

3/ This I am not sure I understand. Where exactly do you see that pi-os lists the router as DNS server to use? All I see is the use of 127.0.0.1#5335 which is unbound, right? What am I missing? And how would I go about changing that? (in the last picture, the queries were sent to Quad9 instead, as I have changed back from unbound to Quad9 for testing).

Thanks again!

4

Ok, quick update: I did reconfigure the pi (step 1) and found the way to set the pi as lan DNS in the router's advanced DHCP settings (step 2; had not seen there was an advanced menu).

Results are mixed. The requests are no longer associated with the router itself (I see the clients in pi-hole) and there is therefore no rate-limiting applied (hurray).

However, there are (seemingly) random SERVFAILs still. Like, I connected to a website and it worked, however the connection to the CDN of that website did not. I ssh-ed into the pi to use dig directly on unbound and the result is the same (which leads me to think that pi-hole works well and that the issue is with unbound itself).

So:

; <<>> DiG 9.18.24-1-Debian <<>> website @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36105
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
website.			IN	A

;; ANSWER SECTION:
website.		104	IN	A	website-ip

;; Query time: 3 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Thu Feb 22 15:23:23 CET 2024
;; MSG SIZE  rcvd: 52

But:

; <<>> DiG 9.18.24-1-Debian <<>> cdn.website @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45105
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cdn.website.			IN	A

;; Query time: 67 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Thu Feb 22 15:23:35 CET 2024
;; MSG SIZE  rcvd: 40

And a number of other websites also lead to SERVFAIL. Any ideas? I am still unsure about step 3 from your message.

5

Any hints?

6

It may depend on the domain's full configuration. Would you be able to give an example of a domain where the main domain works but the CDN subdomain gives a fail? Worth taking a look at one in more detail, and then there's an extra logging option in Unbound which helps reveal what it is seeing, if needed.

Your debug log showd that /etc/resolv.conf was configured with

nameserver <your router IP>

This is the nameserver used by the operating system itself for any queries, eg during updates. However the router was pointing at Pi-hole, ie back to the same device, where Pi-hole would then answer and send the query to its own upstream server. If Pi-hole breaks or is blocking a domain needed by the OS, it can get in the way of fixing or updating itself. Best avoided.

Now that you have adjusted your router so it's not pointing at the Pi-hole, and hopefully have changed its "WAN DNS" back to use an external service (such as your ISP's DNS), you can leave that file as it is, since it will send OS queries to the router which will send them externally.

The trick is to set the OS's IP address first on the interface you will be using. Then, once you're happy that's in place and working, run the Pi-hole Reconfigure and tell it to use that interface when prompted.

If you're using the latest Pi OS, that defaults to using Network Manager for the network. There's a handy user interface available which makes it easy to use. You can use cursor keys, Tab and Enter to move around and select things. You can run that using the command

sudo nmtui

No they're not related. Local DNS lets you create your own DNS records for your network. For example maybe you have a security camera you access by going to http://192.168.1.200. Local DNS would let you give that IP a name, like camera.lan, and then you can use http://camera.lan, which is more friendly.

8

Thanks a bunch! I guess the main thing is then to investigate the fails further. The example I gave was because it seemed weird that a subdomain would be blocked, but many regular domains (incl. google and others) were blocked. How would I go investigating further? Increase verbosity and post here?

9

As above, do you have a concrete example of a domain which works but its cdn subdomain does not work?

Unbound has an option to log validations. This may help shed light on what Unbound thinks it is seeing. To enable this, first of all enable a dedicated log file as per the guide ("Add logging to unbound") if you have not already done so. In your case it looks like you aleady have done.

Next, edit the file at /etc/unbound/unbound.conf.d/pi-hole.conf and add in the line below after the verbosity line (doesn't really matter where you enter it, but better there for tidyness)

val-log-level: 2

From the Unbound docs:

val-log-level: <number>
Have the validator print validation failures to the log. Re-
gardless of the verbosity setting. Default is 0, off. At 1,
for every user query that fails a line is printed to the logs.
This way you can monitor what happens with validation. Use a
diagnosis tool, such as dig or drill, to find out why validation
is failing for these queries. At 2, not only the query that
failed is printed but also the reason why Unbound thought it was
wrong and which server sent the faulty data.

You might also want to reduce the verbosity level from 3 back down to 0, to just leave the validation logging in there and make it easier to browse.

Finally, restart Unbound

sudo service unbound restart

Now visit a site where you are seeing a SERVFAIL, and after that take a look at the validation info in the Unbound log. Does it reveal anything of interest?

A note for later on once this is all fixed – you can comment out the val-log-level item with a # and return verbosity to 0 and restart Unbound. That will prevent the log from growing out of control in normal use. If the log is already quite large and needs zeroing out, you can do this to the live log with the command:

truncate -s 0 /var/log/unbound/unbound.log
10

Thanks, Chris. So this morning I re-set the Pi/Unbound as lan DNS. As first, all worked on Bae's laptop. However, after a restart, almost nothing worked. I say "almost" because google.com did not work, but google.de worked. Major newspapers or shopping websites did not work. Somehow wikipedia worked. So I did what you said about the log and got the following, which seems like a DNSSEC issue, right?

Feb 26 09:36:05 unbound[58347:0] info: validation failure <sentry.io. A IN>: No DNSKEY record from 192.36.148.17 for key io. while building chain of trust
Feb 26 10:10:45 unbound[58347:0] info: validation failure <lb._dns-sd._udp.lan. PTR IN>: no DNSSEC records from 202.12.27.33 for DS lan. while building chain of trust
Feb 26 10:10:45 unbound[58347:0] info: validation failure <db._dns-sd._udp.lan. PTR IN>: no DNSSEC records from 202.12.27.33 for DS lan. while building chain of trust
Feb 26 10:10:45 unbound[58347:0] info: validation failure <b._dns-sd._udp.lan. PTR IN>: no DNSSEC records from 202.12.27.33 for DS lan. while building chain of trust
Feb 26 10:39:23 unbound[58347:0] info: validation failure <dns.adguard.com. HTTPS IN>: SERVFAIL no DS for DS adguard.com. while building chain of trust
Feb 26 10:39:23 unbound[58347:0] info: validation failure <dns.adguard.com. A IN>: SERVFAIL no DS for DS adguard.com. while building chain of trust
Feb 26 10:39:23 unbound[58347:0] info: validation failure <dns.adguard.com. A IN>: SERVFAIL no DS for DS adguard.com. while building chain of trust
Feb 26 10:39:23 unbound[58347:0] info: validation failure <dns.adguard.com. HTTPS IN>: SERVFAIL no DS for DS adguard.com. while building chain of trust
Feb 26 10:41:36 unbound[58347:0] info: validation failure <captive.apple.com. A IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 26 10:41:36 unbound[58347:0] info: validation failure <captive.apple.com. HTTPS IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 26 10:41:36 unbound[58347:0] info: validation failure <captive.apple.com. HTTPS IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 26 10:41:36 unbound[58347:0] info: validation failure <captive.apple.com. A IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 26 10:41:40 unbound[58347:0] info: validation failure <push.apple.com. TXT IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.apple.com.>
Feb 26 10:41:40 unbound[58347:0] info: validation failure <sentry.io. A IN>: No DNSKEY record from 199.7.83.42 for key io. while building chain of trust
Feb 26 10:41:40 unbound[58347:0] info: validation failure <gsa.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.apple.com. A >
Feb 26 10:41:40 unbound[58347:0] info: validation failure <gsa.apple.com. HTTPS IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.apple.com>
Feb 26 10:41:40 unbound[58347:0] info: validation failure <1-courier.push.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.ap>
Feb 26 10:41:40 unbound[58347:0] info: validation failure <1-courier.sandbox.push.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <ca>
Feb 26 10:41:40 unbound[58347:0] info: validation failure <time.euro.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.apple.c>
Feb 26 10:41:40 unbound[58347:0] info: validation failure <db._dns-sd._udp.lan. PTR IN>: no DNSSEC records from 202.12.27.33 for DS lan. while building chain of trust
Feb 26 10:41:40 unbound[58347:0] info: validation failure <b._dns-sd._udp.lan. PTR IN>: no DNSSEC records from 202.12.27.33 for DS lan. while building chain of trust
Feb 26 10:41:40 unbound[58347:0] info: validation failure <lb._dns-sd._udp.lan. PTR IN>: no DNSSEC records from 192.203.230.10 for DS lan. while building chain of trust
Feb 26 10:41:40 unbound[58347:0] info: validation failure <db._dns-sd._udp.lan. PTR IN>: key for validation lan. is marked as invalid because of a previous validation failure <lb._dns-sd._udp.lan>
Feb 26 10:41:40 unbound[58347:0] info: validation failure <lb._dns-sd._udp.lan. PTR IN>: key for validation lan. is marked as invalid because of a previous validation failure <lb._dns-sd._udp.lan>
Feb 26 10:41:40 unbound[58347:0] info: validation failure <api.smoot.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.apple.c>
Feb 26 10:41:40 unbound[58347:0] info: validation failure <api.smoot.apple.com. HTTPS IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.app>
Feb 26 10:41:41 unbound[58347:0] info: validation failure <init.ess.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.apple.co>
Feb 26 10:41:41 unbound[58347:0] info: validation failure <pds-init.ess.apple.com. HTTPS IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.>
Feb 26 10:41:41 unbound[58347:0] info: validation failure <www.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.apple.com. A >
Feb 26 10:41:41 unbound[58347:0] info: validation failure <init.ess.apple.com. HTTPS IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.appl>
Feb 26 10:41:41 unbound[58347:0] info: validation failure <pds-init.ess.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.appl>
Feb 26 10:41:41 unbound[58347:0] info: validation failure <gspe35-ssl.ls.apple.com. HTTPS IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive>
Feb 26 10:41:41 unbound[58347:0] info: validation failure <init-p01md.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.apple.>
Feb 26 10:41:41 unbound[58347:0] info: validation failure <gspe35-ssl.ls.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.app>
Feb 26 10:41:41 unbound[58347:0] info: validation failure <init-p01md.apple.com. HTTPS IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.ap>
Feb 26 10:41:41 unbound[58347:0] info: validation failure <init.itunes.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.apple>
Feb 26 10:41:41 unbound[58347:0] info: validation failure <mesu.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.apple.com. A>
Feb 26 10:41:41 unbound[58347:0] info: validation failure <mesu.apple.com. HTTPS IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.apple.co>
Feb 26 10:41:43 unbound[58347:0] info: validation failure <api.apple-cloudkit.com. A IN>: SERVFAIL no DS for DS apple-cloudkit.com. while building chain of trust
Feb 26 10:41:43 unbound[58347:0] info: validation failure <gateway.icloud.com. A IN>: SERVFAIL no DS for DS icloud.com. while building chain of trust
Feb 26 10:41:43 unbound[58347:0] info: validation failure <gateway.icloud.com. HTTPS IN>: SERVFAIL no DS for DS icloud.com. while building chain of trust
Feb 26 10:41:43 unbound[58347:0] info: validation failure <setup.icloud.com. HTTPS IN>: key for validation icloud.com. is marked as invalid because of a previous validation failure <gateway.iclou>
Feb 26 10:41:43 unbound[58347:0] info: validation failure <setup.icloud.com. A IN>: key for validation icloud.com. is marked as invalid because of a previous validation failure <gateway.icloud.co>
Feb 26 10:41:43 unbound[58347:0] info: validation failure <p122-acsegateway.icloud.com. HTTPS IN>: key for validation icloud.com. is marked as invalid because of a previous validation failure <ga>
Feb 26 10:41:43 unbound[58347:0] info: validation failure <p122-acsegateway.icloud.com. A IN>: key for validation icloud.com. is marked as invalid because of a previous validation failure <gatewa>
Feb 26 10:41:43 unbound[58347:0] info: validation failure <mask-api.icloud.com. A IN>: key for validation icloud.com. is marked as invalid because of a previous validation failure <gateway.icloud>
Feb 26 10:41:43 unbound[58347:0] info: validation failure <api.apple-cloudkit.com. A IN>: SERVFAIL no DS for DS apple-cloudkit.com. while building chain of trust
Feb 26 10:41:44 unbound[58347:0] info: validation failure <p122-fmip.icloud.com. HTTPS IN>: key for validation icloud.com. is marked as invalid because of a previous validation failure <gateway.i>
Feb 26 10:41:44 unbound[58347:0] info: validation failure <p122-fmip.icloud.com. A IN>: key for validation icloud.com. is marked as invalid because of a previous validation failure <gateway.iclou>
Feb 26 10:41:44 unbound[58347:0] info: validation failure <init.itunes.apple.com. HTTPS IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.a>
Feb 26 10:41:44 unbound[58347:0] info: validation failure <gateway.icloud.com. HTTPS IN>: SERVFAIL no DS for DS icloud.com. while building chain of trust
Feb 26 10:41:44 unbound[58347:0] info: validation failure <gateway.icloud.com. A IN>: SERVFAIL no DS for DS icloud.com. while building chain of trust
Feb 26 10:41:44 unbound[58347:0] info: validation failure <bag.itunes.apple.com. HTTPS IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <captive.ap>
11

This issue is actually still valid. Sometimes connections will stall for numerous websites for about 10-15 minutes and only then start working. DNSSEC issue?

12

Thanks for trying that and posting the log. It looks like the cause of what you're seeing, but I don't know how to interpret what it's saying in terms of a Pi-hole + Unbound setup. Any advice welcomed from the forum.

Out if interest how did you install Unbound, was it manually or via apt?

13

I followed the pi-hole manual: unbound - Pi-hole documentation

And it just continues randomly...

Feb 28 18:10:53 unbound[58347:0] info: validation failure <goog. A IN>: no signatures from 192.58.128.30
Feb 28 18:10:53 unbound[58347:0] info: validation failure <google. A IN>: no signatures from 198.41.0.4
Feb 28 18:36:53 unbound[58347:0] info: validation failure <info. A IN>: no signatures from 192.58.128.30
Feb 28 18:44:51 unbound[58347:0] info: validation failure <info. A IN>: no signatures from 202.12.27.33
Feb 28 18:44:57 unbound[58347:0] info: validation failure <5-courier.push.apple.com. A IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 28 18:44:57 unbound[58347:0] info: validation failure <5-courier.push.apple.com. HTTPS IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 28 18:44:57 unbound[58347:0] info: validation failure <5-courier.push.apple.com. HTTPS IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 28 18:44:57 unbound[58347:0] info: validation failure <5-courier.push.apple.com. A IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 28 18:45:06 unbound[58347:0] info: validation failure <www.wu.ac.at. A IN>: No DNSKEY record from 199.7.91.13 for key at. while building chain of trust
Feb 28 18:45:06 unbound[58347:0] info: validation failure <www.wu.ac.at. HTTPS IN>: No DNSKEY record from 199.7.91.13 for key at. while building chain of trust
Feb 28 18:52:41 unbound[58347:0] info: validation failure <gdmf.apple.com. HTTPS IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 28 18:52:41 unbound[58347:0] info: validation failure <gdmf.apple.com. A IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 28 18:52:42 unbound[58347:0] info: validation failure <xp.apple.com. HTTPS IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <gdmf.apple.com. A >
Feb 28 18:52:42 unbound[58347:0] info: validation failure <xp.apple.com. A IN>: key for validation apple.com. is marked as invalid because of a previous validation failure <gdmf.apple.com. A IN>:>
Feb 28 18:52:42 unbound[58347:0] info: validation failure <gdmf.apple.com. A IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 28 18:52:42 unbound[58347:0] info: validation failure <gdmf.apple.com. HTTPS IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 28 18:59:36 unbound[58347:0] info: validation failure <gs-loc.apple.com. HTTPS IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 28 18:59:36 unbound[58347:0] info: validation failure <gs-loc.apple.com. A IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 28 18:59:36 unbound[58347:0] info: validation failure <gs-loc.apple.com. HTTPS IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 28 18:59:36 unbound[58347:0] info: validation failure <gs-loc.apple.com. A IN>: SERVFAIL no DS for DS apple.com. while building chain of trust
Feb 28 19:02:53 unbound[58347:0] info: validation failure <www.google.at. HTTPS IN>: No DNSKEY record from 199.7.83.42 for key at. while building chain of trust
Feb 28 19:02:53 unbound[58347:0] info: validation failure <www.google.at. A IN>: No DNSKEY record from 202.12.27.33 for key at. while building chain of trust
Feb 28 19:54:34 unbound[58347:0] info: validation failure <chat.signal.org. A IN>: No DNSKEY record from 192.58.128.30 for key org. while building chain of trust
Feb 28 19:54:34 unbound[58347:0] info: validation failure <ud-chat.signal.org. HTTPS IN>: key for validation org. is marked as invalid because of a previous validation failure <chat.signal.org. A>
Feb 28 19:54:34 unbound[58347:0] info: validation failure <ud-chat.signal.org. A IN>: key for validation org. is marked as invalid because of a previous validation failure <chat.signal.org. A IN>>
Feb 28 19:54:34 unbound[58347:0] info: validation failure <chat.signal.org. HTTPS IN>: key for validation org. is marked as invalid because of a previous validation failure <chat.signal.org. A IN>
Feb 28 19:54:35 unbound[58347:0] info: validation failure <updates2.signal.org. HTTPS IN>: key for validation org. is marked as invalid because of a previous validation failure <chat.signal.org. >
Feb 28 19:54:35 unbound[58347:0] info: validation failure <updates2.signal.org. A IN>: key for validation org. is marked as invalid because of a previous validation failure <chat.signal.org. A IN>
Feb 28 19:54:35 unbound[58347:0] info: validation failure <updates2.signal.org. A IN>: key for validation org. is marked as invalid because of a previous validation failure <chat.signal.org. A IN>
Feb 28 19:54:35 unbound[58347:0] info: validation failure <updates2.signal.org. HTTPS IN>: key for validation org. is marked as invalid because of a previous validation failure <chat.signal.org. >
Feb 28 20:25:05 unbound[58347:0] info: validation failure <at. A IN>: no signatures from 192.36.148.17
Feb 28 20:25:06 unbound[58347:0] info: validation failure <io. A IN>: no signatures from 198.97.190.53
Feb 28 20:25:08 unbound[58347:0] info: validation failure <c2.piano.io. HTTPS IN>: no DNSSEC records from 173.245.59.118 for DS piano.io. while building chain of trust
Feb 28 20:25:08 unbound[58347:0] info: validation failure <c2.piano.io. A IN>: no DNSSEC records from 173.245.59.118 for DS piano.io. while building chain of trust
Feb 28 20:25:08 unbound[58347:0] info: validation failure <c2.piano.io. A IN>: no DNSSEC records from 172.64.32.112 for DS piano.io. while building chain of trust
Feb 28 20:25:08 unbound[58347:0] info: validation failure <c2.piano.io. HTTPS IN>: no DNSSEC records from 172.64.32.112 for DS piano.io. while building chain of trust
Feb 28 21:32:06 unbound[58347:0] info: validation failure <cdn.ampproject.org. A IN>: No DNSKEY record from 199.7.83.42 for key org. while building chain of trust
Feb 28 21:32:06 unbound[58347:0] info: validation failure <cdn.ampproject.org. HTTPS IN>: No DNSKEY record from 192.58.128.30 for key org. while building chain of trust
Feb 28 21:44:26 unbound[58347:0] info: validation failure <org. A IN>: no signatures from 198.97.190.53
Feb 28 21:44:27 unbound[58347:0] info: validation failure <chat.signal.org. A IN>: no DNSSEC records from 205.251.193.129 for DS signal.org. while building chain of trust
Feb 28 21:44:27 unbound[58347:0] info: validation failure <chat.signal.org. HTTPS IN>: no DNSSEC records from 205.251.193.129 for DS signal.org. while building chain of trust
Feb 28 21:44:27 unbound[58347:0] info: validation failure <chat.signal.org. A IN>: key for validation signal.org. is marked as invalid because of a previous validation failure <chat.signal.org. H>
Feb 28 21:44:27 unbound[58347:0] info: validation failure <chat.signal.org. HTTPS IN>: key for validation signal.org. is marked as invalid because of a previous validation failure <chat.signal.or>
Feb 28 21:50:28 unbound[58347:0] info: validation failure <io. A IN>: no signatures from 198.97.190.53
14

So the router's interface had a setting to override dns settings for all clients, which was activated.

image
image615×541 74.9 KB

This overrides unencrypted DNS queries.

Deactivating it seems to have done the trick and, once emptied, the unbound log no longer fills up.

1 Like
15

Thanks for the info. I wonder why it wasn't doing it for all domains though, eg you mentioned google.de and wikipedia worked.

I like how the router calls it "DNS Rebinding Attack Protection". [ Edit: My mistake, that is a legit option to prevent against DNS rebind attacks, not a fancy way of saying they are redirecting DNS to prevent attacks! It's the second option which is messing with the DNS here ].

Same as the various AV products which explain how they "protect against DNS hijacking". And they do this by... hijacking the DNS themselves instead. And they claim it protects privacy and stops the likes of Cloudflare from seeing your queries... by making it so that they see all your queries instead.

It crops up in here quite steadily. It might not normally be noticeable, but when Pi-hole is in the mix it becomes apparent that something is screwing with DNS.

Anyway, mini rant over, I'm glad you're sorted and back in control of your DNS!

18

Interesting way to think about it. I had not assumed this would be akin to DNS hijacking.

As for why some things went through and not others, I have no explanation. From the device's perspective, it definitely wasn't as if there was no connection at all; some things would work and others would drop.

PS: is "DNS Rebinding Attack Protection" worth using, then?

19

If you have services running internally on domain names, for sure, but it won't do any harm leaving on anyway, which looks like it was the default state.

20

Ah, no, that wasn't an actual picture from my system. But I'll try turning it on.

For reference, for anyone using a GL.iNet Flint 2, it turns out that setting the pi-hole's address as lan dns for the guest network conflicts with settings to force all traffic to the pi in the advance settings (the port forward, I guess). When both are set up, it can mess up the connection; my smart radio would not connect. The moment I removed the pi's address from the lan dns for the guest network (but kept the port forward), the smart radio started showing in the pi's dashboard. Meanwhile the tv worked the whole time. Go figure.

21

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.