Quoting W.C.A. Wijngaards ([email protected]): > > [..] 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 _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
