unbound fails to do reverse look ups

Carlo_Wood · October 17, 2025, 7:09pm

Hi, after two days of investigations I'm feeling a bit desperate...

I install unbound to be used by postfix, which does reverse
lookups of hostnames and started to reject all email because
unbound can't do that, it seems.

Using my normal resolver:

>dig google.com | grep '^google.com'
google.com. 2400 IN A 142.251.36.46

>dig -x 142.251.36.46 | grep '^46'
46.36.251.142.in-addr.arpa. 61312 IN PTR ams17s12-in-f14.1e100.net.

I have unbound listening on 127.25.0.53:

  >dig -x 142.251.36.46 @127.25.0.53
  ;; communications error to 127.25.0.53#53: timed out
  ;; communications error to 127.25.0.53#53: timed out
  ;; communications error to 127.25.0.53#53: timed out

  ; <<>> DiG 9.20.13 <<>> -x 142.251.36.46 @127.25.0.53
  ;; global options: +cmd
  ;; no servers could be reached

Logs of unbound during this:

Oct 17 20:56:57 daniel unbound[199121]: [199121:0] query: 127.0.0.1 46.36.251.142.in-addr.arpa. PTR IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: resolving 46.36.251.142.in-addr.arpa. PTR IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for 46.36.251.142.in-addr.arpa. PTR IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <in-addr.arpa.> 199.180.182.53#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was REFERRAL
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: resolving x.arin.net. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: resolving z.arin.net. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for 46.36.251.142.in-addr.arpa. PTR IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <142.in-addr.arpa.> 192.82.134.30#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was REFERRAL
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: resolving ns3.google.com. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: resolving ns4.google.com. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: resolving ns2.google.com. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for ns2.google.com. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <com.> 192.54.112.30#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was REFERRAL
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for ns3.google.com. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <com.> 192.55.83.30#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was REFERRAL
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for ns4.google.com. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <com.> 192.33.14.30#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was REFERRAL
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for ns3.google.com. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <google.com.> 216.239.36.10#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was ANSWER
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for ns2.google.com. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <google.com.> 216.239.34.10#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was ANSWER
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for ns4.google.com. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <google.com.> 216.239.34.10#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was ANSWER
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for 46.36.251.142.in-addr.arpa. PTR IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <251.142.in-addr.arpa.> 216.239.36.10#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was nodata ANSWER
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: resolving ns1.google.com. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for ns1.google.com. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <google.com.> 216.239.38.10#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was ANSWER
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for 46.36.251.142.in-addr.arpa. PTR IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <251.142.in-addr.arpa.> 216.239.36.10#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was nodata ANSWER
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for z.arin.net. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <arin.net.> 199.212.0.108#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was ANSWER
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for x.arin.net. A IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <arin.net.> 199.212.0.108#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was ANSWER
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for 46.36.251.142.in-addr.arpa. PTR IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <251.142.in-addr.arpa.> 216.239.38.10#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was ANSWER
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: prime trust anchor
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: generate keytag query _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: resolving in-addr.arpa. DNSKEY IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: resolving _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: response for _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: reply from <in-addr.arpa.> 199.253.183.183#53
Oct 17 20:56:57 daniel unbound[199121]: [199121:0] info: query response was NXDOMAIN ANSWER
Oct 17 20:57:02 daniel unbound[199121]: [199121:0] query: 127.0.0.1 46.36.251.142.in-addr.arpa. PTR IN
Oct 17 20:57:04 daniel unbound[199121]: [199121:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset in-addr.arpa. DNSKEY IN
Oct 17 20:57:04 daniel unbound[199121]: [199121:0] info: prime trust anchor
Oct 17 20:57:04 daniel unbound[199121]: [199121:0] info: generate keytag query _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:04 daniel unbound[199121]: [199121:0] info: resolving in-addr.arpa. DNSKEY IN
Oct 17 20:57:04 daniel unbound[199121]: [199121:0] info: resolving _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:04 daniel unbound[199121]: [199121:0] info: response for _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:04 daniel unbound[199121]: [199121:0] info: reply from <in-addr.arpa.> 200.10.60.53#53
Oct 17 20:57:04 daniel unbound[199121]: [199121:0] info: query response was NXDOMAIN ANSWER
Oct 17 20:57:07 daniel unbound[199121]: [199121:0] query: 127.0.0.1 46.36.251.142.in-addr.arpa. PTR IN
Oct 17 20:57:11 daniel unbound[199121]: [199121:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset in-addr.arpa. DNSKEY IN
Oct 17 20:57:11 daniel unbound[199121]: [199121:0] info: prime trust anchor
Oct 17 20:57:11 daniel unbound[199121]: [199121:0] info: generate keytag query _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:11 daniel unbound[199121]: [199121:0] info: resolving in-addr.arpa. DNSKEY IN
Oct 17 20:57:11 daniel unbound[199121]: [199121:0] info: resolving _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:11 daniel unbound[199121]: [199121:0] info: response for _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:11 daniel unbound[199121]: [199121:0] info: reply from <in-addr.arpa.> 193.0.9.1#53
Oct 17 20:57:11 daniel unbound[199121]: [199121:0] info: query response was NXDOMAIN ANSWER
Oct 17 20:57:18 daniel unbound[199121]: [199121:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset in-addr.arpa. DNSKEY IN
Oct 17 20:57:18 daniel unbound[199121]: [199121:0] info: prime trust anchor
Oct 17 20:57:18 daniel unbound[199121]: [199121:0] info: generate keytag query _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:18 daniel unbound[199121]: [199121:0] info: resolving in-addr.arpa. DNSKEY IN
Oct 17 20:57:18 daniel unbound[199121]: [199121:0] info: resolving _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:18 daniel unbound[199121]: [199121:0] info: response for _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:18 daniel unbound[199121]: [199121:0] info: reply from <in-addr.arpa.> 199.180.182.53#53
Oct 17 20:57:18 daniel unbound[199121]: [199121:0] info: query response was NXDOMAIN ANSWER
Oct 17 20:57:25 daniel unbound[199121]: [199121:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset in-addr.arpa. DNSKEY IN
Oct 17 20:57:25 daniel unbound[199121]: [199121:0] info: prime trust anchor
Oct 17 20:57:25 daniel unbound[199121]: [199121:0] info: generate keytag query _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:25 daniel unbound[199121]: [199121:0] info: resolving in-addr.arpa. DNSKEY IN
Oct 17 20:57:25 daniel unbound[199121]: [199121:0] info: resolving _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:25 daniel unbound[199121]: [199121:0] info: response for _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:25 daniel unbound[199121]: [199121:0] info: reply from <in-addr.arpa.> 196.216.169.10#53
Oct 17 20:57:25 daniel unbound[199121]: [199121:0] info: query response was NXDOMAIN ANSWER
Oct 17 20:57:31 daniel unbound[199121]: [199121:0] info: failed to prime trust anchor -- could not fetch DNSKEY rrset in-addr.arpa. DNSKEY IN
Oct 17 20:57:31 daniel unbound[199121]: [199121:0] info: prime trust anchor
Oct 17 20:57:31 daniel unbound[199121]: [199121:0] info: generate keytag query _ta-b7ce-d6ac.in-addr.arpa. NULL IN
Oct 17 20:57:31 daniel unbound[199121]: [199121:0] info: resolving in-addr.arpa. DNSKEY IN
Oct 17 20:57:31 daniel unbound[199121]: [199121:0] info: resolving
_ta-b7ce-d6ac.in-addr.arpa. NULL IN Oct 17 20:57:32 daniel
unbound[199121]: [199121:0] info: response for
_ta-b7ce-d6ac.in-addr.arpa. NULL IN Oct 17 20:57:32 daniel
unbound[199121]: [199121:0] info: reply from <in-addr.arpa.>
200.10.60.53#53 Oct 17 20:57:32 daniel unbound[199121]: [199121:0]
info: query response was NXDOMAIN ANSWER Oct 17 20:57:38 daniel
unbound[199121]: [199121:0] info: failed to prime trust anchor -- could
not fetch DNSKEY rrset in-addr.arpa. DNSKEY IN Oct 17 20:57:38 daniel
unbound[199121]: [199121:0] info: Could not establish a chain of trust
to keys for in-addr.arpa. DNSKEY IN Oct 17 20:57:38 daniel
unbound[199121]: [199121:0] info: validation failure
<46.36.251.142.in-addr.arpa. PTR IN>: no DNSKEY rrset [all servers for
this domain failed, at zone in-addr.arpa. from 196.216.169.10 upstream
server timeout] for trust anchor in-addr.arpa. while building chain of
trust

The reason this seems to fail is because unbound tries to connect with
tcp (after an udp failure) to an .in-addr.arpa. root server, which doesn't
like that and immediately closes the connection.

The root server closes the connection because RD=0 (Recursion desired),
which is correct I think: unbound should not ask root servers for a DNSKEY.

I can simulate this from the command line:

dig @f.in-addr-servers.arpa in-addr.arpa DNSKEY +dnssec +tcp +nosplit | grep '257'

in-addr.arpa. 2370 IN DNSKEY 257 3 8 AwEAAbNX16PjL99cu7CpO7Nt5EXoq8k6TCZpzxz13wCITdkwIce4UrzUqw7b76WH7N3KKAb4uJgmswkujk+gYMqnMAwNBFELrCDDkflw2AIjFPXBd2Txw8o3H5of2uIbAijm76B562VIiT3p0RIP1SH4eA+wHwYmqM3o/PiYfCxQD1c+EJx6b6dRcKAfeX4XMSsM6DyI6tjLGZ//w/IspRnbRb6Q36zWNyPPY2+5fqkaJ/94OKapvXTCUpWsNqKYlOxMwovwW9a2uBIgldzSq9mCtGUXU7mRZkwUIpnzA5Qe+lYdimWnzve7BXVs8ZZUyNhlDMlWYUrYHiaJ0uESYAWZQ98=
in-addr.arpa. 2370 IN DNSKEY 257 3 8
AwEAAbdOaEhLDa/H2m+hbXBHiAUE95PgpL2358lkJCBmb2Dn7aImc5sqoaEa48hlabMuG2PfnbWd3ttpVXX6mwLRMppyhJeBbr1q2YWtzi+Xx5modXLKSDPuLliLUQ1oPnq2QWK7BUNwmV70gQSOx78vkisDqFzocC2aiFAi+D2r45GPvtBMbjfCA1FB0SELeUCsxhgoAHphO5T6ITCrOccM7XX7A4qRbcbS65HOcbT+UDG9OoXjmw2j8mWgJXrpwvdsskaISrTivzcqadgOinSgAL3bVYFKCkiVBmx87d88v+OuK+358xsUIU+0MzXUidLS8086BpdiEW4cJ6c08oDyC10=

dig @f.in-addr-servers.arpa in-addr.arpa DNSKEY +dnssec +tcp +nosplit +norecurse

;; communications error to 193.0.9.1#53: end of file
;; communications error to 193.0.9.1#53: end of file
;; communications error to 193.0.9.1#53: end of file

; <<>> DiG 9.20.13 <<>> @f.in-addr-servers.arpa in-addr.arpa DNSKEY +dnssec +tcp +nosplit +norecurse
; (1 server found)
;; global options: +cmd
;; no servers could be reached

Am I correct to think that the problem is that unbound tries to do that last
thing at all, while it shouldn't?

I tried to added a trust-anchor with the above data, but that didn't help.
The only change is that now unbound sets the bit "Non-authenticated
data: Acceptable" - but the root server still immediately closes the connection.

Isn't this a bug in unbound or am I doing something wrong?

Current config:

grep -v '^[[:space:]]*#' unbound.conf | grep -v '^$'

server:
        verbosity: 2
        interface: 127.25.0.53
        outgoing-interface: 192.168.132.70
        so-sndbuf: 0
        edns-buffer-size: 1232
        do-ip6: no
        do-daemonize: no
        username: "unbound"
        log-time-iso: yes
        log-queries: yes
        log-replies: yes
        log-tag-queryreply: yes
        log-destaddr: yes
        log-servfail: yes
        trust-anchor-file: "/etc/unbound/trusted-key.key"
        trust-anchor-file: "/etc/unbound/trust-anchors.d/in-addr.arpa.key"
        pad-responses: yes
python:
dynlib:
remote-control:
        control-enable: yes
        control-interface: 127.0.0.1
        control-port: 8953
        server-key-file: "/etc/unbound/unbound_server.key"
        server-cert-file: "/etc/unbound/unbound_server.pem"
        control-key-file: "/etc/unbound/unbound_control.key"
        control-cert-file: "/etc/unbound/unbound_control.pem"

where

cat /etc/unbound/trust-anchors.d/in-addr.arpa.key

in-addr.arpa. DNSKEY 257 3 8 AwEAAbNX16PjL99cu7CpO7Nt5EXoq8k6TCZpzxz13wCITdkwIce4UrzUqw7b76WH7N3KKAb4uJgmswkujk+gYMqnMAwNBFELrCDDkflw2AIjFPXBd2Txw8o3H5of2uIbAijm76B562VIiT3p0RIP1SH4eA+wHwYmqM3o/PiYfCxQD1c+EJx6b6dRcKAfeX4XMSsM6DyI6tjLGZ//w/IspRnbRb6Q36zWNyPPY2+5fqkaJ/94OKapvXTCUpWsNqKYlOxMwovwW9a2uBIgldzSq9mCtGUXU7mRZkwUIpnzA5Qe+lYdimWnzve7BXVs8ZZUyNhlDMlWYUrYHiaJ0uESYAWZQ98=
in-addr.arpa. DNSKEY 257 3 8
AwEAAbdOaEhLDa/H2m+hbXBHiAUE95PgpL2358lkJCBmb2Dn7aImc5sqoaEa48hlabMuG2PfnbWd3ttpVXX6mwLRMppyhJeBbr1q2YWtzi+Xx5modXLKSDPuLliLUQ1oPnq2QWK7BUNwmV70gQSOx78vkisDqFzocC2aiFAi+D2r45GPvtBMbjfCA1FB0SELeUCsxhgoAHphO5T6ITCrOccM7XX7A4qRbcbS65HOcbT+UDG9OoXjmw2j8mWgJXrpwvdsskaISrTivzcqadgOinSgAL3bVYFKCkiVBmx87d88v+OuK+358xsUIU+0MzXUidLS8086BpdiEW4cJ6c08oDyC10=

but well - that should be necessary because I don't see any mention of something like that in any documentation online

Please help,
Carlo

Mans_Nilsson · October 18, 2025, 8:23am

Hi, after two days of investigations I'm feeling a bit desperate...

Is your connectivity OK? The query:

@f.in-addr-servers.arpa in-addr.arpa DNSKEY +dnssec +tcp +nosplit +norecurse +mult

(mult added for readability)

works here:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44981
;; flags: qr aa; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;in-addr.arpa. IN DNSKEY

;; ANSWER SECTION:
in-addr.arpa. 3600 IN DNSKEY 257 3 8 (
        AwEAAbdOaEhLDa/H2m+hbXBHiAUE95PgpL2358lkJCBmb2Dn7aImc5sqoaEa48hlabMuG2PfnbWd3ttpVXX6mwLRMppyhJeBbr1q2YWtzi+Xx5modXLKSDPuLliLUQ1oPnq2QWK7BUNwmV70gQSOx78vkisDqFzocC2aiFAi+D2r45GPvtBMbjfCA1FB0SELeUCsxhgoAHphO5T6ITCrOccM7XX7A4qRbcbS65HOcbT+UDG9OoXjmw2j8mWgJXrpwvdsskaISrTivzcqadgOinSgAL3bVYFKCkiVBmx87d88v+OuK+358xsUIU+0MzXUidLS8086BpdiEW4cJ6c08oDyC10=
        ) ; KSK; alg = RSASHA256 ; key id = 47054
in-addr.arpa. 3600 IN DNSKEY 256 3 8 (
        AwEAAcLg6IbJ4/8UYx7tf/gluXK27boQ+ZYphcdvLdSDIHElensV3TZTKK+eH9bwAwnwhR4Aqyq7IAskLfxFllYjUj1fmjdXr7/eqpR9qANXYlmUoxuJb+d6nEzs9sl7fAKqotSKsYU1bCrainQDV1WINttNJKe3APW0TDB13znjvstJ
        ) ; ZSK; alg = RSASHA256 ; key id = 2109
in-addr.arpa. 3600 IN DNSKEY 257 3 8 (
        AwEAAbNX16PjL99cu7CpO7Nt5EXoq8k6TCZpzxz13wCITdkwIce4UrzUqw7b76WH7N3KKAb4uJgmswkujk+gYMqnMAwNBFELrCDDkflw2AIjFPXBd2Txw8o3H5of2uIbAijm76B562VIiT3p0RIP1SH4eA+wHwYmqM3o/PiYfCxQD1c+EJx6b6dRcKAfeX4XMSsM6DyI6tjLGZ//w/IspRnbRb6Q36zWNyPPY2+5fqkaJ/94OKapvXTCUpWsNqKYlOxMwovwW9a2uBIgldzSq9mCtGUXU7mRZkwUIpnzA5Qe+lYdimWnzve7BXVs8ZZUyNhlDMlWYUrYHiaJ0uESYAWZQ98=
        ) ; KSK; alg = RSASHA256 ; key id = 54956
in-addr.arpa. 3600 IN RRSIG DNSKEY 8 2 3600 (
        20251029140514 20251008031929 47054 in-addr.arpa.
        eqmVvWQJouCrrFAs+H6vjDBEIarUGrRZP23EAa6fEJYGR3/pYdQe4BuM9IH4fhDC1n8n9QwWFlzYguZyAc2zwKErlySh4dvgnW5BP1PFIvUaMpRw07j75VSyi6DeGUMCKLxMOLKXdCvNLkmpggclZGrUBiahC3i5Pa41wDRXimUJ+570qTKKpNHqATMFnpAsc+zX0vk2e6+mONs6qD7xPop8beksBahDK51gtx/+VVpXYbSH9SAmjSYTOpOZK/Cm+PpPalqYC+LiAtZT8lWXeFibXIlgKJHBIheI//7t6mMRwCusOtsP4V4MdlVykL9KMEMLbPJPggPcX2c3xRoxIQ== )
in-addr.arpa. 3600 IN RRSIG DNSKEY 8 2 3600 (
        20251029140514 20251008031929 54956 in-addr.arpa.
        JbsD1JOJqMjj9ZUNx3FECbF+MzSaYNBbqRNalAOtcL5rifZbGXq5b5SmvgPLbKMNJuUk72p7/GcFLqVEslJ9Jbj4H0WShXE7lP/ndLsegkCIOWuuBTZrGDS75KOR7wjti4MDNzmJJHZ3lBN5MyyISmYjdYzsLSUSr0aIQ9+l54BlKaLcFhyeX1po/+5RrHHF6YcYghHtHvs8Utv7DcslwQWsJ7+fZdVTa+zre1kUoRMDhdShahPTTzlQnsuu5/wRjdWcdmGMsSUsMt36I2I+2YkxvPwvy06a2bZAJK3oatxF5qD7Is623TseCuV3H5JaQBSfHmCscTPr2himXAHaTA== )

I'd check what answers or refuses your query..

dig @f.in-addr-servers.arpa. hostname.bind CH TXT +short
"ns1.se-sto.authdns.ripe.net"

Carlo_Wood · October 18, 2025, 3:23pm

Hi, thanks you for your reply.

The command

~>dig @f.in-addr-servers.arpa in-addr.arpa DNSKEY +dnssec +tcp +nosplit
+norecurse +mult ;; communications error to 193.0.9.1#53: end of file
;; communications error to 193.0.9.1#53: end of file
;; communications error to 193.0.9.1#53: end of file

; <<>> DiG 9.20.13 <<>> @f.in-addr-servers.arpa in-addr.arpa DNSKEY
+dnssec +tcp +nosplit +norecurse +mult ; (1 server found)
;; global options: +cmd
;; no servers could be reached

fails.

For your last command I get back:

~>dig @f.in-addr-servers.arpa. hostname.bind  CH TXT +short "ns1.se-sto.authdns.ripe.net"
"ns2.pt-lis.authdns.ripe.net"

If this is indeed a firewall issue as Jan Komissar suggested then it
seems hard to find out which firewall that is :/. That is, I get an "end of file"
(it is pretty fast, not a real timeout). Aka, the connection is closed.
What packet should can I look at the closes the connection? Will that have
the address of the firewall, or address of the root server? I suspect the
latter, so that the only way to find out where this happens is with timing.

This is way above my pay grade however (to figure out what the "ping" is
using a +norecurse DNS query packet) :/...

Any ideas?

Carlo

Carlo_Wood · October 18, 2025, 3:30pm

Hello Jan,

thank you for your reply!

Why would any firewall go so far as to specifically filter on DNS
queries with certain flags?! I didn't even know that was possible :/.

Could this be done by my ISP? If so, is there a way I can find out
where exactly this filtering happens? I am using a Linksys Router
that still has the firmware of VPNExpress on it, even though I no
longer have an account there. I suppose that theoretically it is
possible that even my own router does this, because DNS (leakage)
is a VPN thing - if that is the case then I want to switch back to
opensource firmware... In that case the closing of the connection
should be sub-millisecond I think. I wonder if I can measure that
easily?

Carlo

Mans_Nilsson · October 18, 2025, 6:17pm

Any ideas?

The DNS firewall blocks DNS traffic via TCP but not UDP If I had a
Eurocent every time a stupid firewall admin does that, I could devote
all my time to answering questions on mailing lists pro bono! .
Since the refusing reply arrives fast, it probably is in the form of a
ICMP unreachable.

Looking at traffic on the machine while asking the question, using a
tool like tcpdump and writing to file, to filter in Wireshark later,
probably is the best way to check this hypothesis.

What you are looking for is a TCP RST or ICMP unreach packet, and it
just might, if it is a ICMP one, contain the ip address of the offender.

My speculation here is that you normally don't end up with large answers
that trigger re-query over TCP (when the reply is large enough so as to
trigger the Truncated bit being set and most resolver servers re-query
via TCP when this happens.) except when you look up reverses which are
signed. And the /8 delegations to RIR infrastructure typically are signed.

bmcdonaldjr · October 20, 2025, 1:43pm

I agree that’s it’s probably a firewall or edge router causing the issue.
Try using a different target DNS server in your dig command. (E.g. 8.8.8.8 or 9.9.9.9)
Both SHOULD give good replies
If you get similar results as received on your initial command, remove the +TCP and +NOSPLIT switches from the command. That will pinpoint what is going on but not where
Make sure your router is not the culprit

BTW, the command gets good results here for both unbound 1.24.0 and power DNS_recursor 5.3

My $.02

Bob