Yet another Unbound SERVFAIL with one server

Expected Behaviour:

RPi 5 with pi-hole 5.18.2 and unbound 1.17.1-2+deb12u2 on new dietpi system
Unbound and pi-hole were installed using the dietpi installer.
Most queries seem to be working, and nzb.su should resolve.

Actual Behaviour:

nzb.su returns a SERVFAIL

dig @localhost -p 5335 a nzb.su
;; communications error to ::1#5335: connection refused
;; communications error to ::1#5335: connection refused
;; communications error to ::1#5335: connection refused
;; communications error to 127.0.0.1#5335: timed out

; <<>> DiG 9.18.24-1-Debian <<>> @localhost -p 5335 a nzb.su
; (2 servers found)
;; global options: +cmd
;; no servers could be reached

Based on many other threads I've read, I tried running sudo /usr/sbin/unbound -ddd -vvv -c /etc/unbound/unbound.conf while the following dig query was executed:
dig dietpi.com @127.0.0.1 -p 5335 a nzb.su

The dig output is the same:

dietpi@DietPi:/etc/systemd$ dig @127.0.0.1 -p 5335 a nzb.su                                                ;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out

; <<>> DiG 9.18.24-1-Debian <<>> @127.0.0.1 -p 5335 a nzb.su
; (1 server found)
;; global options: +cmd
;; no servers could be reached

However, the same command with instagram.com works:

dig @127.0.0.1 -p 5335 a instagram.com

; <<>> DiG 9.18.24-1-Debian <<>> @127.0.0.1 -p 5335 a instagram.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10622
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
instagram.com.          300     IN      A       31.13.65.174

;; Query time: 72 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Sat Jun 01 18:14:36 EDT 2024
;; MSG SIZE  rcvd: 58

Output of /etc/unbound/unbound.conf.d/dietpi.conf:

# https://nlnetlabs.nl/documentation/unbound/unbound.conf/
server:
        # Do not daemonize, to allow proper systemd service control and status estimation.
        do-daemonize: no

        # A single thread is pretty sufficient for home or small office instances.
        num-threads: 1

        # Logging: For the sake of privacy and performance, keep logging at a minimum!
        # - Verbosity 2 and up practically contains query and reply logs.
        verbosity: 0
        log-queries: no
        log-replies: no
        # - If required, uncomment to log to a file, else logs are available via "journalctl -u unbound".
        #logfile: "/var/log/unbound.log"

        # Set interface to "0.0.0.0" to make Unbound listen on all network interfaces.
        # Set it to "127.0.0.1" to listen on requests from the same machine only, useful in combination with Pi-hole.
        interface: 127.0.0.1
        # Default DNS port is "53". When used with Pi-hole, set this to e.g. "5335", since "5353" is used by mDNS already.
        port: 5335

        # Control IP ranges which should be able to use this Unbound instance.
        # The DietPi defaults permit access from official local network IP ranges only, hence requests from www are denied.
        access-control: 0.0.0.0/0 refuse
        access-control: 10.0.0.0/8 allow
        access-control: 127.0.0.1/8 allow
        access-control: 172.16.0.0/12 allow
        access-control: 192.168.0.0/16 allow
        access-control: ::/0 refuse
        access-control: ::1/128 allow
        access-control: fd00::/8 allow
        access-control: fe80::/10 allow

        # Private IP ranges, which shall never be returned or forwarded as public DNS response.
        # NB: 127.0.0.1/8 is sometimes used by adblock lists, hence DietPi by default allows those as response.
        private-address: 10.0.0.0/8
        private-address: 172.16.0.0/12
        private-address: 192.168.0.0/16
        private-address: 169.254.0.0/16
        private-address: fd00::/8
        private-address: fe80::/10

        # Define protocols for connections to and from Unbound.
        # NB: Disabling IPv6 does not disable IPv6 IP resolving, which depends on the clients request.
        do-udp: yes
        do-tcp: yes
        do-ip4: yes
        do-ip6: no

        # DNS root server information file. Updated monthly via cron job: /etc/cron.monthly/dietpi-unbound
        root-hints: "/var/lib/unbound/root.hints"

        # Maximum number of queries per second
        ratelimit: 1000

        # Defend against and print warning when reaching unwanted reply limit.
        unwanted-reply-threshold: 10000

        # Set EDNS reassembly buffer size to match new upstream default, as of DNS Flag Day 2020 recommendation.
        edns-buffer-size: 1232

        # Increase incoming and outgoing query buffer size to cover traffic peaks.
        so-rcvbuf: 4m
        so-sndbuf: 4m

        # Hardening
        harden-glue: yes
        harden-dnssec-stripped: yes
        harden-algo-downgrade: yes
        harden-large-queries: yes
        harden-short-bufsize: yes

        # Privacy
        use-caps-for-id: yes # Spoof protection by randomising capitalisation
        rrset-roundrobin: yes
        qname-minimisation: yes
        minimal-responses: yes
        hide-identity: yes
        identity: "Server" # Purposefully a dummy identity name
        hide-version: yes

        # Caching
        cache-min-ttl: 300
        cache-max-ttl: 86400
        serve-expired: yes
        neg-cache-size: 4M
        prefetch: yes
        prefetch-key: yes
        msg-cache-size: 50m
        rrset-cache-size: 100m

The output of my verbose unbound window while running the dig command to nzb.su is here: dietpi@DietPi:~$ sudo /usr/sbin/unbound -ddd -vvv -c /etc/unbound/unbound.conf - Pastebin.com

Any ideas what else I can try? I tried asking on the DietPi Forums but didn't have any success.

1 Like

I recommend visiting the DietPi support site. You used their installer for the software; there may be something unique to their installer.

(On a side note: That link takes you to the dietpi forums, not the unbound ones.)

I have no difficulties resolving nzb.su via my unbound installation.

I noticed a warning in your unbound log:
warning: subnetcache: serve-expired is set but not working for data originating from the subnet module cache.

I can't say whether that may contribute to your observation, but as you are running unbound with dietpi's configuration, you could consider to test whether running with Pi-hole's recommended unbound configuration would change your observation. You'd have to figure yourself how to apply that, as I don't know how dietpi goes about configuring unbound.

However, as you state that other requests are working fine, it would seem specific to that domain rather than a configuration issue.

I note that contrary to your topic title, your output does not contain a single SERVFAIL status reply.

Instead, it shows either connection refused (when querying via IPv6) or timed out (when talking via IPv4).

The former is a local issue accessing ::1#5335, triggered by using dig with @localhost, and probably can be ignored, as your unbound does not (and needs not) accept IPv6 traffic anyway.

The latter time out would indicate that either unbound itself or one of the authoritative DNS servers visited during recursion did not reply in time.

Your unbound log indeed shows that unbound is waiting for replies of servers authoritative for su, but never receives one, e.g.:

[1717169478] unbound[3034:0] info: iterator operate: query nzb.su. A IN
[1717169478] unbound[3034:0] info: processQueryTargets: nzb.su. A IN
[1717169478] unbound[3034:0] info: sending query: nzb.su. A IN
[1717169478] unbound[3034:0] debug: sending to target: <su.> 193.232.128.6#53
[1717169478] unbound[3034:0] debug: cache memory msg=67366 rrset=88077 infra=12012 val=67176 subnet=74504
[1717169479] unbound[3034:0] debug: iterator[module 2] operate: extstate:module_wait_reply event:module_event_noreply

That could have a variety of causes, e.g. those servers may not have been able to reply in time, either due to heavy load or because they are located too far away from you, or something in their DNS configuration is off, or they are actively discarding requests from your IP range, or something upstream of you is interfering with accessing them (e.g. your ISP).

For some of those causes, this may only be temporary glitch, in which case repeating the request should be successful.

If it isn't, you'd have to investigate why authoritative servers for su are timing out for you.

If you don't bother to investigate, but absolutely must access that domain, you could consider to configure your Pi-hole to forward resolution for that domain only to a public DNS resolver instead of unbound.

1 Like

Sorry, that was an error. I meant to write DietPi. I'll edit the original post.

I did, which is what I meant to say in the original post. I'll correct it now.

I appreciate the replies and will examine the configuration to see if there are differences. I've run so many queries that 2 months ago when I started the draft I was seeing results like ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36534. I included more recent results when I decided to try posting here. Incidentally the device was setup on 29 April and didn't experience issues until 13 May. It took me so long to detect it that I don't know what updates if any might have happened during those 2 weeks to influence the issue.

It seems unlikely my ISP is blocking that domain because queries using 8.8.8.8 go through right away. I admit I don't understand what recursive DNS really means, but it seems if the ISP were blocking the site or if the site had its own issues, then it wouldn't work with 8.8.8.8 either. My ignorance aside, I'll keep trying to find a solution. There are dozens of posts complaining about this specific domain not working with unbound + pi-hole, and none so far seem to have a successful resolution.

I was reading another post yesterday where certain .il domains were failing to connect in the same fashion. It was recommended there to install systemd-resolved, and while that seemed to help the poster in that thread, all it did was break pi-hole for me, causing FTL to fail to load because port 53 was already in use. I uninstalled systemd-resolved, and the system went back to working.

Anyway thank you again for the assistance. I'll keep looking around and maybe ping DietPi support again to see if they have ideas there.

That conclusion is unwarranted.

Rather than a direct domain block, your observation may involve restricted acccess to one of the authoritative DNS servers along the resolution recursion, i.e. the nameservers for .su or .nzb.su. As mentioned, your log demonstrates that all requests to .su nameservers never receive a reply, hence the timeout.

So when investigating, keep in mind that resolution of the domain via a public resolver like 8.8.8.8 may still work, as it would then be that public resolver talking to .su nameservers when walking the recursion chain.

But as mentioned:

Short of trying to identify the real cause and take it up with the DNS maintainers or your ISP, that may also be the easiest workaround.

Thanks again. As you've no doubt intuited, I am at my limit of understanding the issue. I'll either continue without unbound or learn how to forward that one domain.

The latter isn't too difficult, it would involve creating a custom dnsmasq configuration (e.g. /etc/dnsmasq.d/42-bypass-unbound.conf), with contents like:

# forward resolution to public resolver, bypassing unbound
server=/nzb.su/9.9.9.9

You may keep 9.9.9.9 or change that to a public resolver of your choice.

When done, check for potential syntax errors:

pihole-FTL dnsmasq-test

If OK, run pihole restartdns to take those settings into effect.

Note that
a. you will be missing out on DNSSEC validation for that domain
b. subdomains (like example.nzb.su) will also be forwarded to that public resolver

When comparing this workaround with the easier creation of a local DNS record for nzb.su in Pi-hole, it has the advantage of picking up IP address changes automatically.

Thanks for that. Now that I've read more about recursive DNS, I decided to see if the authoritative servers were having issues. I tried running nslookup to find the authoritative servers, and this was the result:

nslookup
> set querytype=soa
> nzb.su
Server:         192.168.99.5
Address:        192.168.99.5#53

Non-authoritative answer:
nzb.su
        origin = pdns03.domaincontrol.com
        mail addr = dns.jomax.net
        serial = 2020102805
        refresh = 28800
        retry = 7200
        expire = 604800
        minimum = 86400

Authoritative answers can be found from: # there was no more text beyond this point

Again speaking from ignorance, it appears nslookup wasn't able to contact or determine the authoritative servers for nzb.su.

In any event, your solution worked for me, and now all of my queries besides nzb.su are using unbound.

No, that result looks OK.

As I've mentioned, your unbound log indicates that the nameservers for su would be unresponsive:

193.232.128.6#53 is a.dns.ripn.net, which is one of the authoritative DNS servers for su, as can be found from

$ nslookup -querytype=NS su. 127.0.0.1 -port=5335
Server:		127.0.0.1
Address:	127.0.0.1#5335

Non-authoritative answer:
su	nameserver = a.dns.ripn.net. (-> 193.232.128.6)
su	nameserver = b.dns.ripn.net. (-> 194.85.252.62)
su	nameserver = d.dns.ripn.net. (-> 194.190.124.17)
su	nameserver = e.dns.ripn.net. (-> 193.232.142.17)
su	nameserver = f.dns.ripn.net. (-> 193.232.156.17)

Authoritative answers can be found from:

(I've manually added IPs in above output.)

In addition, running nzb.su by a DNSSEC validator turns up some errors and warnings, including missing responses when queried via UDP:

This does not quite match your logged events, but it would confirm that there is indeed something objectively wrong with nzb.su's public DNS configuration, which ideally would have to be fixed by the respective DNS server's maintainers.
Until that happens, you may keep going with your workaround, and perhaps check from time to time if nzb.su has been fixed.

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