unbound fails to do reverse look ups

Mon Oct 20 13:43:14 UTC 2025

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

Sent from my Google Pixel 9a phone.

On Sun, Oct 19, 2025, 08:00 <unbound-users-request at lists.nlnetlabs.nl>
wrote:

> Send Unbound-users mailing list submissions to
>         unbound-users at lists.nlnetlabs.nl
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.nlnetlabs.nl/mailman/listinfo/unbound-users
> or, via email, send a message with subject or body 'help' to
>         unbound-users-request at lists.nlnetlabs.nl
>
> You can reach the person managing the list at
>         unbound-users-owner at lists.nlnetlabs.nl
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Unbound-users digest..."
>
>
> Today's Topics:
>
>    1. Re: unbound fails to do reverse look ups (Carlo Wood)
>    2. Re: unbound fails to do reverse look ups (Carlo Wood)
>    3. Re: unbound fails to do reverse look ups (M?ns Nilsson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 18 Oct 2025 17:23:14 +0200
> From: Carlo Wood <carlo at alinoe.com>
> To: unbound-users at lists.nlnetlabs.nl
> Subject: Re: unbound fails to do reverse look ups
> Message-ID: <20251018172314.7bd17782 at daniel.localdomain>
> Content-Type: text/plain; charset="us-ascii"
>
> 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
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 228 bytes
> Desc: OpenPGP digital signature
> URL: <
> http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20251018/08191a6e/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 2
> Date: Sat, 18 Oct 2025 17:30:13 +0200
> From: Carlo Wood <carlo at alinoe.com>
> To: "Jan Komissar (jkomissa)" <jkomissa at cisco.com>
> Cc: "unbound-users at lists.nlnetlabs.nl"
>         <unbound-users at lists.nlnetlabs.nl>
> Subject: Re: unbound fails to do reverse look ups
> Message-ID: <20251018173013.22cdc68e at daniel.localdomain>
> Content-Type: text/plain; charset=US-ASCII
>
> 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
>
> On Fri, 17 Oct 2025 21:22:24 +0000
> "Jan Komissar (jkomissa)" <jkomissa at cisco.com> wrote:
>
> > Your result may be caused by a misconfigured firewall that
> > drops outgoing DNS queries without the recursion flag set.
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 18 Oct 2025 20:17:16 +0200
> From: M?ns Nilsson <mansaxel at besserwisser.org>
> To: Carlo Wood <carlo at alinoe.com>
> Cc: unbound-users at lists.nlnetlabs.nl
> Subject: Re: unbound fails to do reverse look ups
> Message-ID: <aPPZrEsn-uyCOwqx at besserwisser.org>
> Content-Type: text/plain; charset="utf-8"
>
> Subject: Re: unbound fails to do reverse look ups Date: Sat, Oct 18, 2025
> at 05:23:14PM +0200 Quoting Carlo Wood via Unbound-users (
> unbound-users at lists.nlnetlabs.nl):
>
> > 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.
>
> --
> M?ns Nilsson     primary/secondary/besserwisser/machina
> MN-1334-RIPE           SA0XLR            +46 705 989668
> Yow!  And then we could sit on the hoods of cars at stop lights!
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL: <
> http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20251018/d7b7c69e/attachment-0001.bin
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Unbound-users mailing list
> Unbound-users at lists.nlnetlabs.nl
> https://lists.nlnetlabs.nl/mailman/listinfo/unbound-users
>
>
> ------------------------------
>
> End of Unbound-users Digest, Vol 70, Issue 4
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20251020/f8a9fac7/attachment.htm>