Maintained by: NLnet Labs

[Unbound-users] dig fails intermittently, but unbound-host does not

W.C.A. Wijngaards
Tue Mar 29 14:16:40 CEST 2011

Hash: SHA1

Hi Andrew, Paul,

On 03/29/2011 02:11 PM, Andrew Hearn wrote:
> On 29/03/11 12:19, Paul Wouters wrote:
>> On Tue, 29 Mar 2011, Andrew Hearn wrote:
>>> We have version 1.3.4 on a server and have an odd, intermittent, problem
>>> with looking up a particular record.
>>> We have other unbound and bind servers that don't have this problem.
>>> eg:
>>> [root at a log]# unbound-control flush
>>> ok
>>> [root at a log]# dig @localhost
>> That domain seems broken, at least from the "world view":
>> [paul at bofh ~]$ dnscheck
>>   0.000: INFO Begin testing zone with
>> version 1.2.1.
>>   0.000: INFO Begin testing delegation for
>>   6.008: INFO Name servers listed at parent:
>>   6.168: ERROR Failed to find name servers of
>>   6.168: ERROR No name servers found at child.
>>   6.168: INFO Done testing delegation for
>>   6.168: CRITICAL Fatal error in delegation for zone
>>   6.168: INFO Test completed for zone
>> If it works internally, perhaps one issue is that one of your servers
>> uses the external instead
>> of internal view?

I think Paul is correct.

> Thanks for the info, but I'm not sure this explains it, as:
>   unbound-host -v
> always works, and gives answers, but
>   dig @localhost
> is intermittent
> Also, works each time we try

That is because the first looking (has to) use the parent-side
delegation information.  But with a cache the daemon on a second lookup
uses the child-side delegation information.  unbound-host is a
commandline tool and does the first lookup of course.

In unbound 1.4.5 the approach to deal with such broken domains was
changed significantly, making it more robust.  It may work with this
broken domain.

Or, you could unbreak the domain, fix it :-)

Best regards,
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora -