[Gen-art] Re: Gen-ART Review of draft-ietf-dnsext-dns-name-p-s-01

[Geoffrey Sisson <[e-mail]>]

"Spencer Dawkins" <[e-mail]> wrote:

> I was selected as General Area Review Team reviewer for this specification
> (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Thank you for your time and effort in reviewing the document.

> I have a few comments that might be considered during IETF Last Call. These 
> comments follow.
> 
> Thanks,
> 
> Spencer
> 
> I was confused when I read in section 3. "Derivations":
> 
>    These derivations assume that all uppercase US-ASCII letters in N
>    have already been replaced by their corresponding lowercase
>    equivalents.
> 
> and then, a few paragraphs later, in section 3.1.1. "Derivation of DNS Name 
> Predecessor":
> 
>    4.  Decrement the value of the least significant (right-most) octet
>        of the least significant (left-most) label, skipping any values
>        that correspond to uppercase US-ASCII letters, and then append
>        the least significant (left-most) label with as many octets as
>        possible of the maximum sort value.
> 
> Where did the uppercase US-ASCII letters come from? (I thought they had 
> already been replaced)... There is similar text in 3.1.2, 3.2.1, and 3.2.2 
> (they are pretty much symmetrical), and further into 4.2. If (3) said 
> "lowercase have already been replaced by uppercase", all this would make 
> perfect sense to me - am I misunderstanding?

You're correct that all uppercase US-ASCII letters in the domain name
have been converted to lowercase.  However, an uppercase letter may be
encountered when incrementing (3.1.2.3 and 3.2.2.3) or decrementing
(3.1.1.4 and 3.2.1.4) an octet.  For example, if an octet contains '@'
and it gets incremented, the new value would be 'A'.  Similarly, if an
octet contains '[' and it gets decremented, the new value would be
'Z'.  To maintain canonical sort order, these value must be skipped,
i.e. increment('@') -> '[' and decrement('[') -> '@'.

Note that the logic above isn't explicitly set out, as the derivation
has been generalised for possible modifications, in particular the
exclusive use of LDH ('letter-digit-hyphen') values.  This problem
doesn't arise in LDH as increment('9') -> 'a' and decrement('a') -> '9',
which sidesteps the uppercase issue altogether.

> In section 4.1. "Test for Existence", why is the following text saying 
> "should reflect"? I'm wandering around "should/SHOULD" and "must/MUST" here. 
> If it IS "should/SHOULD", when is it OK for the synthesized NSEC RR to NOT 
> reflect the RRset types that exist?
>
>    If it does, either a standard non-synthesised NSEC RR
>    should be used, or the synthesised NSEC RR should reflect the RRset
>    types that exist at the NSEC RR's owner name in the Type Bit Map
>    field as specified by Section 4.1.2 of [RFC4034].

draft-ietf-dnsext-dns-name-p-s is intended to compliment
draft-ietf-dnsext-dnssec-online-signing, which has been submitted for
publication as a standards track document.  Section 4.1 really only
expands upon paragraph eight of Section 2 of that document, which
says:

   Before answering a query with these records, an authoritative server
   must test for the existence of names between these endpoints.  If the
   generated NSEC would cover existing names (e.g. exampldd.com or
   *bizarre.example.com), a better increment or decrement function may
   be used or the covered name closest to the QNAME could be used as the
   NSEC owner name or next name, as appropriate.  If an existing name is
   used as the NSEC owner name, that name's real NSEC record MUST be
   returned.  Using the same example, assuming an exampldd.com

We avoided RFC 2119 key words in draft-ietf-dnsext-dns-name-p-s as we
thought that otherwise things might get messy.  In view of your
observations, perhaps it would make sense to drop Section 4.1 from the
document altogether?

> Section 4.5.1. "Restriction of Effective Maximum DNS Name Length" worries 
> me - the text correctly states the possibility that you'll get a longer name 
> via dynamic DNS/zone transfer, and if this can happen, I would think that 
> it's better to disallow the optimization. 

I believe it shouldn't be too difficult for an implementation to adapt
to the introduction of a longer label.  The predecessor/successor
functions could be paramaterized to take into account the longest label
in the zone.

I would be reluctant to remove this optimisation as few zones contain
labels that are even half the maximum label length, so that the savings
in NXDOMAIN response size that might be realised by utilising this
optimisation for these zones is not inconsiderable.

Thanks again.

Geoff

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art