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

[Mark Andrews]

In message <m239f8tysq.wl%jinmei at isc.org>, JINMEI Tatuya / =?ISO-2022-JP?B?GyRC
P0BMQEMjOkgbKEI=?= writes:
> 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')

At the DNS level there is no such restrictions.  LDH etc. are all upper
level restrictions.
 
> - 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
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org