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

Shane Kerr shane at isc.org
Tue Sep 27 12:00:26 UTC 2011


Jinmei,

Thanks for clarifying this issue.

On Mon, 2011-09-26 at 12:32 -0700, JINMEI Tatuya / 神明達哉 wrote:
> 
> This is a clever way and should work in most cases in practice, but
> I've realized it doesn't work in some less common cases.

<snippity>

> 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 '-')
> 
> Option 2 is better in terms of correctness, of course, but it has its
> own drawbacks: It requires more code, and it would be more difficult
> to edit the zone in the database directly (i.e., not from our API).  I
> personally still incline to go for option 2 (or any other way that
> ensure the correct result) because I suspect the case with '-' is not
> so uncommon, and also because to claim to be "reference
> implementation" I believe we should generally not allow incorrect
> behavior simply because it's minor.

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.

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.

We could rename the column from 'rname' to 'revhexname' to make it a bit
less obscure.

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

--
Shane




More information about the bind10-dev mailing list