SERVFAIL from validating nameservers for &

Chris Thompson cet1 at
Sat Feb 7 17:58:46 UTC 2009

On Feb 6 2009, Mark Andrews wrote:

>In message <Prayer. at>, 
>Chris Thompson writes:
>> More info about the "not consistently" bit. With nothing about
>> them in the cache ("rndc flushname") looking up SOA or
>> NS records for them gives SERVFAIL. But looking up A records does
>> not, and after that SOA and NS lookups work OK as well.
>> Hmmm...
>	The TLD lies.  DNSSEC is doing exactly what it is
>	supposed to do and is blocking ibad answers.
>	Mark
>; <<>> DiG 9.3.6-P1 <<>> soa +dnssec
>;; global options:  printcmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29667
>;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>;			IN	SOA
>pro.			14400	IN	SOA 
> 2009020518 28800 7200 604800 300

Ah, yes -- many thanks for the elucidation.

Indeed, looking up SOA for via a non-validating nameserver
(without it having already discovered the NS records for it) believes
this crap and reports it back to the caller.

The nameservers for "pro" seem to have some very odd bugs:

 * asked about the SOA for a sub-zone, they authoritatively deny its 
    existence, as above.
 * asked about NS records for a sub-zone, they return the delegation
    set as the _answer_. That's also true of the * lot,
    but these are worse, because unlike them they claim the answer is
 * even when they do give a referral, it is marked authoritative.

One hardly dares to ask how they achieve all this ...

Chris Thompson
Email: cet1 at

More information about the bind-users mailing list