On Fri, 22 Jan 2010, Alex Bligh wrote:
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.
Sounds good.
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.
If I secure example.org, and .org is signed, OPT-OUT might cause a spoofed
exemple.org to not be caught by the user's validating resolver. Therefor,
I do think opt-out should be avoided when possible.
There are considerable operational
advantages in Opt Out (zone size, cryptographic complexity etc.)
I understand zone size, though I don't understand "cryptographic complexity".
Having different "security values" attached to data within the same zone seems
more complex to me, not less complex?
for large zones only sparsely populated with secure delegations,
particularly where few queries have DO set anyway.
I'd like to avoid circular adoption loop arguments :)
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
