Re: NSEC+-epsilon (whitelies server) proof of concept.

[[e-mail] (Geoffrey Sisson)]

Alex Bligh <[e-mail]> writes:

> --On 29 November 2004 12:29 +0100 "Olaf M. Kolkman" <[e-mail]> wrote:
> 
> > When the proxy receives a query it will return a "REFUSE" if the query
> > name contains "\000" or "\255" in one of its labels.
> 
> I am presuming you *do* in fact mean "\000" or "\255" *in* any one
> of its labels, not "\000" or "\255" *as* any one of its labels.
> 
> If so, then this is a pragmatic rather than a purist approach (that isn't a
> criticism, that's an observation), as it effectively prevents any existing
> labels with "\000" or "\255" in from working (obviously). But if that's the
> case, i.e. if one is prepared to consider certain octet values as reserved
> (and thus unavailable for the raw zone file), then I think it's possible to
> construct far more simple successor and predecessor functions than those in
> draft-sisson-dnsext-dns-name-p-s, (especially if one enforces one octet
> stricter length restrictions) which are much simpler to code, understand
> and debug. For instance, in terms of successor functions, if one limits the
> function's domain[*] to labels not containing \000 and \255, less than 63
> (not 64) octets, and with a similar change to the total name length
> restriction, then one could define the successor function as simply
> concatenating "\000" to the label. The result of the successor function is
> not going to need a successor itself, as you'll be returning REFUSE as the
> QNAME had a \000 in a label.

I've added a comparable optimisation to sisson-dnsext-dns-name-p-s-01.
A copy of the `draft' draft is available at:

    http://www.panix.com/~geoff/draft-sisson-dnsext-dns-name-p-s-01pre2.txt

However in a delegation-only domain, the owner names of glue RRs may
still be 255 octets in length.  Any optimisation involving restriction
of maximum length would require ensuring that no owner name of any
glue RR exceeded the restriction.  However I don't believe such a
restriction would be unpopular with registrants: at the moment there
are only two glue RRs in the co.uk zone which are longer than the
maximum label size alone.

> > This policy is
> > not strictly needed but it is to address the issue that the the NSEC
> > next name should be part of the zone.  By refusing queries for the
> > names that contain the "maximum and minimum sort values" that have
> > been inserted in the +-epsilon process, we "weasel" our way out of the
> > question if these names are or are not in the zone, the client will
> > just never be able to know because of our policy.
> 
> Yes-ish. I think you can generalize that concept as follows:
> 
> If it is permissible to place further restrictions on valid label names by
> a set of rules (X), then by defining the successor/predecessor functions
> S', P' as ones which for any input value compliant with rules (X) generate
> a near successor/predecessor which are not compliant with rule (X), and
> refusing queries for QNAMEs breaching rule (X), we avoid the wildcard /
> existence problem.
> 
> I am not ENTIRELY sure your approach conforms to the above for all
> cases (I am thinking of maximal DNS length) in that I think the
> successor might under certain circumstances not have a \000 or \255 in
> it. From the draft:
> 
>    DNS name is the maximum DNS name length:
> 
>       y  = fooooooooooooooooooooooooooooooooooooooooooooooooo.ooooooooo\
>            oooooooooooooooooooooooooooooooooooooooooooooooooooooo.ooooo\
>            oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.o\
>            oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo\
>            oo.example.com.
> 
>       y' = foooooooooooooooooooooooooooooooooooooooooooooooop.ooooooooo\
>            oooooooooooooooooooooooooooooooooooooooooooooooooooooo.ooooo\
>            oooooooooooooooooooooooooooooooooooooooooooooooooooooooooo.o\
>            oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo\
>            oo.example.com.
> 
> which does not have a \000 or a \255 in it. You can solve that trivially
> by putting a one lower limit of maximum DNS name length in the input
> zone.

Note that you will always be able to devise a QNAME which will result
in a predecessor or successor which not only doesn't contain \255 or
\000, but is also a valid owner name in the zone.  These are unlikely
to occur in normal practice, though.

Regards

Geoff

--
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/>