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

[George Barwood]

----- Original Message ----- 
From: "Mark Andrews" <marka at isc.org>
To: "George Barwood" <george.barwood at blueyonder.co.uk>
Cc: "Cricket Liu" <cricket at nxdomain.com>; <dns-operations at mail.dns-oarc.net>; <dns at nasa.gov>
Sent: Monday, February 14, 2011 12:58 AM
Subject: Re: [dns-operations] Another possible .gov validation problem?


> 
> 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 practical issue here is detecting that there actually IS a problem.

Someone might easily conclude that the name is no longer registered
( and of course in one sense that's true ), but having obtained an
authoritative answer for the query, reporting NameError seems mis-leading to me.

> 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.

I think it would be useful (SHOULD) for the authoritative server to detect the
problem when loading the zones. Sure, the operator ought to get it right,
but helping operators when they get it wrong is surely good practice.
Ok, if it turns out to be too difficult/expensive for the software to perform
a check, then it might not be practical, but I doubt that is the case here.

In another context (glue), RFC 2181 says this

   Where a server can detect from two zone files
   that one or more are incorrectly configured, so as to create
   conflicts, it should refuse to load the zones determined to be
   erroneous, and issue suitable diagnostics.
I don't entirely agree with the refusing to load the zones part, but issuing diagnostics
seems a good idea when zone files are detectably inconsistent. Anything that helps
ease the transition to DNSSEC.

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