[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On dynamic NSEC
- To: namedroppers@ops.ietf.org
- Subject: On dynamic NSEC
- From: Simon Josefsson <jas@extundo.com>
- Date: Thu, 11 Nov 2004 13:04:26 +0100
- Cancel-lock: sha1:7i4epkPKNXHMCFAu2EaTULZy/z0=
- User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)
Quoting <http://www.xmpp.org/ietf-logs/dnsext@ietf.xmpp.org/2004-11-10.html>:
> [13:02:09] <ggm> in dynamic, see two things. NSEC+/-<e> is doing it
> on the fly. minimally cover. idea has been posted to ML. not in
> archive. use NSEC mechanism, good things, can use current resolvers
> to validate. would mean can deploy DNSSECbis without enumeration
> properties, if can implement this in server....
...
> [13:07:54] <ggm> Proposed way forward: fast-track epsilon in this
> group, review, try to see if will work, publish asap. so that things
> can be deployed today. in same time, continue on other solutions,
> without makeing choices.
There seem to be some assumption that online signing of dynamically
generated NSEC with "epsilon" domains coexist with DNSECbis.
I'd like to remind people about section 2.3 of protocol-09:
Each owner name in the zone which has authoritative data or a
delegation point NS RRset MUST have an NSEC resource record.
...
An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
RRset at any particular owner name. That is, the signing process
MUST NOT create NSEC or RRSIG RRs for owner names nodes which were
not the owner name of any RRset before the zone was signed.
This text imply to me that you cannot invent new owner names for NSEC.
I believe the above MUST's are not required for interoperability nor
are they necessary for successful operation of DNSECbis.
It seems the text may cause problems, if dynamic signing of NSEC with
epsilon domain names is used together with DNSECbis.
I raised this problem, in the context of lying NSEC, during the
DNSECbis last call. It was apparently ignored.
http://article.gmane.org/gmane.ietf.dnsext/5339
I maintain that the MUST cannot in general be verified by clients, and
hence should not be part of the specification. Further I believe that
the text prevent deployment of NSEC alternatives.
Thanks,
Simon
--
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/>