[dns-operations] Another possible .gov validation problem?

Mark Andrews marka at isc.org
Mon Feb 14 00:58:02 UTC 2011


In message <46178960413C48D7BA6BC8B2FD89AA01 at local>, "George Barwood" writes:
> If the query is run with +cdflag=1 then you get an A record back, agreed?

No.  NXDOMAIN could also be returned and it would have validated
as secure.  It all depends query order and what is in the cache at
the time the A query is made.

> I think (in the absence of attacks) I would expect +cdflag=1 responses to
> agree, with the only exception being that checking can produce ServerFail.
> 
> I'm not yet convinced one way or the other, maybe it doesn't matter in the
> end. I just think ServerFail is a more accurate categorisation of this
> situation from a practical point of view, with meaning "something is wrong
> with the DNS / we are under attack".  NameError seems slightly misleading,
> when there is concrete evidence of a mis-configuration.

So you want a authoritative nameserver to detect when it is configured
for a zone but no delegation for that zone exists and return SERVFAIL
for the 1 in a million case.  This is not the nameserver's job.

The fact that the nameserver didn't do this actually made it easier
to diagnose the problem.  The NXDOMAIN for the DS lookup said that
there wasn't a delegation.  If it returned SERVFAIL one would have
to work out why it was returning SERVFAIL for the DS lookup.

> I don't think the standard has anything to say on this ( please correct me
> if I'm wrong ).

The RFC's say how to generate the answers for the individual queries.
The authoritative server answered correctly in both cases.  It found
the correct zone to generate the answer from, generated and returned
it.

It is not the nameserver's job to ensure that parent / child zones
are consistent even when served by the same server.  That is the
operators job.

> George
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



More information about the dns-operations mailing list