[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: question about dnssec-protocol-04
</chair>
At 22:33 2003-12-22, David Blacka wrote:
On Monday 22 December 2003 3:41 pm, Mark.Andrews@isc.org wrote:
> A signed zone should return the same answers as a unsigned
> zone modulo DNSSEC records.
Where does this requirement come from?
This requirement was placed on the work that lead to RFC2065
thus it has been there for about 10 years in both RFC2065 and RFC2535
this was viewed as backwards compatibility.
> > It is true that I cannot think of any useful reason to do this, but
> > forbidding such NSEC records should have some real problem associated
> > with it.
>
> Without the rule it also means that a UPDATE client needs
> to know to delete NSEC when the last regular record is
> deleted. This introduces race conditions between the client
> and the server which don't exist if the server is left to
> manage the creation and deletion of NSEC.
I don't see how allowing solo NSEC records is incompatible with the server
manging the NSEC records. That seems like a policy issue to me. I will
agree that UPDATE clients shouldn't deal with NSEC records directly.
With the requirement this is a snip of a "random" large delegation zone
(RRsig's omitted for clarity>
ogud.com NS <ns set with 3 servers>
NSEC ogue.com NS DS NSEC RRSIG
DS
ogue.com NS <ns set with 2 servers>
NSEC <points somewhere>
Without the restriction following is a valid zone snip
ogud.com NS <ns set with 3 servers>
NSEC ogud1.com NS DS NSEC RRSIG
DS
ogud1.com NSEC ogud2.com NSEC RRSIG
ogud2.com NSEC ogud3.com NSEC RRSIG
....
ogud99999.com NSEC ogude.com NSEC RRSIG
ogue.com NS <ns set with 2 servers>
NSEC <points somewhere>
but what is the value of this ?
The zone is larger (not a good thing) and to a non DNSSEC aware resolver
it looks like there is wild card in the zone when there is none.
Second point, without this rule a dynamic update nameserver may elect
not to delete NSEC records when the other records at the name are deleted
as it is looks like less work, but it is not.
In either case one NSEC record needs to be updated either the one
at the name or the one of the name preceding the updated.
I'll be clear here: I am not bothered by this restriction per se. While I
haven't seen the light as to why solo NSEC records are bad, I also think that
they are useless. What bothers me is that a) if they are harmless, then they
shouldn't be forbidden, and b) if they aren't, then the "why" of the rule
needs to be in the document as well. If I'm confused by this now, then
someone two years from now will probably be confused by this as well, and
telling them to search the namedroppers archives for a explanation is
not...good.
The records are almost harmless.
<chair>
I think this is a good point, if David is confused someone else will be
thus we should add text to the document explaining the reasons.
Olafur
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>