Pi-hole with unbound not resolving subdomain

Hi!

Maybe I am completely wrong here, but I thought you may have an idea what's going on.
After pi-hole/unbound has been running without any problems for about two years now, it suddenly started not resolving one subdomain: weatherstation.wunderground.com. wunderground.com itself is resolved fine, the subdomain however produces "temporary error in name resolution" or sometimes a timeout.

A dig response:

dig weatherstation.wunderground.com

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Raspbian <<>> weatherstation.wunderground.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18541
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Di Mär 09 18:24:13 CET 2021
;; MSG SIZE  rcvd: 60

I do have a level 4 debug log if anyone is interested, the important part may be:

[1615309613] unbound[28569:0] info: iterator operate: query weatherstation.wunderground.com. A IN
[1615309613] unbound[28569:0] debug: process_response: new external response event
[1615309613] unbound[28569:0] info: scrub for com. NS IN
[1615309613] unbound[28569:0] info: response for weatherstation.wunderground.com. A IN
[1615309613] unbound[28569:0] info: reply from <com.> 192.55.83.30#53
[1615309613] unbound[28569:0] info: incoming scrubbed packet: ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
;; flags: qr ; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 0
;; QUESTION SECTION:
wunderground.com.       IN      A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
wunderground.com.       86400   IN      NS      a11-66.akam.net.
wunderground.com.       86400   IN      NS      a10-65.akam.net.
wunderground.com.       86400   IN      NS      a1-70.akam.net.
wunderground.com.       86400   IN      NS      a14-64.akam.net.
wunderground.com.       86400   IN      NS      a13-67.akam.net.
wunderground.com.       86400   IN      NS      a24-65.akam.net.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com.   86400   IN      NSEC3   1 1 0 - ck0q1gin43n1arrc9osm6qpqr81h5m9a NS SOA RRSIG DNSKEY NSEC3PARAM ;{flags: optout}
CK0POJMG874LJREF7EFN8430QVIT8BSM.com.   86400   IN      RRSIG   NSEC3 8 2 86400 20210313054023 20210306043023 58540 com. ML/ush0Hvdw0xdTHUz8cgFeLWqTp9Zy/4OXQp9G2kIXMqHE/R9acR2lNhjS5euFMkSeKSt1FxOGtUriOEaHn9Pgpn6woncHl2iTBEyFVBhPnolnJPX3NiFOjIZs2$
D2LSED27795ECVMN8KSI2M1EFJHDJDF7.com.   86400   IN      NSEC3   1 1 0 - d2lt6a84mh8acvird6t0mn7ofg1l9h0f NS DS RRSIG ;{flags: optout}
D2LSED27795ECVMN8KSI2M1EFJHDJDF7.com.   86400   IN      RRSIG   NSEC3 8 2 86400 20210315045746 20210308044746 58540 com. PRfEfj4G/FoSrGo/bjTzzFeCiMKe6m7pLW5NMNrdkGVAZxBtugXs/F/BhO+qYI/FGtqGrEIuE3FrhvvwAVkC1Ct8SV8P6SJEG/BMjuVwhLv6iPCprgSESmy6kAJY$

;; ADDITIONAL SECTION:
;; MSG SIZE  rcvd: 716

[1615309613] unbound[28569:0] debug: iter_handle processing q with state QUERY RESPONSE STATE
[1615309613] unbound[28569:0] info: query response was REFERRAL
[1615309613] unbound[28569:0] info: negcache insert referral  com. NS IN
[1615309613] unbound[28569:0] info: negcache rr CK0POJMG874LJREF7EFN8430QVIT8BSM.com. NSEC3 IN
[1615309613] unbound[28569:0] info: negcache rr D2LSED27795ECVMN8KSI2M1EFJHDJDF7.com. NSEC3 IN
[1615309613] unbound[28569:0] info: DelegationPoint<wunderground.com.>: 6 names (6 missing), 0 addrs (0 result, 0 avail) parentNS
[1615309613] unbound[28569:0] info:   a24-65.akam.net.
[1615309613] unbound[28569:0] info:   a13-67.akam.net.
[1615309613] unbound[28569:0] info:   a14-64.akam.net.
[1615309613] unbound[28569:0] info:   a1-70.akam.net.
[1615309613] unbound[28569:0] info:   a10-65.akam.net.
[1615309613] unbound[28569:0] info:   a11-66.akam.net.
[1615309613] unbound[28569:0] debug: cleared outbound list for next round
[1615309613] unbound[28569:0] debug: iter_handle processing q with state QUERY TARGETS STATE
[1615309613] unbound[28569:0] info: processQueryTargets: weatherstation.wunderground.com. A IN
[1615309613] unbound[28569:0] debug: processQueryTargets: targetqueries 0, currentqueries 0 sentcount 0
[1615309613] unbound[28569:0] info: DelegationPoint<wunderground.com.>: 6 names (6 missing), 0 addrs (0 result, 0 avail) parentNS
[1615309613] unbound[28569:0] info:   a24-65.akam.net.
[1615309613] unbound[28569:0] info:   a13-67.akam.net.
[1615309613] unbound[28569:0] info:   a14-64.akam.net.
[1615309613] unbound[28569:0] info:   a1-70.akam.net.
[1615309613] unbound[28569:0] info:   a10-65.akam.net.
[1615309613] unbound[28569:0] info:   a11-66.akam.net.
[1615309613] unbound[28569:0] debug: attempt to get extra 3 targets
[1615309613] unbound[28569:0] info: new target a14-64.akam.net. A IN
[1615309613] unbound[28569:0] info: new target a1-70.akam.net. A IN
[1615309613] unbound[28569:0] info: new target a10-65.akam.net. A IN
[1615309613] unbound[28569:0] debug: no current targets -- waiting for 3 targets to resolve.

The interesting thing: google dns resolves the subdomain just fine to 169.63.130.179

Would be glad if anyone had any hints how to progress further on this matter.

Thanks! Mathew

Check the DNSSEC for that domain, it's not following the RFCs.

https://dnsviz.net/d/weatherstation.wunderground.com/dnssec/

Thank you for your lightning fast response!
So in this case, probably nothing I can do
But is the SHA-1 signing error not only relevant for the cloud domain and not for the .com part? Sorry just curious this is not really my area of expertise...

Is there a quickfix I might try?

First, lets make sure it really is DNSSEC that is causing the failure. The dig response shows SERVFAIL, but that's pointing to 127.0.0.1 Port 53.

What port is unbound running on?
Does dig show SERVFAIL if you directly query unbound?
What does the Pi-hole admin interface show for the queries?
Does it still fail with DNSSEC disabled on `unbound?

Yes, it still fails when DNSSEC is disabled
Unbound runs on 5353, Pi-hole runs on 53 and uses 127.0.0.1:5353 as upstream DNS

Yes, SERVFAIL also occurs when directly querying unbound

Queries to unbound:
Query wunderground.com

pi@rasp:~ $ dig wunderground.com @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Raspbian <<>> wunderground.com @127.0.0.1 -p 5353
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33418
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
wunderground.com.       3600    IN      A       92.122.254.27

;; Query time: 25 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Di Mär 09 20:17:29 CET 2021
;; MSG SIZE  rcvd: 61

Query weatherstation.wunderground.com to unbound

pi@rasp:~ $ dig weatherstation.wunderground.com @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Raspbian <<>> weatherstation.wunderground.com @127.0.0.1 -p 5353
;; global options: +cmd
;; connection timed out; no servers could be reached

Query weatherstation.wunderground.com to google

pi@rasp:~ $ dig weatherstation.wunderground.com @8.8.8.8

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Raspbian <<>> weatherstation.wunderground.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18297
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;weatherstation.wunderground.com. IN    A

;; ANSWER SECTION:
weatherstation.wunderground.com. 52 IN  CNAME   rtupdate.wunderground.com.
rtupdate.wunderground.com. 3    IN      CNAME   prod-pws-ng-ingest.pws-ng-prod-iks-wdc-01-997b58a668d15d562a6bed58ea7c5f9e-0001.us-east.containers.appdomain.cloud.
prod-pws-ng-ingest.pws-ng-prod-iks-wdc-01-997b58a668d15d562a6bed58ea7c5f9e-0001.us-east.containers.appdomain.cloud. 271 IN CNAME pws-ng-prod-iks-wdc-01-997b58a668d15d562a6bed58ea7c5f9e-0001.us-east.containers.appdomain.cloud.
pws-ng-prod-iks-wdc-01-997b58a668d15d562a6bed58ea7c5f9e-0001.us-east.containers.appdomain.cloud. 1 IN A 169.55.126.244
pws-ng-prod-iks-wdc-01-997b58a668d15d562a6bed58ea7c5f9e-0001.us-east.containers.appdomain.cloud. 1 IN A 169.61.113.60
pws-ng-prod-iks-wdc-01-997b58a668d15d562a6bed58ea7c5f9e-0001.us-east.containers.appdomain.cloud. 1 IN A 169.63.130.180
pws-ng-prod-iks-wdc-01-997b58a668d15d562a6bed58ea7c5f9e-0001.us-east.containers.appdomain.cloud. 1 IN A 169.63.130.179
pws-ng-prod-iks-wdc-01-997b58a668d15d562a6bed58ea7c5f9e-0001.us-east.containers.appdomain.cloud. 1 IN A 169.55.126.243
pws-ng-prod-iks-wdc-01-997b58a668d15d562a6bed58ea7c5f9e-0001.us-east.containers.appdomain.cloud. 1 IN A 169.61.113.58

;; Query time: 39 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Di Mär 09 20:18:08 CET 2021
;; MSG SIZE  rcvd: 321

Pi-hole shows:

2021-03-09 20:08:15 	A	weatherstation.wunderground.com	localhost	OK (forwarded)	SERVFAIL

What is your unbound.conf file contents?

server:
    # If no logfile is specified, syslog is used
    logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    port: 5353
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    # root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the servers authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # Suggested by the unbound man page to reduce fragmentation reassembly problems
    edns-buffer-size: 1472

    # TTL bounds for cache
    cache-min-ttl: 3600
    cache-max-ttl: 86400

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines
    num-threads: 1

    # Ensure kernel buffer is large enough to not loose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: 192.168.1.0/16
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: 10.8.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

Why are you modifying the TTL records?

I am? Ah, I am! Admittedly, this part is copy&paste....

Did you follow a guide to set up unbound? Are there other files in unbound.conf.d that make other changes?

I followed this guide - 2 years ago that is: unbound - Pi-hole documentation

Edit: Other files: pi-hole.conf (the unbound.conf) qname-minimisation.conf (yes) and root-auto-trust-anchor-file.conf

It's possible that you have something blocking those nameservers and that's causing the timeout. unbound is waiting for a response from those servers and nothing is coming back.

The problem definitely is in unbound and it doesn't look like it's DNSSEC. It's just a complete failure to resolve records.

That may be preventing the akamai DNS servers from sending a response. Try it without that enabled and see what happens.

set to no, restarted service, no luck

as for blocking: I wouldn't know what, Pi-hole is the only blocking thing around. Don't know if that counts, but ping is working for those servers...

Can you run dig weatherstation.wunderground.com @a1-70.akam.net

Sure

dig weatherstation.wunderground.com @a1-70.akam.net

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Raspbian <<>> weatherstation.wunderground.com @a1-70.akam.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32228
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;weatherstation.wunderground.com. IN A

;; ANSWER SECTION:
weatherstation.wunderground.com. 60 IN CNAME rtupdate.wunderground.com.

;; Query time: 26 msec
;; SERVER: 193.108.91.70#53(193.108.91.70)
;; WHEN: Di Mär 09 22:51:46 CET 2021
;; MSG SIZE rcvd: 83

Have you removed the TTL lines from your unbound configuration?

Yes, but it did not change anything

I don't know what else to check.

You're not getting a SERVFAIL from unbound, you're not getting any response at all:

pi@rasp:~ $ dig weatherstation.wunderground.com @127.0.0.1 -p 5353

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Raspbian <<>> weatherstation.wunderground.com @127.0.0.1 -p 5353
;; global options: +cmd
;; connection timed out; no servers could be reached

Actually that varies. Sometimes I get. Servfail, sometimes I get nothing.
Do you (or anyone else) have a working unbound 1.9 where we could check whether it’s a general unbound problem or if it’s something only I see?

Thank you for all your help do far!