--On 22 January 2010 12:04:07 +0100 Olaf Kolkman <o...@nlnetlabs.nl> wrote:
Strawman text said:
Though some claim all data in the DNS should be considered public, it
sometimes is considered to be more then private, but less then public
data.
That does not describe the problem well, in that (1) it is not
the data that is somewhere between public and private, it is
that the mechanisms of access to that data that change, and (2) it
completely ignores opt-out. How about
Though all agree DNS data should be accessible through query
mechanisms, a side effect of NSEC is that it allows the contents of
a zone file to be enumerate in full by sequential query. Whilst for
some operators this behaviour is acceptable or even desirable, for
others it is undesirable for policy, regulatory or other reasons.
This is the first reason for development of NSEC3.
The second reason for the existence of NSEC3 is that NSEC requires
a signature over every RR in the zonefile, thereby ensuring that
any denial of existence is cryptographically signed. However, in a
large zonefile containing many delegations very few of which are to
signed zones, this may produce unacceptable additional overhead
especially where insecure delegations are subject to frequent
update (a typical example might be a TLD operator with few
registrants using secure delegations). NSEC3 allows intervals
between two such delegations to "Opt-out" in which case they may
contain one more more insecure delegations, thus reducing the size
and cryptographic complexity of the zone.
5.3.4 Opt-out
An Opt-Out NSEC3 RR does not assert the existence or non-existence of the
insecure delegations that it may cover. This allows for the addition or
removal of these delegations without recalculating or re- signing RRs in
the NSEC3 RR chain. Therefor, Opt-Out should be avoided if possible.
1. Therefor*e*
2. I don't think the last sentence follows from the foregoing, in that
this behaviour is desirable for the zone operator! (I know what
you mean).
3. Aside from that, I don't think an injunction to avoid Opt-Out in
these terms is sensible in a delegation only zone. In such a zone,
I don't really see the additional security risk from opt out across
insecure delegations, given if a spoof can be done, it can be
done at the delegated zone level. There are considerable operational
advantages in Opt Out (zone size, cryptographic complexity etc.)
for large zones only sparsely populated with secure delegations,
particularly where few queries have DO set anyway.
--
Alex Bligh
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
