Distributed configuration of "private" IDNA (Re: IDNA and getnameinfo() and getaddrinfo())

[Nicolas Williams]

On Thu, Jun 17, 2010 at 05:28:04PM -0400, John C Klensin wrote:
> The DNS works as well as it does partially because, while caches
> have to follow a few specific rules (including those for
> octet-level matching of labels in length-label pair form),
> caches can be pretty dumb.  Asking caches to be smart and able
> to reflect whatever matching rules the authoritative servers
> (and/or their authoritative parents) think appropriate means
> _really_ smart caches.

Yes.  That might be realistic if correct implementations existed that
were BSD-licensed, portable and very self-contained.  As it is this idea
is not realistic.

> And then there is the DNAME possibility and the consequent need
> for new primitives that authoritatively identify the tree in
> which an FQDN target is really located.
> 
> If one wanted it to work, I suggest that one would want to start
> by deprecating DNAME and maybe CNAME so that there was exactly

I don't think you'd have to deprecate CNAME.  In any case, CNAME can't
really be deprecated -- it's too useful and too widely in use.  I can
see operators coming at us with pitchforks if we tried.

> one way to access a particular DNS node.  Then one would need to
> think about at least one of a new Label Type (my current
> favorite), a new Class (probably not good enough, my early
> proposal to that effect notwithstanding), or an EDNS0 option to
> permit a client to differentiate among servers applying
> different rules (as far as I know, not yet comprehensively
> evaluated by anyone).  The three of those options have two
> things in common:
> 
> 	(i) Good luck getting them deployed soon enough and
> 	widely enough to do anyone any good. Think in decades.
> 	
> 	(ii) We would still be stuck with legacy A-labels in
> 	zones and the need to sort them out in applications.
> 	Some zones could be expected to at least stop adding
> 	more of them but those that were driven by either market
> 	or compatibility considerations would probably discover
> 	that they had to deploy every name according to both the
> 	old (IDNA A-labels) and new (e.g., UTF8 with UTR46-2025)
> 	conventions.   Synchronized domains anyone?  :-(

(ii) is a huge problem.  IDNA is a reality now.  Which is why we must
work with IDNA rather than for alternatives.

> While you are at it, I'd like a pony.  Actually, I'd like a
> whole corral full of ponies.

I want some too.

Nico
--