Re: draft-arends-dnsnr-00

[Samuel Weiler <[e-mail]>]

Avoiding the terminology discussion entirely...

I'm confused about how DNSNR is supposed to work with hashed next
names.  Perhaps I'm missing something.  I'd like to be enlightened.

It looks like you're continuing to use DNSNR/NSEC3 owner names which
match "actual owner names", to borrow Ben's terminology.  For example
(and I'd love to see an example with hashed owner names in the doc):

example.com. 86400 IN DNSNR ? 1 34abc (hash(34abc+alpha)) types
alfa.example.com. 86400 IN DNSNR ? 1 34abc (hash(34abc+beta)) types
beta.example.com. 86400 IN DNSNR ? 1 34abc (hash(34abc+apex)) types

(Which ignores the authoritative-only bit and doesn't say how much of
the next name you're hashing, since I don't understand that part of
the discussion.)

What answer is given in response to a query for c.example.com?  The
beta DNSNR tells me nothing, since I can't tell what name was used to
create the hash, and I can't tell if c.example.com would be covered by
the DNSNR or not.

In other matters, I find the discussion of the authoritative only bit
in 2.1.1 confusing, if not misleading.  If you want to not have DNSNRs
for unsecure delegations (or optionally not have them), just say
that.  Make it clear whether the authoritative only bit is a per-zone
thing or applies per-span, like opt-in.  And the incomplete citation
in the first paragraph of 2.1.4 is likely to be inconsistent with not
requiring DNSNRs at each name (including those unsecure delegations).

Also, the presentation format of the hash value is inconsistent
between 2.1.2 (third paragraph) and 2.2.

-- Sam

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>