Remider: BIDI inter-label tests in -02

[Erik van der Poel]

On Fri, Sep 5, 2008 at 3:12 PM, Andrew Sullivan <ajs at commandprompt.com> wrote:
> Dear colleagues,
>
> This is probably rambling.  I'm still trying to make clear the problem
> I've been picking at since Dublin.
>
> On Fri, Sep 05, 2008 at 11:15:51AM +0200, Harald Alvestrand wrote:
>
>> (As a personal preference, I would prefer to make it a SHOULD, or even a
>> "MUST if the following label is known by the BIDI test" - but that did
>> not seem to be the WG's consensus in Dublin, so that's not what the text
>> says).
>
> I oppose very strongly anything stronger that MAY.  The basic problem
> is that the BIDI test as it stands is not restricted to application
> space -- that is, it's not out in the area where DNS doesn't need to
> care.
>
> The current protocol document has the BIDI test happening at
> registration time.  Now, if what we claim is that a zone operator MUST
> NOT register a label that violates the principle in the current text,
> then what we are requiring is that the operator test all possible
> resolution paths for the label.

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?

> This could be quite a serious
> checking burden -- particularly when one considers that one presumably
> ought to check against future conversion of the parent name to a DNAME,
> which creates a new path that one didn't have when one did the
> checking.  Since we haven't invented a mechanism by which to tell the
> parent operator, "Hey, I got a BIDI down here!  Don't screw up!" we
> can't really perform such a check.  Therefore, this registration check
> is a hedge, but not an assurance, about the validity of the entire
> FQDN.  The DNAME example isn't just hypothesizing, either, since many
> operators seem to be planning to do "variant" work with various DNAME
> tricks.
>
> Worse, the _other_ thing that the protocol document currently says is
> that the BIDI rules SHOULD be applied at resolution time.  What an
> inter-label validity check does is invent a whole new category: the
> "validity" or "invalidity" of a FQDN, where that (in)validity comes
> not from some property of some label, but from an emergent property
> of the combined labels at a given moment in time.  Again, remember, it
> is trivial to introduce a problem here with a DNAME.

Why can't the pre-resolver just convert the FQDN to a series of
U-labels and then run the bidi test across all of the labels? When the
test fails, it could either (a) refuse to lookup the domain name or
(b) refuse to display the domain name in Unicode form.

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'm probably missing something... :-)

Erik

> If I were the
> registrant of alephnull.com (it's a real name -- I just checked), I
> might be very tempted in future to make it a DNAME for <ALEF>-0.com.
> But this could easily create problems, and problems that would be
> obvious nowhere at the level where a DNS operator will look.  (If the
> answer is, "well, then, we need to specify that here", then I'll point
> out that you are thereby committing yourself to updating DNAME at the
> very least.)
>
> Moreover, we have a similar issue in the presence of wildcards.  If
> there's a wildcard at 3.com, then <ALEF>.3.com ought to be valid.  But
> according to this test, it won't be.  Why not?  certainly not because
> of any property of <ALEF>.  And not because of any property of 3.com
> either.  What we're really doing is inserting a new rule that doesn't
> match step 3 in section 4.3.2 of RFC 1034 (that's the one that starts
> "Start matching down, label by label, in the zone.").
>
> Now, maybe all of this is just the unfortunate use of the word
> "resolution" in the protocol document, and maybe that's actually what
> needs to change.  It seems to me, after all, that what protocol is
> talking about is neither registration nor resolution, but
> pre-registration and pre-resolution.  It's like a filter that goes on
> before you get to the resolver.  I imagine the IDNA application calls
> getidnbyname().  That is a bunch of rules that performs preprocessing,
> makes decisions, and then either errors or hands on to
> gethostbyname(), which then does the usual DNS handling.  In case of
> an error, there are two possible kinds: IDN errors and DNS errors.
> The former aren't even related to the latter in a strict sense: DNS
> error codes are only ever going to be for things that reach the DNS itself.
>
> If we adopted that sort of language, I'd probably be a lot more
> comfortable.  But I don't think that's the way the documents are
> currently expressed (even if it's what's intended).  Until we get
> close to something like that, I have to oppose recommendation or
> requirement of any inter-label checking.
>
> A
>
> --
> Andrew Sullivan
> ajs at commandprompt.com
> +1 503 667 4564 x104
> http://www.commandprompt.com/
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>