IDNAbis spec

John C Klensin klensin at
Wed Nov 4 16:37:15 CET 2009


This would create more vunerabilities than it would eliminate.
The argument for "more run time checking" involves not trusting
zone administrators.  I think we have found a decent balance on
that subject -- not going quite as far as we possibly could, but
striking a balance with the other considerations, including
different practices by different languages using the same
script.  If I were running a registry, I'd certainly consider it
reasonable to apply some of the tests that you suggest.  But
remember that DNAMEs can be created by anyone with appropriate
dynamic update privileges and in zones anywhere in the tree
pointing to anywhere else in the tree.  If we say "the client
MUST make these checks", then people will rely on their being
made... and bad-guy clients simply won't.

I do believe that, at some point, the world is going to need
better sets of "guidelines to registries and zone administrators
for best practices" -- maybe globally (e.g., "you should think
about these issues") but more likely on a per-language basis.
But Rationale already does some of the former (personally, I'd
welcome going a bit further, but WG consensus about what to say
has been hard to achieve and it is even harder to know where to
stop) and it is worth noting that there are already several
per-script efforts for the latter (starting with the JET work
that also brought us variants).

But trying to make a normative requirement would, I fear, just


--On Wednesday, November 04, 2009 7:23 AM -0800 Erik van der
Poel <erikv at> wrote:

> I was talking about a single DNAME definition, not about other
> DNAMEs that might enter the picture at some point. If somebody
> were to implement a tool that checks DNAMEs before inserting
> them into a zone, that tool could check a *single* DNAME
> against the IDNAbis bidi rules.
> Here is an example from
> frobozz.example.  DNAME    frobozz-division.acme.example.
> When the tool is about to insert this DNAME into the zone, it
> can apply the bidi rules to the full domain name (which
> consists of multiple labels, as you can see).
> Even if some other DNAMEs were defined later that would allow
> the creation of domain names that break the bidi rules, the
> client can check the rules at lookup time and at display time.

More information about the Idna-update mailing list