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

[JINMEI Tatuya / 神明達哉]

At Mon, 26 Sep 2011 12:32:17 -0700,
JINMEI Tatuya <jinmei at isc.org> wrote:

> In our current sqlite3 schema and manipulation interfaces, we used
> "reversed" names to identify the "previous name" in the DNSSEC order
> of a given name. [...]

> 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.
[...]
> 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 '-')

According to today's biweekly call, the consensus seems we should
address this issue.  In that case I personally think Shane's proposal
is simple and effective enough.  Stephen mentioned some possible
alternatives in the call, but I didn't fully understand them at that
time, much less whether they are better than Shane's.  If think they
are better, could you explain your ideas again here? > Stephen

Some other related notes:
- The consensus on the slightly related issue of whether to allow
  non-captive mode seemed that we should allow it, at least for some
  backends.  But as I said in my other message in this thread, I
  personally don't think that affects the solution to this problem (if
  someone disagrees please speak up)

- In the call Joao mentioned that name label characters must be 7 bit
  (so there cannot be a domain name like "\255.example.com.")  Even if
  that's true we still have the problem due to '-' vs '.', '\.', etc,
  so it shouldn't affect the main point of this discussion.  But (if I
  understand Joao correctly) I didn't think we had such a restriction
  in label characters.  RFC2181 even seems to explicitly emphasize
  that we don't have such a restriction:

     [...] any binary string whatever can be used as the label of any
     resource record.
     (In Section 11, 'Name syntax')

- From a quick look, PowerDNS 3.0 seems to use a similar approach as
  ours (actually I cannot think of any way that is essentially
  different from this if we want to achieve the goal via a
  general-purpose database), but it converts '.' as the label
  separator to ' ' (a white space), e.g., "a.example.com." -> "com example a"  
  It will solve the problem of '.' vs '-', but I suspect it will still
  have a problem with other escaped characters such as \. (in fact, I
  suspect PowerDNS generally doesn't work well if the qname has an
  escaped character even without DNSSEC).

---
JINMEI, Tatuya