[Unbound-users] Unbound recursing and broken NS in RRSET.

[Sander Smeenk]

Quoting W.C.A. Wijngaards (wouter at nlnetlabs.nl):

> > [..] Unbound does not even answer(!) queries for domains which have
> > at least one malfunctioning NS in their NS RRSET.
> What sort of malfunctioning are you talking about?

This reply took some time because of other urgent matters to attend to
at work, but i owe you and this "thread" an update on this issue after
(wrongfully) accusing Unbound as quoted above. ;-)

We managed to figure out what Unboud was doing and also fixed this
issue which turned out to be a strict UDP-fragment filter 'protecting'
our DNS vlan.

This filter dropped UDP *fragments* but it let the *first* packet of the
fragemented flow go through. This caused alot of retransmissions, each
failing in the same way: First packet is received, the rest was dropped.
Retransmits. Rinse, repeat.

In fact this retransmissions took so long, dig and other stub resolvers
timed out on the query and indicated SERVFAIL.

Also, the broken nameserver for the debian.org zone was totally
unrelated to any of this as you explained in your reply.
The nameserver was fixed a few days after i sent my message.

The strange part was that, with the UDP filter in place, retrying the
same query to Unbound a few times eventually *did* turn up the correct
answer. My theory is that Unbound switches to TCP after $so_many
retransmits / failures via UDP.

I learned to use DNS-OARC's Reply Size test[1] /before/ annoying
mailinglist subscribers. Sorry. ;-)

With regards,
-Sander.
[1] https://www.dns-oarc.net/oarc/services/replysizetest
-- 
| Experience is a wonderful thing.
| It enables you to recognise a mistake if you make it again.
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2