[bind10-dev] flaws in reversed name-based approach for getting the "previous name"

[JINMEI Tatuya / 神明達哉]

At Tue, 27 Sep 2011 14:00:26 +0200,
Shane Kerr <shane at isc.org> wrote:

> > What should we do with these cases?  I can think of two possibilities
> > (there may be more):
> > 
> > 1. ignore the problem as a minor case (or say "use in memory data
> >    source if your zone contains this problem")
> > 2. use some normalized form that ensures the sorting result as a
> >    string is identical to the DNSSEC order.  For example, if we
> >    represent all characters in the "\DDD" form, that would work (note
> >    that '.' < '\' coincidentally, so there won't be a problem like '.'
> >    vs '-')

> I've always considered the possibility that we may want two types of
> SQL-based data source:
> 
>      A. "Captive", where BIND 10 controls the data
>      B. "Free", where another application can modify the data
> 
> Right now we've got a sort of mix, where we don't expect external data
> modification, but it mostly works.
> 
> I think that perhaps we can commit more firmly to stating that our
> current data SQLite source is option A, "captive". In that case, using
> an "ugly" format for the data should not be a big problem.

Actually, I personally thought an "ugly" format could be acceptable
quite independently from captive vs free.  The "reverse" name is not
so easy to construct by hand, so even if it might be a bit more
readable, we'll see a broken zone especially regarding the ordering in
a "free" type of data source.

Whether we allow the "free" type or firmly reject it seems to be a
bigger issue.  Right now, our API doesn't assume we control everything
(i.e., we assume we'd allow a "free" type of data source to exist) and
perform stricter validation on data from data sources that we wouldn't
have to do if we prohibited that type (note: this is not only for
DNSSEC related code).

So the decision affects some core part of the implementation (and
perhaps even the API design).  I personally don't have a strong
opinion; I'm okay with whatever actual operators want.  But if we
make the decision of limiting to the captive mode, it should be done
by quite sooner.

Now, going back to my original point...

> Using \NNN will bloat the size of the database a bit, although it is
> easy to read for most programmers. An alternative might be to simply use
> hex encoding, which would result in strings like:
> 
>   EXAMPLE.COM -> COM.EXAMPLE -> "636F6D.6578616D706C65"
> 
> Since ASCII hex numbers preserve the same order as their original
> characters, and all of [0-9A-F] sort after '.', this should have the
> correct behavior.

Hmm, maybe this one is better (btw you already seem to prefer handling
this correctly than ignoring it).  I used the \DDD format so that the
result will still be valid domain name, but "reverse names" would
actually be mostly useless as a domain name, and in any case we need
to develop a specialized converter (that is, we cannot use an existing
libdns++/pydnspp method or function to generate this format), so the
implementation overhead would be the same.

> The functions to convert to/from these values are straightforward, so we
> shouldn't carry a lot of extra code for correctness.

True, and we wouldn't necessarily need to convert "from" the hex
format.  We need the "to" part to write the database, and the
converted values are only used by the database internals (we only use
the resulting rows after they are sorted by the database, and we are
not interested in the "reverse hex" field of the row in our DNS
related operations).

---
JINMEI, Tatuya