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

[Alex Bligh <alex@alex.org.uk>]

Olaf,

Apologies for replying without reading the perl first, but I am
trying to understand your thinking here

--On 29 November 2004 12:29 +0100 "Olaf M. Kolkman" <olaf@ripe.net> 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.

All the complexity in draft-sisson-dnsext-dns-name-p-s is because it needs
to support all possible values in the "original" zonefile (i.e. all legal
domain[*].

[* = 'domain' in the mathematical sense, i.e. set of legal input values
to a function - terminological overload - arrrgghh ]

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

I note that for the purists, names with \000 and \255 in labels,
and (I think) labels between epsilon and delta, are restricted in
their use (i.e. either must not exist or it cannot be shown securely
either that they do or don't exist). I do not think that is a practical
issue for most users.

Alex


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