Implementation questions (digressing from...) / A DNAME issue

[John C Klensin]

--On Thursday, January 01, 2009 11:12 PM -0500 Andrew Sullivan 
<ajs at shinkuro.com> wrote:

> On Thu, Jan 01, 2009 at 08:33:18PM -0500, John C Klensin wrote:
>
>> And, if you think that is clear to a non-specialist, I look
>> forward to IETF Last Call :-(
>
> It's currently a WG I-D, and it hasn't passed from WGLC for
> other reasons.  Nevertheless, questions about the draft that
> show up how it is not clear to someone with a passing
> knowledge of DNS would be welcome on the
> namedroppers at ops.ietf.org mailing list.

I will try to read the draft and make suggestions.  It may be 
that the terminology is defined well enough elsewhere to make 
the paragraph clear (it would be a first).  Getting me to 
subscribe to, and actively follow, the namedroppers list would 
be a much harder sell -- been there, done that.

>> If I correctly understand Vaggelis's concern, the problem
>> isn't  (only) the A RRs, but the MX RRs and anything else
>> that happens  to be lying around the zone apex/ tree location
>> of the DNAME RR  itself(SRV, AAAA, NAPTR, etc.).
>
> Sure.  But in delegation-centric zones (which is after all
> surely what the DNAME answer is supposed to be addressing)
> most of those record types should be on the other side of the
> zone cut.  I hate to say, "Don't do that," but if we're going
> to make the zone operators responsible for significant parts
> of the way things work, then we have to rely on them to tell
> delegated zone operators bad news sometimes.

Let me play devil's advocate for a moment and see if I can state 
the counterargument.

IDNs introduce a new issue into the DNS, an issue of perceived 
ambiguity of labels.   One can look at that issue as visual 
confusion (in "sign on the side of the bus" form) or as 
confusion caused by operational decisions made elsewhere (e.g., 
mapping all digits to European ones and then viewing digit input 
and display as localization matters) but the problem exists 
independent of misbehavior (phishing or otherwise) issues and is 
not one that can be solved in the general case by anything that 
clients can do or by anything registries can to that doesn't 
involve aliasing.

This issue exists both within-script (because of encoding 
variations with Unicode, including but certainly not limited to 
the Greek cases) and between-script (e.g., because of one 
language written in multiple scripts or a desire to associate a 
"new" IDN with an older Latin-based label).

In reality, we might have had these issues all along, but the 
principle that "color" and "colour" weren't going to match was 
established long before DNS names became popular among end users 
and those trying to sell things to them.   With IDNs, we've had 
various ICANN-related and other "governance" groups helping us 
out by establishing the firm belief that aliasing is possible 
and obvious and that it can, should, and does work in the 
obvious-to-them way.   Whether we need such help or not, we have 
it (see below).

All of the important cases turn out to be intra-zone references. 
Anything else violates the administrative hierarchy principle by 
requiring that separate pieces of the hierarchy be managed in a 
coordinated way.  The thing we know for sure is that "separate 
hierarchy, coordinated management" isn't going to work well for 
anything with any complexity, e.g., pairs of zones containing 
delegations and sub-delegations.  If nothing else, the caching 
model and its use of TTLs based on time of record acquisition 
virtually guarantees that the trees will become unsynchronized, 
to say nothing of the fact that keeping things synchronized when 
there are lots of entries (e.g., a traditional zone file, 
whether those entries are delegation records, point to 
traditional hosts offering services, or otherwise) is an 
administrative nightmare.

Most top-level IDN ideas are problematic for exactly that 
reason: people conceive of them, not as completely independent 
entities with non-ASCII names, but as surrogates for existing 
domains.  That is especially common in the country-code case, 
where the current model essentially requires that surrogate 
relationship, regardless of how they are actually managed.  But 
any real surrogacy relationship requires either aliasing or 
somewhat parallel management of separate trees (whether on a 
zone-by-zone or delegation-by-delegation within a zone basis). 
"Don't do that" (or its traditional variation "just say no" may 
very well be the right answer, but, with ICANN's help, that is 
not a choice we are going to be able to make or impose at this 
point --operational reality has gotten away from us and the only 
choices are whether we want an alias type that does the right 
thing or or want to encourage an environment in which people get 
regularly surprised by the side-effects of people trying to 
manage synchronized zones and subtrees.   In my devil's advocate 
role, I believe the latter is irresponsible.  If DNSEXT says 
"don't do that and, if you do, it is not our problem", that 
ultimately becomes a sign of IETF being out of touch with 
operational reality.

It is possible to suggest that, with a different structure than 
ICANN's, or even if ICANN had followed its own original 
recommendation, we would not be facing this situation, but it is 
now part of our reality.

>> nodes only do not apply.  If that case is going to be common
>> enough, it is time to invent a third alias type that, for
>> that  limited circumstance, does what people keep wanting and
>> expecting DNAME to do.
>
> If people need something that really does alias a whole zone,
> then we need an RRTYPE, yes.  But keep in mind that there are
> serious problems with relying on a new RRTYPE for this use
> case, most of which boil down to "we need to replace all the
> resolvers in the part of the Internet we want to reach."  If
> we're going to do that, I suggest that IDNA is maybe the wrong
> approach; we maybe need DNS2.  That seems like a tall order.

Again playing devil's advocate, I suggest that "I/we don't like 
this, therefore it maybe requires DNS2" is spurious.  One could 
reasonably wish for an aliasing model that would use a single 
RRTYPE, not two or three (or for no aliasing requirement at 
all), but the type of mechanism I suggest is not inconsistent 
with the existing model.   Since I had it explained to me eight 
or nine years ago, I've perfectly well understood why a 
cross-zone, general purpose, alias mechanism needs to work only 
on subtrees... and why that was ok for its intended purpose of 
aiding transition.  But this is a different sort of requirement, 
one for permanent aliases within a given zone.  And, 
incidentally, unless I don't understand your terminology, 
whether a zone is "delegation-centric" either has nothing to do 
with it or the zones of interest have exactly that property, 
with a cluster of names consisting precisely of delegation 
records at one node and and one or more alias nodes pointing at 
it.

As far as the deployment difficulties are concerned, certainly I 
recognize  them.    But the people who want IDNs, especially at 
levels of the tree at which name management is not under the 
direct administrative control of the entity "owning" the zone, 
are highly motivated to get them to actually work.  "If you want 
to support surrogate names, then you are going to have to be 
sure that the relevant infrastructure is upgraded" is a much 
more reasonable story --and one that is more likely to be 
heeded-- than "don't do that" or "forget about those 
surrogates".   After all, we already know the alternative; you 
and Vaggelis have explained what is necessary and the 
difficulties of maintaining it.

    john