Developper information
From IUCG - Internet Users Contributing Group
Contents |
091104 14:31 Erik van der Poel
There are several different operations that you can perform on the labels of a domain name, and these operations occur at different times. Here are just a few examples:
- (1) single-label registration time
- (2) multi-label DNAME definition time
- (3) multi-label domain name lookup time
- (4) multi-label domain name display time
idnabis-protocol-17 focuses on (1) and (3). For (1), it says:
"If the proposed label contains any characters that are written from right to left it MUST meet the BIDI criteria [IDNA2008-BIDI]."
Note that the above is talking about a single label. For (3), the protocol says:
"Verification that the string is compliant with the requirements for right to left characters, specified in [IDNA2008-BIDI]."
Note that the above is talking about a "string", which presumably might contain more than one label. As far as I can tell, IDNAbis does not say much about operations (2) and (4) for bidi.
idnabis-bidi-06 says:
'A "BIDI domain name" is a domain name that contains at least one RTL label.' and
'The following rule, consisting of six conditions, applies to labels in BIDI domain names.'
Clearly, the above is talking about multi-label domain names. However, the rule itself tells you how to test a single label, so that part of the spec can be used at registration time (1).
Let's take an example. One of our favorite examples is 3com.com. At registration time, when we are registering the label "3com", there is no way of knowing that someone may, at some point in the future, define a DNAME that breaks the IDNAbis bidi rules. Since there is no way of knowing that, the registration is simply allowed.
Later, someone tries to define a DNAME, say, HEBREW.3com.com where HEBREW is a string of right-to-left Hebrew characters. At this point, the implementation might choose to check the IDNAbis bidi rules and either reject the DNAME or emit a warning about it if it breaks the rules.
Even later, someone tries to lookup HEBREW.3com.com. The implementation can check the entire domain name against the IDNAbis bidi rules. It does not have to check since the protocol says "SHOULD".
Yet later again, someone tries to display HEBREW.3com.com. The implementation probably should check against the IDNAbis bidi rules. If the domain name breaks the rules, the implementation can refuse to display it in Unicode form (choosing Punycode instead), or produce a warning of some kind.
So, the IDNAbis drafts are in some sense incomplete, since they don't fully address DNAME time (2) and display time (4). But if the WG does start to discuss these, you can imagine what my position is going to be.
Erik
091104 15:38 Gihan Dias
the WG concluded that the registry or registrar had to be cognizant of this kind of anomaly and reject problematic registration requests.
Unfortunately, it is impossible to make sure *all* registrars (or even all registries) would uniformly handle problematic requests.
We need mandatory rules for registrations, which are checked by software in lookups.
091104 15:47 Andrew Sullivan
(2) multi-label DNAME definition time
The problem there is that there is _no way_ to have a rule about this. It's not that we never thought about it; it's that you can't possibly specify a rule that will solve this problem.
If there are zone cuts, it is _just impossible_ to know what might end up lurking on the other side of the cut, not only at the time of registration but also later, since a DNAME could be introduced at a later date (indeed, that's actually one of the target use cases of DNAMEs).
091104 15:59 Vint Cerf
There is no way to guarantee this uniformity; nor was the WG able to define every possible case in which problems would arise. The range of possibilities is too great given the huge number of new symbols introduced by IDNA. This was debated extensively during the last 2 years and that is the working group consensus as I see it.
901104 16:16 Gihan Dias
I understand.
My point is that if the WG was unable to reach a consensus, then registrars would not be able to do so either, so what we'll have is an "anything goes" situation.
At the least, we (software developers, sys admins, website owners, advertising companies, users, etc.) need to be aware of the problems.
091123 16:23 Erik van der Poel
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 http://tools.ietf.org/html/rfc2672
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.
091104 16:32 Andrew Sullivan <ajs@shinkuro.com>
My point is that if the WG was unable to reach a consensus, then registrars would not be able to do so either, so what we'll have is an "anything goes" situation.
Yes, but not by registrars. Registry operators need to make policy that makes sense given the characters they're willing to support. Note that the documents explicitly say, "Registries need to develop policy in this area." Will this vary from registry to registry? Yes: that's part of the goal. The idea is to make the protocol flexible enough that different operators can make different policies to match their different circumstances.
At the least, we (software developers, sys admins, website owners, advertising companies, users, etc.) need to be aware of the problems.
You bet. But how is that different from being aware of the linguistic environment in which your software runs, your systems work, or your advertising and webites are interpreted? For instance, if you're aiming to attract fans of 1970s Detroit automobiles, you'd be pretty foolish to name your site "underthebonnet.com". How is this different?
091104 16:37 John C Klensin
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 backfire.
091104 16:48 Andrew Sullivan
I was talking about a single DNAME definition, not about other DNAMEs that might enter the picture at some point.
That sounds like operational guidance, not protocol. "Be careful" is not a useful thing to put in a protocol document, even if it's perfectly good operational advice.
I think you're right that it'd be nice to put together a set of guidelines for what people ought to do when operating IDNA-aware zones. There are several sets of considerations that need to be taken into account, and such advice ought indeed to be offered.
The IDNABIS WG is not the forum that should generate that advice: hardly anybody here is a DNS operator. I in fact previously offered (in a fit of insanity) to put together a -00 draft outlining such advice. I think it should probably be taken to DNSOP to see if there's any interest. But the response to me (one with which I have considerable sympathy) was that it'd be crazy to try to produce operational suggestions for a protocol that hasn't made it out of the IETF's process yet.
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 http://tools.ietf.org/html/rfc2672 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).
I think you don't fully understand how DNAMEs work. Your example does not alias "frobozz.example." to "frobozz-division.acme.example.", because DNAMEs don't alias the owner name where the DNAME appears. That DNAME _does_ alias www.frobozz.example to www.frobozz-division.acme.example. It also aliases א1.frobozz.example to א1.frobozz-division.acme.example. In fact, it aliases
- .frobozz.example. The problem is to know whether there is in fact
the label א1 in frobozz-division.acme.example, and without controlling both zones, the administrator of frobozz.example doesn't know (and can't know unless zone transfer is permitted or frobozz-division.acme.example is running DNSSEC with NSEC). This is why there is a problem. DNAMEs don't do what a lot of people think they do.
