Remider: BIDI inter-label tests in -02

[Andrew Sullivan]

On Fri, Sep 05, 2008 at 07:01:32PM -0700, Erik van der Poel wrote:

> I don't think that the operator needs to test all possible paths for
> the label. The operator should just check against the parent (and the
> parent's parent, and so on). Is this reasonable? Or are there
> situations where the operator cannot know the normal parent?

I've been thinking about your latter question, and if I understand it
correctly I think it suggests a serious misunderstanding of the nature
of the DNS.  That might be the source of some of the confusion in this
discussion, so I'm going to try to outline exactly what will happen in
the case I'm thinking about.  If this is something already obvious to
you (or others interested in this thread), my apologies.

The fundamental problem lies in these terms "the parent" and "the
normal parent".  The _actual_ parent at a given moment could be
something other than the typed-in label.  I'm not sure what you mean
by "normal parent", but you likely mean "the next label up in the DNS,
as typed in by the user or otherwise delivered by the application".
Given that the identification of this label is in fact what's at
issue, such a term is faintly circular anyway.  But supposing that we
could identify it, it doesn't help, because that label might not
form part of the FQDN that's actually the parent.

In a DNAME substitution, the substitution happens at any point in the
processing of RFC 1034 section 4.3.2, step 3.  As you match down,
label by label, if you get to a node that is found to own a DNAME RR,
the DNAME substitution occurs.  (If this is confusing, there's a nice
clarifying chart at Table 1 in draft-ietf-dnsext-rfc2672bis-dname-14:
http://tools.ietf.org/html/draft-ietf-dnsext-rfc2672bis-dname-14).
Note that this can happen more than once, which means you can have
chains of CNAMEs and DNAMEs.  

Now, to return to the example case we were discussing,
<ALEF>.example.com is perfectly safe.  The problem arises, however,
when example.com is a DNAME to 3.com.  <ALEF>.3.com is problematic.
This has a few consequences:

1.  If we're serious in suggesting that the example.com operator needs
to perform the BIDI test on any IDNA registration, then the operator
presumably needs to perform the test when converting example.com to
3.com via a DNAME.  Of course, in this case the check will be on
already existing delegations underneath example.com, and if something
fails the test either the DNAME is not allowed or the delegations have
to be removed before the DNAME is inserted.  Now, since delegations
have to appear on both sides of a zone cut, this is possible to check,
but it may entail a pretty significant effect.  Moreover, in such a
case we are putting a limitation on what a zone operator may do with
their zone _every time_ they make a change of this sort, even if
they're not worrying about IDNA (they might well not know that there's
an IDNA below them.  Remember, the zone operator adding a DNAME will
quite probably have no easy way of telling that there's a BIDI U-label
below the target label: it's in the zone as an A-label).  This gives
the lie to the suggestion that this is a step that can be done
"pre-DNS", as I suggested in my note the other day.

2.  If we're serious in suggesting that you have to perform these
checks pre-resolution, then what we are saying is that applications
first need to perform all the resolution above the target QNAME,
perform the BIDI test on the resulting "real" FQDN, then finally hand
the tested A-label through to gethostbyname().  This sounds like a lot
of DNS work for something that's supposed to be happening
pre-resolution.

And anyway, as I've already suggested, making the BIDI test mandatory
automatically makes wildcards illegal for any domain that starts with
a digit.  Since a wildcard *.3.com would work for <ALEF>.3.com, the
wildcard ought to be prohibited by the registration rule.

> If the FQDN happens to run into bidi failures due to DNAMEs that were
> not anticipated (nor condoned) by the original registrant, then the
> lookup fails or the name will not be displayed in Unicode. So what?
> Eventually, people will learn not to generate FQDNs with such
> problems.

I think your faith that people will learn about how to operate the DNS
such that all the foot-guns remain unloaded is not entirely supported
by the historical evidence.  But more importantly, there's no reason
that a delegated zone _should_ be able to rely on some parent zone not
using a DNAME.  The child has no authority over the parent.  It might
not be too surprising to find one day that bigcorpexample.com has been
DNAMEd to 3gimundomergedcorps.com without anyone checking that none of
the regional offices will go off the air because of it.  But they'll
sure be annoyed when it happens.

A

-- 
Andrew Sullivan
ajs at commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/