Subject: [dnsext] DNAME update draft UD bit

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 18 May 2009 15:42:23 +0200

Hi WG,

The DNAME update draft contains a new feature: the UD bit.  This bit is
used by a resolver to signal the authority server that CNAME synthesis
is not necessary.  It can be used to provide a lighter load for hosting
DNAME records.

Initially this feature was incorporated, more than a year ago I believe,
with lukewarm support (but not opposition) from the working group.  It
was believed that for IDN purposes DNAMEs might be used in the root, and
less load on the critical servers is a good thing.  I wonder if there is
still any reason to add a UD bit?

Against the UD bit are: the fact it takes on of the precious 16 EDNS0
flags.  Also cname synthesis support will be necessary anyway for legacy
resolvers.  And my personal adverse feeling towards more complexity,
signaling and negotiation to the DNS when it is not necessary.  Can we
take away the UD bit?

Best regards,
   Wouter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 May 2009 14:08:32 +0000

> Date: Mon, 18 May 2009 15:42:23 +0200
> From: "W.C.A. Wijngaards" <[email-masked]>
> ...

+1.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 May 2009 10:13:21 -0400

> still any reason to add a UD bit?

IDNA2008 (which is what the new version of the protocol is called),
unless it is modified considerably for how it stands right now,
removes most of the mapping from the older IDNA version (called
IDNA2003).  This means that things that were valid in IDNA2003 may or
may not be valid under a registry's (i.e. zone operator's) policies in
IDNA2008; and things that were _not_ valid in IDNA2003 may be valid
under the operator's policies in IDNA2008.

The IDNAbis WG's charger prohibits it from changing the IDNA prefix
(xn--) used on ACE names; while such a prefix change would seem to be
obvious when adopting a strictly-incompatible change such as IDNA2008,
for various other reasons the people working on this problem thought
that would be a bad idea.

Given that there will be a period where clients using both protocols
will be deployed, there will be some need to provide compatibility
mappings between the two IDNA versions for some period of time
(possibly infinitely long).  In the absence of ENAME (equivalent-name,
in which a given set of labels is just "swapped out" for an "equivalent",
wherever the former shows up), DNAME seems to be the best candidate.
Even if no root label ends up needing DNAMEs for this purpose, it is
all but certain that TLDs will need it.

I don't know whether that means we need the UD bit, but I thought this
would be important background to have when making the decision.

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 18 May 2009 10:42:04 -0500

> all but certain that TLDs will need it.

I think it is reasonable to assume that the use case for ENAME (or 
DNAME) extends to one or more elements of the anticipated set which may 
be added to the root within the next several years.

Eric

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 May 2009 11:57:55 -0400

[no hat]

> be added to the root within the next several years.

Well, let's be careful.  I made up ENAME out of whole cloth (because
there's some magical behaviour in it that currently conforms to what
people seem to want).  So if something is needed, it's going to be
DNAME or nothing.  (Besides, even if we knew how to invent ENAME so
that the magic result was in fact achievable -- and I'm of little
brain, so it won't be me who can do this -- it'd be a long time before
we were in a position to recommend it for use at the root.)

The right answer to Wouter's question, therefore, is whether the
additional complexity is worth the gains from UD.  

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.