Subject: [dnsext] DNSEXT charter and treating DNS names as "the same"

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Aug 2010 09:36:49 -0400

Dear colleagues,

One of our primary goals for DNSEXT at IETF 78 was to get feedback
from the user community (in particular, we aimed at application
developers) who have the "aliasing" and "sameness" problem(s) with the
DNS.  Unfortunately, we were unable to attract many such participants.

It is clear to us that none of the proposals now before DNSEXT
addresses all the problems that people have.  As far as we are able to
tell, there are needs with respect to domain names, with respect to
whole trees in the DNS, and perhaps with respect to individual labels
no matter where they might appear in a domain name.  None of the
proposals handles all of these, and some of these needs are not
addressed at all.

We appear to be faced with a choice among three basic strategies:

    1.  Experiment: Since we don't know what the problems are, but we
    have people proposing solutions, we could adopt the proposed
    solutions experimentally, and evaluate in (say) five years whether
    the proposals solved the problems people have.

    2.  Limp along: We could accept that no proposal will solve
    everything, and "limp along" by standardizing properly the
    proposals we have: work towards clarity and precision in the
    problem statement and then proceed to work on the proposals
    themselves.

    3.  Kick it upstairs: A basic problem in all of this is that the
    DNS does not have a presentation layer.  Domain names end up being
    used in presentation contexts, and that's what's broken.  So, we
    could say that there is no problem here for the DNS, but that we
    are ready and willing to support building a presentation layer
    atop the DNS.  Such a specification needs to come from elsewhere.

The problem with (1) is that some of the proposals are simply
impossible to do as experiments (if we change the rules for CNAME,
they're effectively changed forever whether we like it or not).  In
addition, we think it would be a very bad idea to perform such an
experiment in the root, but we expect that there would be operational
pressures to do so.

The problem with (2) is that we make the DNS more complicated without
solving all or perhaps even most of the problems people really have.
The complication will be greater than many people seem to think: for
instance, the BNAME proposal as it is currently written is, as far as
we can tell, simply incompatible with all the deployed validators in
the world.  That seems like a problem that needs addressing, and we
can't see how to do so easily.

The problem with (3) is that it was suggested before, and got no
traction.  Moreover, it's very complicated, such that the work might
never complete; and in the meantime, people who have a problem have no
help.

We DNSEXT chairs are mostly convinced that there is no current
proposal that is any simpler than just duplicating zone apex data and
adding a DNAME to the "alias" zones.  This suggests an option 4:

    4.  Provisioning only: document how to do what's needed by
    provisioning, and explain why the WG is not doing anything else.

Before we propose another charter for the WG, we'd like to hear more
arguments why any work is needed, and which of the options 1-4 seem
like the best bet for that work.

Best regards,

Andrew and Olafur

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

---

From: Brian Dickson <[email-masked]>
Date: Tue, 10 Aug 2010 11:55:19 -0300

> experiment in the root, but we expect that there would be operational
I think it would be reasonable to allow experimentation, with the
restriction that changes
must be fully backward compatible for at least one "equivalent" name of any
set of equivalent names.

In other words, it can't break existing implementations for all instances of
a set of equivalent names,
where "break" is interpreted as widely as possible (such as "fails
validation as insecure or bogus, for signed zones").

NB - I am proposing something which won't break existing implementations,
and thus can be experimented with, even
at the root.

> can't see how to do so easily.
I think there is a need to address the sets of problems, and potential sets
of solutions, in the mathematical
sense of "spanning sets".

Only if the set of problems can be covered by the set of solutions, can (2)
proceed,
and all of the necessary solutions to meet that conditions must be fully
delivered.

This, unfortunately, may require a slight divergence from standard IETF
policy, in that in order
to meet this condition, there may be individual proposals which don't meet
the traditional
general consensus, which need to be "fostered" or "sponsored" by either the
chairs,
the area director(s), or the IAB, and for which "abandon" is not an
acceptable outcome.

They have to be treated as a set, all-or-nothing, not as individual
proposals.
Otherwise not all cases will be covered, and thus what portions do progress
are for naught.

>    provisioning, and explain why the WG is not doing anything else.
I'd like to add to 4, e.g. " (4.a.) Provisioning Enhancements: document
per-implementation improvements to support provisioning-only solutions,
which reduce or eliminate out-of-sync conditions for equivalent 'things'."
(By per-implementation, I mean describe in general/abstract terms, what each
implementation is encouraged to do, and _not_ describe in
implementation-specific detail what each known existing implementation
should change.)

> like the best bet for that work.
One underlying problem specific to DNSSEC RRSIG issues (where "equivalent"
things need to be signed by each of their "equivalent" parent zone owner
names), is the tying of "identity" of a zone to the "owner" name of the apex
data.

If we want to be able have "equivalent" things and not have an arithmetic
explosion of RRSIGs for those things, either the labeling needs to change,
or the manner of assigning an "identity" for "signer" purposes (and thus the
corresponding logic for validation) needs to change. (IMHO, the label
equivalence needs to be of the first-class type, where all labels are
created equal, to avoid increasing complexity and fragility.)

Mark Andrews has proposed a "multi-match label" (new label type).

My idea is to add a new RRset to the apex of the zone, which establishes the
complete set of names by which the zone is known (and thus equivalent
owners, and thus de-facto permitted signer names).

Note that as the RR type would not be one of the "special few", it would be
signed, just like any other RR.
And for ensuring the security and sanity (and to avoid circular logic in
signing), it (and it alone) would need to be signed by all the names
contained in it.
The additional validation logic is simple - if owner(zone) !=
signer(zone_entry) then {
check_for_signed_zone_equivalents(owner(zone),signer(zone_entry)) }

Other than that, the provisioning of zones (by copying) or linking of zones
(as an enhancement) should be sufficient for most, if not all, cases.

Note that the restriction of some kinds of equivalence only working for
zones, can be worked around by turning anything which would otherwise be a
non-apex entry in a zone, into a zone of its own. It is a clever and ugly
hack, which has the benefit of being 100% backwards compatible, and can be
experimented on today with no risk.

Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Aug 2010 13:55:21 -0400

I think the provisioning approach makes sense.

I do not see the justification for experimenting for issues that can
be handled through provisioning.

While I am currently working on a 'presentation' layer proposal to
combine DNSSEC, SSL and SRV and some other stuff to provide an
integrated discovery mechanism, I see getting a presentation mechanism
defined as being an essential prerequisite to getting an I18N
presentation layer to work.

In other words, we have to get a decent story together for how to
manage presentation-layer for the Web Services for google.com before
we go on to work out the presentation layer for the I18N variations
thereof.

-- 
Website: http://hallambaker.com/

---

From: John Levine <[email-masked]>
Date: 11 Aug 2010 04:18:53 -0000

>    provisioning, and explain why the WG is not doing anything else.

Yeah.

Anyone been following the progress of the recent ICANN IDN TLDs?
They're as good a live experiment in cloning trees via provisioning as
we're likely to find.

R's,
John

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 13 Aug 2010 11:14:56 +0200

> DNS.  Unfortunately, we were unable to attract many such participants.

Andrew,

I would like to point out that application developers are not the only 
target audience of the "sameness" problem.  From my (obvious) point of 
view I see that more close to the registry/registrar audience.  Like 
what Greeks are doing: https://grweb.ics.forth.gr/english/faq.html#f49
As I see it they would benefit greatly if they could insert xNAME (where 
x is C+D or B) which would alias owner of the xNAME as well.

Domain owners are the second audience which has some opinions on the 
"sameness" (mostly in form of IDN).  I hear many voices which either say 
"don't do IDN at all because you create mess" or they say "if you do 
IDN, do it as an aliases only".

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Alex Bligh <[email-masked]>
Date: Fri, 13 Aug 2010 10:33:45 +0100

Ondrej,

--On 13 August 2010 11:14:56 +0200 Ondřej Surý <[email-masked]> wrote:

> view I see that more close to the registry/registrar audience.  Like what
> Greeks are doing: https://grweb.ics.forth.gr/english/faq.html#f49

I agree that this is being driven partly (mostly?) by the registry/registrar
community. However, what I don't understand is that even if we come
up with a magic DNS aliasing solution so that Ai.Bj always gives
the same result as A1.B1, what is the use of it if it doesn't work
at the application layer too? number of users of web browsers and
email exceed number of users of dig by many orders of magnitude. I have
yet to find one application the "magic xNAME" proposal would work with
out the box.

-- 
Alex Bligh

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 13 Aug 2010 15:04:45 +0200

On 13.8.2010 11:33, Alex Bligh wrote:
>> I would like to point out that application developers are not the
>> only target audience of the "sameness" problem. From my (obvious)
>> point of view I see that more close to the registry/registrar
>> audience. Like what Greeks are doing:
>> https://grweb.ics.forth.gr/english/faq.html#f49 As I see it they
>> would benefit greatly if they could insert xNAME (where x is C+D
>> or B) which would alias owner of the xNAME as well.
>
> I agree that this is being driven partly (mostly?) by the
> registry/registrar community. However, what I don't understand is
> that even if we come up with a magic DNS aliasing solution so that
> Ai.Bj always gives the same result as A1.B1, what is the use of it
> if it doesn't work at the application layer too? number of users of
> web browsers and email exceed number of users of dig by many orders
> of magnitude.

> I have yet to find one application the "magic xNAME" proposal would
> work with out the box.

Why is it so important that it works out of the box?  The usage in R-R-R 
model doesn't include magnitude of domain names.  It just gives people 
an option to simplify the one place where they do most errors and which 
has those strange things which people don't understand like TTL.  From 
my viewpoint (of a person who worked for hosting company longer than for 
registry) the rest is up to the provisioning and it's very easy to do 
compared to provisioning of the DNS.

Ondřej

---

From: Alex Bligh <[email-masked]>
Date: Fri, 13 Aug 2010 14:26:56 +0100

--On 13 August 2010 15:04:45 +0200 Ondřej Surý <[email-masked]> wrote:

> model doesn't include magnitude of domain names.  It just gives people an
> option to simplify the one place where they do most errors and which has
> those strange things which people don't understand like TTL.  From my
> viewpoint (of a person who worked for hosting company longer than for

My suspicion is that it is all but impossible to solve at the
application layer, and that means there is little point causing
protocol entropy at the DNS layer. I'd quite like to be proved
wrong on this.

To give you an example of provisioning impossibility or impracticality
take www.Ai.Bj.Ck.Dl, where each of i,j,k,l are more than one (and
range from 1 to I,J,K,L). How do you provide an SSL certificate for
that? As far as I can see, the only current way is to have
I*J*K*L certificates, on I*J*K*L different IP addresses, which necessarily
means you CANNOT have mirroring between zones because you want a different
A record. Even if one of the various proposed solutions to the one-SSL-cert
per IP record problem was adopted, you would STILL need I*J*K*L SSL
certs as far as I can see. This problem exists at various different
magnitudes for http, smtp, sip, etc. etc.

I am not saying we should ignore this until the application layer is
fixed. I am saying the protocol entropy this induces means we shouldn't
progress this until we know the application layer is fixable at
least for common protocols (and as I say, I'd like my cynicism to be
proved wrong here). If there's one common protocol that requires
x.Ai.Bj.Ck.Dl has a different A record to x.A1.B1.C1.D1, then people
aren't going to use an xNAME type proposal because it will prevent
support of that protocol (and presumably they'll use a "dumb
provisioning hack" instead).

-- 
Alex Bligh

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 13 Aug 2010 16:04:43 +0200

> magnitudes for http, smtp, sip, etc. etc.

For HTTPS you either:

- don't use ssl for aliased domain names

- dont' use aliases for domains where you need SSL

- use SNI (Server Name Indication) the support is already there

- use this:
             X509v3 Subject Alternative Name:
                 DNS:www.sury.org, DNS:sury.org

SMTP, SIP, etc. have either requirement for using canonical name (SMTP) 
or they have SRV records (SIP).

Ondrej

---

From: Brian Dickson <[email-masked]>
Date: Fri, 13 Aug 2010 11:19:12 -0300

> magnitudes for http, smtp, sip, etc. etc.

I believe the one-SSL-per-IP is well-solved.

http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

(All current versions of all browsers support SNI, AFAIK.)

The Subject Alternative Name in SSL certificates allows a single cert to
function for all combinations.
Costs vary by SSL CA/reseller, of course.

Combine these together, and I think the problem, at least for HTTPS, is
solved.

Brian

---

From: Alex Bligh <[email-masked]>
Date: Fri, 13 Aug 2010 16:03:47 +0100

Ondrej,

> - don't use ssl for aliased domain names

Not really an option if the idea is to make aliasing work

> - dont' use aliases for domains where you need SSL

You can't avoid that if your registry uses aliasing, can you?

> - use SNI (Server Name Indication) the support is already there

Does SNI have widescale deployment support? I thought it still
required I*J*K*L different certificates (not that I am an https
guru by any means).

>                  DNS:www.sury.org, DNS:sury.org

Something like this is the only practical way to make all
aliases behave in an equivalent manner (which
was, as I understand it) the idea.

> SMTP, SIP, etc. have either requirement for using canonical name (SMTP) 
or > they have SRV records (SIP).

SIP with SRV is less of a problem.

HTTP (not S) still requires handling of the GET line, which will
have to be written according to equivalence rules which may only
be known to the registry (paf suggested this isn't an issue).

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Fri, 13 Aug 2010 15:40:27 +0000

> Date: Fri, 13 Aug 2010 10:33:45 +0100
> From: Alex Bligh <[email-masked]>
> 
> registry/registrar community. However, what I don't understand is that
> even if we come up with a magic DNS aliasing solution so that Ai.Bj
> always gives the same result as A1.B1, what is the use of it if it
> doesn't work at the application layer too? number of users of web
> browsers and email exceed number of users of dig by many orders of
> magnitude. I have yet to find one application the "magic xNAME" proposal
> would work with out the box.

there's no way to get total sameness without application changes.  consider
an application who looks for the A and AAAA for an MX target, and then
looks for PTR's for the resulting addresses, and insists that the one be
found within the other.  if the original name is Ai.Bj then there's not
enough state in DNS itself to ensure that the final name is also Ai.Bj,
it's going to be A1.B1.  this example is not contrived.  this yields a hard
choice:  add a constraint.  require that Ai.Bj be normalized to A1.B1
before it is used either for DNS lookups or any host identity (like SMTP
HELO).  this means we wouldn't have true "sameness" across the names
{A1.B1, Ai.Bj}, one would be a first class name, the other would be a
second class name.

both BNAME and SHADOW would create second class names in this sense, though
only BNAME uses CNAME or CNAME-like technology to do it.

the other hard choice would be to say, only new-style-alias-aware apps can
see them.  this is unthinkable due to the size of the installed base.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 13 Aug 2010 17:00:37 +0100

--On 13 August 2010 15:40:27 +0000 Paul Vixie <[email-masked]> wrote:

> there's no way to get total sameness without application changes.

I agree. So:
 1. we can't get total sameness without application changes
 2. many of those applications are going to require "manual
    provisioning hacks" which are dependent upon knowing how
    aliasing further up the tree works, which removes at least
    some of the benefits of xNAME

My question is:
  Do these together mean the advantage of xNAME over doing the
  "manual provisioning hack" for DNS as well as for the
  applications is outweighed by protocol entropy caused?

If the answer is "no, it is not outweighed", xNAME needs to be
a LOT better than manual provisioning (hence the criterion
of O(n) provisioning I suggested).

-- 
Alex Bligh

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 13 Aug 2010 13:06:29 -0400

> protocol entropy at the DNS layer. I'd quite like to be proved

I want to highlight that paragraph, because it is a concise version of
an objection we've heard a few times in this debate.

This WG is responsible for the DNS protocol, and we have to make a
trade-off: is the additional complexity we propose to add going to be
worth it?

The "worth it" question was the reason I was aiming at applications
area people in particular in Maastricht.  I agree that the pressure to
add these aliasing features is coming from the registry/registrar (and
other zone operators, if you make that distinction) community.  But as
keepers of the protocol, we need not just to respond to direct users
of the DNS but also to the question, "Will this be usable?  Is the
additional complexity going to benefit us overall?"  

Some are arguing (as Alex does nicely above) that the answer seems to
be no.  For my part, my answer is, "I don't know."  But speaking
personally, I am reluctant to make a change to any protocol in order
to get a benefit I have reason to doubt will be attainable.

A

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

---

From: Paul Vixie <[email-masked]>
Date: Fri, 13 Aug 2010 17:53:16 +0000

> Date: Fri, 13 Aug 2010 17:00:37 +0100

i don't think the changes needed in apps should be called "manual
provisioning hacks".  that would misconstrue them as "similar to
what ICANN is telling IDN TLD operators to do today" and they are
not (similar): both in what's being changed (software) and in who
is doing the changing (developers) and in the scalability (future
proofing vs. unending manual labour).

>  applications is outweighed by protocol entropy caused?

i think that question is nonsequitur, given the lack of similarity
between the thing IDN TLD operators do today, vs. what developers
of DNS apps would have to do.  (see above.)

> of O(n) provisioning I suggested).

paul

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Aug 2010 10:57:31 -0700

>to get a benefit I have reason to doubt will be attainable.

Another way to look at this is that, unless the users of the change we are going to make agree to it, don't do it. We didn't get any significant application area input[*] in Maastricht, even after asking for it, so we truly don't know. Given that, I propose we don't start working on any line of solutions that will be useless without effort from the users.

--Paul Hoffman

[*] I don't consider the app input from John Klensin and I to be enough to be considered "significant", particularly because we mostly discussed a previous effort that died due to lack of input.

---

From: Alex Bligh <[email-masked]>
Date: Sat, 14 Aug 2010 07:54:04 +0100

--On 13 August 2010 10:57:31 -0700 Paul Hoffman <[email-masked]> 
wrote:

> Another way to look at this is that, unless the users of the change we
> are going to make agree to it, don't do it.

I think it may be worse than that. If the end requirement is to make
Ai.Bj.Ck.Dl work like A1.B1.C1.D1, DNS equivalence may hinder this. How?
Well, take the example of an application like https. The intention is that
the end user typing the https://Ai.Bj.Ck.Dl into her browser gets the same
thing as typing https://A1.B1.C1.D1. It may be (due to incomplete
deployment of SNI, e.g. support of IE prior to 7.0) that the only effective
way to do this is multiple IP addresses. Having a mirror will PREVENT that.
Moreover if the server admin doesn't want to buy I*J*K*L certs, the end
user will be presented with an invalid security cert rather than a simple
'not found'.

https is just one example of why one might want an exception from
equivalence. But so for no xNAME proposal allows for this. A provisioning
hack does.

So, if there are existing apps where DNS equivalence is problematic, xNAME
may do more harm than good because it /breaks/ the application layer.
Here, to make Ai.Bj.Ck.Dl work like A1.B1.C1.D1, you need DIFFERENT
DNS reponses, which xNAME PREVENTS.

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Sat, 14 Aug 2010 14:06:53 +0000

> Date: Sat, 14 Aug 2010 07:54:04 +0100
> ...
> So, if there are existing apps where DNS equivalence is problematic,
> xNAME may do more harm than good because it /breaks/ the application
> layer.  Here, to make Ai.Bj.Ck.Dl work like A1.B1.C1.D1, you need
> DIFFERENT DNS reponses, which xNAME PREVENTS.

wouldn't you just not put in xNAME RR's on the names which needed
different dns responses?  or if you mean that you want difference
for some apps and sameness for other apps, how would a provisioning
hack support that?

---

From: Alex Bligh <[email-masked]>
Date: Sat, 14 Aug 2010 16:31:33 +0100

> for some apps and sameness for other apps, how would a provisioning

An example will probably help.

Let us suppose ICANN delegate z1. and z2. to the combined republic
of Z-land, and want "names ending z1. and z2. to work the same".
In an attempt to achieve this, they use the recent output of
the DNSEXT working group to provide zone equivalence, and put
the following in the root zone file:

	$ORIGIN .
	z1.	IN 	NS 	ns.znic.net.
	z2.	IN	XNANE	z1.

znic is the registry for z1. (and hence z2.). It doesn't
really matter whether the XNAME record lives in the root
zone or whether znic has it at the apex of a z2. zone file
for this region.

One registrant within z1. is hugecorp, so z1's zonefile
contains this:
	$ORIGIN z1.
	hugecorp	IN	NS	ns.example.com.

And within hugecorp, there is a regional entity:
	$ORIGIN hugecorp.z1.
	region		IN	NS	ns.example2.com.

And the regional entity has a web server
	$ORIGIN region.hugecorp.z1.
	www		IN	A	192.200.0.1

The web server operator wants his webserver to respond to both
http://www.region.hugecorp.z1/ and http://www.region.hugecorp.z2/,
and the XNAME neatly facilitates this, as both lookups produce
192.200.0.1.

However, a problem comes when the operator tries to get HTTPS
working. The operator's webserver runs IIS, which neither
support SNI nor X509v3-SAN. Whilst he could change the web
server software, lots of his users run old versions of
IE, or use any versions of IE or Chrome on Windows XP, or
use Blackberries, none of which support SNI or X509v3-SAN
either. So if he puts up an https service on /either/
address, the other will give a certificate error, which
is unhelpful as hugecorp is a bank.

If, however, the XNAME hack had not been used, the following would
be in the zone files.
	$ORIGIN .
	z1.	IN 	NS 	ns.znic.net.
	z2.	IN 	NS 	ns.znic.net.

	$ORIGIN z1.
	hugecorp	IN	NS	ns.example.com.
	$ORIGIN z2.
	hugecorp	IN	NS	ns.example.com.

	$ORIGIN hugecorp.z1.
	region		IN	NS	ns.example2.com.
	$ORIGIN hugecorp.z2.
	region		IN	NS	ns.example2.com.

	$ORIGIN region.hugecorp.z1.
	www		IN	A	192.200.0.1
	$ORIGIN region.hugecorp.z2.
	www		IN	A	192.200.0.2

The administrator of the web server, who understands his application's
needs, puts www.region.hugecorp.z1. on a different IP address
from www.region.hugecorp.z2., and, whilst begrudging the fact
he now has to pay for 2 certificates, at least has 2 working
http addreses. Or alternatively (per paf) just makes one of
them work, but at least the other doesn't produce an error.
Neither of these options is possible if equivalence is forced on
him higher up the chain. Forcing DNS to return equivalent records
actually caused the application to perform DIFFERENTLY. Manual
provisioning in this instance makes things BETTER.

Also, no one needed to do any protocol design, worry about signalling,
upgrade any nameservers or caching resolvers. It all worked out the box.

-- 
Alex Bligh

---

From: Brian Dickson <[email-masked]>
Date: Sat, 14 Aug 2010 12:42:56 -0300

> way to do this is multiple IP addresses. Having a mirror will PREVENT that.

I would have to say that's an oversimplification, and not a unique
conclusion.

While it is always possible to type https:// into a browser, the vast
majority of
real-world use cases involves http:// which then, based either on general
design
or user interaction, results in the browser being sent to https://something.

Two general mechanisms exist for support for the SNI issue -- one is to
redirect
the user to the https://A1.B1.C1.D1 site, the other is to present a "minimum
browser"
supported link. There are plenty of older browsers which web sites won't
support,
or requirements that browsers must meet (number of bits for SSL support, for
instance.)

> user will be presented with an invalid security cert rather than a simple
The  issue of multiple certs was addressed elsewhere - SAN (subject
alterntive name)
certs handle this, i.e. only one cert is needed. Those can be used
regardless of the
single IP address or the many IP addresses. Orthogonal to the issue at hand.

Brian

P.S. Reminder - I'm in favor of provisioning hacks and/or meta-provisioning
hacks.

---

From: "Yao Jiankang" <[email-masked]>
Date: Sun, 15 Aug 2010 10:04:34 +0800

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "Paul Vixie" <[email-masked]>; <[email-masked]>
Cc: "Alex Bligh" <[email-masked]>
Sent: Saturday, August 14, 2010 11:31 PM
Subject: Re: [dnsext] The succinct version of the argument for "do nothing" (was: [dnsext] DNSEXT charter and treating DNS names as "the same") 

> actually caused the application to perform DIFFERENTLY. 
>

maybe not, it depends on how you configure it.

>Manual

some zone has the millions of names, these names have the millions childerens.

provisioning for a few name are easy,  but how about millions?

---

From: John Levine <[email-masked]>
Date: 15 Aug 2010 03:00:14 -0000

>provisioning for a few name are easy,  but how about millions?

Don't you build your zone files with databases and automatic scripts?

R's,
John

---

From: Alex Bligh <[email-masked]>
Date: Sun, 15 Aug 2010 08:05:06 +0100

--On 15 August 2010 10:04:34 +0800 Yao Jiankang <[email-masked]> wrote:

> Forcing DNS to return equivalent records

Some applications appear not to be configurable (see examples
given).

The point is that if it breaks a few, manual provisioning would
have been better.

> provisioning for a few name are easy,  but how about millions?

You are manually provisioning the applications anyway.

As for creating the zone, is there a reason a tool like
perl won't work for this (creating z2. from the zonefile
for z1.)?

Moreover, I am sure there would be an opportunity for server
vendors to say "make this zone respond like that zone
with the following exceptions" (though that would be
harder with signed zones).

-- 
Alex Bligh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 15 Aug 2010 17:45:21 -0400

There are ways to fix this up in the certificates.

But there is no way to have a secure scheme where a person types in
x.y.z and there is no mention of x, y and z in the cert.

So there is no way you can make this work by putting magic links into
the apex zone. Not unless you can establish a trust chain for the
equivalence statement that has the same degree of assurance
(validation, insurance, etc.) as the chain it is mapped to. And ICANN
is certainly not proposing to do that with their DNSSEC proposal.

 So if you take magic links off the table, you have provisioning hacks
and 'Did You Mean' links or both as possible mechanisms.

---

From: Danny Mayer <[email-masked]>
Date: Sat, 21 Aug 2010 09:50:06 -0400

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

> {A1.B1, Ai.Bj}, one would be a first class name, the other would be a

Why is SMTP a problem? You can always set up the MX records for aliased
zones to point to just one FQDN and have the PTR record point back to
the same FQDN. Or am I looking at it from the wrong end?

Danny

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 23 Aug 2010 14:13:37 +0200

> the same FQDN. Or am I looking at it from the wrong end?

Because in reality you do not have A1.B1 and A2.B2. You might have instead, for example:

AnBnCnDn.EnFnGnHn where you have n=1,..,n=4 and a delegation at the period.

So in reality you might in this example talk about more than two permutations (although of course not all values and combinations of n=1,..,n=4 makes any sense).

   Patrik

---

From: Danny Mayer <[email-masked]>
Date: Mon, 23 Aug 2010 15:41:45 -0400

> So in reality you might in this example talk about more than two permutations (although of course not all values and combinations of n=1,..,n=4 makes any sense).

But the MX record can point to just one FQDN, no matter what the domain
name you choose to use. The target of the MX does not need to have all
of the variations of the domain name. The SMTP server just needs to be
able to accept all of the possible domains that point to it and that is
an SMTP problem and not a DNS problem.

Danny

---

From: Alex Bligh <[email-masked]>
Date: Mon, 23 Aug 2010 21:07:03 +0100

> an SMTP problem and not a DNS problem.

How does the MX server know whether the domain is local (i.e. whether
it should accept mail for it) and if so which local domain it is
equivalent to, without manual configuration?

-- 
Alex Bligh

---

From: Danny Mayer <[email-masked]>
Date: Mon, 23 Aug 2010 17:00:54 -0400

> equivalent to, without manual configuration?

The same way that you configure any SMTP server. It has to know what it
will accept. There's no magic involved. The mail servers that I've
configured always expect me to tell it. Besides that's out of scope for
this WG.

Danny

---

From: Alex Bligh <[email-masked]>
Date: Mon, 23 Aug 2010 22:38:32 +0100

> configured always expect me to tell it. Besides that's out of scope for

I thought this was a reply to John Levine's thread on predictive vs.
reactive name aliasing. He was in essence making the point reactive
name aliasing doesn't work. That means you have to be able to configure
names in advance. Firstly, there may be a large number combinatorially.
Secondly, the available aliases may change over time and the rules
may not be immediately apparent to the mail system owner (e.g. TLDs
changing their rules). Thirdly, if the application layer needs to
be preconfigured, that makes automatic XNAME stuff less useful. I don't
see the point in doing a lot of work at the DNS layer without
considering the problems it generates at the application layer.
Is asking whether work is actually useful or counterproductive to
the application layer really out of scope?

-- 
Alex Bligh

---

From: Danny Mayer <[email-masked]>
Date: Thu, 26 Aug 2010 22:51:34 -0400

> the application layer really out of scope?

This sounds like you are suggesting that if a mail server is set up for
domain X and it has a shadow zone or a xDNAME copy to a Y domain then it
should automatically be able to configure itself based on the DNS
records with both X *and* Y. That requires enumerating all of the
"equivalent" domains which would argue more in favor of something like
Paul's shadow zone proposal since those records would have to exist in
the zone.

Danny

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Aug 2010 11:33:26 -0400

Exactly, and this is precisely the reason that I do not consider magic
pointer approaches to have any value. It is impossible to make
existing applications work without them being aware that the names
they are using are being aliased.

So if there is magic fixup in the core of the DNS it will break legacy
application servers for sure.

Proposals that only work after every server in the world has upgraded
almost always fail. In this case I think that there is a negligible
chance that any work done here is going to have the industry support
needed to achieve deployment because I do not believe it is possible
to arrive at an implementable statement of what new servers should do.

The reason for rejecting client side fixup appeared to be that
deployment would take too long.

What I would expect to happen with magic fixup is that once
implemented it would break servers in random and unexpected ways.
While some people think this would be a driver for deployment, I think
it rather more likely that people would simply start filtering out the
magic fixup pointers from their recursive DNS.

This will lead ISPs to block these records and redirect the user to a
landing page from where they can attempt to access the site. We can
all see where that leads.

If a provisioning or client side fixup is too slow for people a fixup
that breaks noncompliant servers is going to be worse.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 27 Aug 2010 16:49:22 +0000

> Date: Thu, 26 Aug 2010 22:51:34 -0400
> From: Danny Mayer <[email-masked]>
> 
> should automatically be able to configure itself based on the DNS records
> with both X *and* Y. That requires enumerating all of the "equivalent"
> domains which would argue more in favor of something like Paul's shadow
> zone proposal since those records would have to exist in the zone.

and indeed, the need for an API function like this informed the SHADOW design.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 27 Aug 2010 17:58:38 +0100

> Paul's shadow zone proposal since those records would have to exist in

I think shadow is worth investigating further. I'm not yet convinced
that the best answer isn't "do nothing", though.

-- 
Alex Bligh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 28 Aug 2010 12:49:56 -0400

There are three choices:

1) Attempt to meet a set of requirements that appear to be inconsistent
2) Meet a reduced set of requirements we know that we can meet but
fall short of the need
3) Do nothing

I proposed the Did You Mean (DYM) record because that is a lower bound
for what we might achieve. We can definitely describe and implement a
DYM record and make it work. It does not meet the full set of
requirements that people think that they want but I don't consider
them to be satisfiable.

The Internet is very large and very complex. It is not possible to
make major changes to the core infrastructure and have them work
overnight. It takes a minimum of about ten years for certain types of
changes to work through.

We seem to end up with a situation where the people who are realistic
about deployment constraints get shoved aside by the people who insist
that change must come faster. So instead we end up with proposals from
people who think that wishes are ponies and RFCs are deployments. And
ten or so years later we are still at the starting line.

---

From: Danny Mayer <[email-masked]>
Date: Sat, 28 Aug 2010 15:16:11 -0400

> that the best answer isn't "do nothing", though.

+1

---

From: "Jiankang YAO" <[email-masked]>
Date: Mon, 30 Aug 2010 10:30:04 +0800

----- Original Message ----- 
From: "Phillip Hallam-Baker" <[email-masked]>
To: "Alex Bligh" <[email-masked]>
Cc: <[email-masked]>; "Patrik Fältström" <[email-masked]>; "Paul Vixie" <[email-masked]>; <[email-masked]>
Sent: Sunday, August 29, 2010 12:49 AM
Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same"

> overnight. It takes a minimum of about ten years for certain types of

if we choose to use xName, I think that xName is not a kind of internet major changes.
for example, although the BNAME proposes a new RRTYPE, only the servers which want to use it need to update the servers.
the current non-dnssec resolvers do not need to be updated. the dnssec-resolvers need to be updated, but the dnssec is just starting to deploy.
so if we can come out the solution soon, the bname can get the deployment with the dnssec. it means that we do not need ten years.

if we think that adding the new RRTYPE such as BNAME is a major internet change, there would have had too many major internet changes during these days.

if we really care for the major internet changes, do we notice that there is a real internet major change. 
 the dns root has the IDN TLDs and there will have thousands of IDN TLDs in the future. The number of IDN TLDs will be larger than the ASCII IDN TLDs in the future.

Most IDN protocols appeared before the IDN TLDs or IDNs come to the world.
if we call the current DNS protocols as the "ASCII oriented DNS protocols", do we need do something for the IDN DNS?
there are more than 3 billion of IDN users in the world. 
in 2007 ietf meeting, one IAB plenary is about the IDN and internationalized ietf protocols. I think that IAB has noticed it and most IETF protocols will deal with some internationalized issues.

I think that if  we can do something benefit to the 3 billions of internet users, it is worth to do it even if that is "the major inernet changes you called".

Jiankang Yao

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 30 Aug 2010 01:07:32 -0400

The issue is not the cost of the changes, it will be the amount of
infrastructure that will have to have changed before the changes may
be used successfully.

The problem is not the DNS infrastructure, it is the fact that Web
servers will not know what to do with the connection attempts unless
we require changes in administration to be made that render the need
for a new DNS record superfluous.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 30 Aug 2010 10:44:34 +0200

On Mon, Aug 30, 2010 at 10:30:04AM +0800,
 Jiankang YAO <[email-masked]> wrote 
 a message of 70 lines which said:

>  the dns root has the IDN TLDs and there will have thousands of IDN
>  TLDs in the future. The number of IDN TLDs will be larger than the
>  ASCII IDN TLDs in the future.

I don't see the point. I'm a big fan of IDN, I agree that we will have
one day more IDN TLDs than ASCII TLD but so what? What's the
connection with the whole discussion about "synchronous domains" and
the possible solutions (xNAME, SHADOW, etc)?

Unless you claim that *every* IDN TLD require synchronization of
content (something that not everyone will agree with) *and* that this
synchronization requires a non-provisioning method to be done,
something that you often repeat but which is not true.

Please provide hard facts, not just hand-waving about IDN. We can
deploy IDN (actually, it is already done) without xNAME. 

Domain synchronization is not an IDN issue. (I would like to have
bortzmeyer.fr and bortzmeyer.org synchronized, even if they are ASCII
names.)

---

From: "Jiankang YAO" <[email-masked]>
Date: Mon, 30 Aug 2010 17:20:57 +0800

----- Original Message ----- 
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 30, 2010 4:44 PM
Subject: [dnsext] Re: DNSEXT charter and treating DNS names as "the same"

> the possible solutions (xNAME, SHADOW, etc)?

IDN TLDs or some second levels IDN domain names may need the solution.

for example, greece, chinese, arabic, india character.

there is a character variant group in ICANN, which focus on discussion of the variant characters from different languages.

> something that you often repeat but which is not true.

I can not prove that every IDN TLD need it.
but some IDN TLD and second level IDN domain names need it.

the users of that kind of  IDN TLD or second level IDN domain names is not millions, but billions.

I think that DNS is not only for ASCII based characters, but also IDN.

> deploy IDN (actually, it is already done) without xNAME. 

we can use some idns now, but we should make them work better.

>
> 
> Domain synchronization is not an IDN issue.
>

Domain synchronization is from the  IDN issue, may be resolved in the DNS.

> (I would like to have

this is a kind of domain names we should make it synchronized.

---

From: "Jiankang YAO" <[email-masked]>
Date: Mon, 30 Aug 2010 17:31:35 +0800

----- Original Message ----- 
From: "Phillip Hallam-Baker" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: "Alex Bligh" <[email-masked]>; <[email-masked]>; "Patrik Fältström" <[email-masked]>; "Paul Vixie" <[email-masked]>; <[email-masked]>
Sent: Monday, August 30, 2010 1:07 PM
Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same"

>The issue is not the cost of the changes, 
>

hope so.

>it will be the amount of

I don't think that it is necessary.
if  you want to use the  alias1.com and alias.com, the domain administrator  must  regist them first (the domain administrator knows how many alias domain names registered, you may see rfc3743 too) and then put them to the dns.
so the administrator know these alias domain names and will configure them properly.

this configureation is similar to the current practise of configuration of google.com and google.uk pointing to the same address.

>for a new DNS record superfluous.

pls see the example above.

Jiankang Yao

---

From: Alex Bligh <[email-masked]>
Date: Mon, 30 Aug 2010 10:45:44 +0100

> but some IDN TLD and second level IDN domain names need it.

*Why* do these TLDs need XNAME as opposed to the provisioning method?

Let us assume the provisioning method means synchronized entries move
together between registrants etc. The only thing XNAME gives you beyond the
provisioning method AFAICS is ensuring the tree below the delegation point
is also synchronized, which is (in some circumstances) disadvantageous in
making the applications perform similarly (as demonstrated several times).
So what is the /advantage/ of XNAME over provisioning, given its trivial
to demonstrate provisioning is capable of doing the same thing and is
more flexible when 'the same thing' is sometimes wrong?

-- 
Alex Bligh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 30 Aug 2010 12:01:24 -0400

The only reason I can see to reject the provisioning method is that
the provisioning may not work across zones of authority.

So for example, let us imagine that I want to synchronize
hallambaker.com with hallambaker.co.uk. If I registered the .co.uk
version I would be able to program my DNS configurator to create the
same records in each domain.

The same infrastructure tells my Web server to map
www.hallambaker.co.uk to www.hallambaker.com through an internal
redirect.

I get precisely the effect desired with no need to change any of the
DNS infrastructure. The only (minor) downside being that this may not
work identically if I decide to make radical changes to my DN
configuration and end up with records that are out of sync. But this
is not really a major difference to what happens with a single zone,
cutovers take time to propagate, that is the way the Web is.

Now imagine that .co.uk decide that they want to synchronize *.co.uk
and *.co.gb.

So now I start to see traffic from www.hallam.co.gb. My Web server has
no idea that this should be redirected to hallam.com and no way to
find out.

The only way that I can see to make an XNAME type scheme work would be
as follows:

1) CANONICALIZE

I don't care if you want the two trees to be peers. That type of
system simply does not work reliably in my view. If you want multiple
naming to work then you have to pick one set of names that is
canonical and map all the equivalents to those forms.

If you can't pick one set of names then do like they are doing with
IPv9 and map everything to numbers which is probably where IDNs will
end up in any case because there isn't a single keyboard on the planet
that can type every UNICODE code point direct without the user
learning a coding scheme and there never will be (I don't think
handwriting recognition is likely to work much better either). On the
other hand, every telephone handset in the world has decimal Arabic
numerals and can call every other telephone handset in the world.

2) ZNAME pointer to describe the forward reference.

This contains the following fields

* Canonical domain
* Alias link

The canonical domain has a ZNAME link pointing to itself and the first
alias in the list. The first alias points to the second and so on.

co.uk   ZNAME co.uk co.gb
co.gb   ZNAME co.uk co.unitedkingdom
co.unitedkingdom ZNAME co.uk co.uk

This is the bare minimum of information required to make the scheme
work. And it is somewhat flawed since we would ideally want to have
all these records signed using the .co.uk ZSK and this is not
something that DNSSEC really supports/enforces.

Better would be the following

co.uk                                                ZPTR co.gb
co.gb._ZNAME.co.uk                      ZPTR co.unitedkingdom
co.unitedkingdom._ZNAME.co.uk   ZPTR

co.gb   ZNAME co.uk
co.unitedkingdom ZNAME co.uk

OK so we have removed all arbitrary limits from the scheme, what does
that buy us over the DYM record which is an advisory pointer as
follows:

co.gb   DYM co.uk
co.unitedkingdom DYM co.uk

The only difference between ZNAME and DYM is that with DYM there are
no processing rules defined in the DNS system.

So processing for ZNAME would be:

Client looks up www.hallambaker.co.uk, gets A record returned for
www.hallambaker.com.
All clients automatically support ZNAME because the processing rules
are in the DNS system

If their DNS resolver supports ZNAME - user gets to see site.
Otherwise - user gets 'site not found' page from web client

If Server supports ZNAME lookup - user gets to see site.
If Server does not support ZNAME - user gets 'site not found' page
from web server

Processing for DYM on the other hand would be

Client looks up www.hallambaker.co.uk, gets A record returned for
www.hallambaker.com.

If client supports DYM - user gets directed to the right site
Otherwise user does not get directed to the right site.

No other part of the infrastructure needs to provide support.

The dependence on the resolver is particularly difficult from a user
experience perspective. Changing their means of accessing the net will
cause sites that were reachable to suddenly become unreachable for
unknown reasons.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 30 Aug 2010 16:10:15 +0000

> Date: Mon, 30 Aug 2010 10:44:34 +0200
> From: Stephane Bortzmeyer <[email-masked]>
> ...
> Unless you claim that *every* IDN TLD require synchronization of content
> (something that not everyone will agree with) *and* that this
> synchronization requires a non-provisioning method to be done, something
> that you often repeat but which is not true.

ICANN's regulatory regime (such as it is) makes adding "new tld's" difficult.
it is very hard to create a new IDN TLD which isn't synchronized to a current
one since this would run afoul of competitive issues ("why does CNNIC get so
many TLD's and my national name registry get so few?") and also commercial
issues ("you're calling that an IDN TLD but it is basically another .COM for
a specific language and has no relation to any ISO3166 TLD's namespace.")

it is comparatively much easier for ICANN to create synchronized IDN TLD's
since they are just new windows into an existing namespace.  provisioning
hacks are not a strong enough guaranty that synchronization will occur --
ICANN is doing it now just to get things started but they will not do it for
the many hundreds/thousands of IDN TLD's yet to come.

if everybody here could expand their horizons a bit, stop looking at this as
a simple engineering problem where the simplest/cheapest solution is usually
the right one, then we'd stop seeing the repeated refuge of "just use a
provisioning hack and stop asking for a protocol change".  that will not work
since the problem statement is in ICANN's regulatory regime not in the DNS.

ICANN has been uncharacteristically clear about this, and yao has explained
it several times, and i've explained it at least once.  no provisioning hack
of any kind will answer ICANN's problem statement.  please stop proposing it.

> deploy IDN (actually, it is already done) without xNAME. 

done.  (again.)

> bortzmeyer.fr and bortzmeyer.org synchronized, even if they are ASCII

sounds as if you'd appreciate SHADOW then.  but, IDN TLD's have regulatory
issues that your personal domain does not have, so, the situations are not
similar.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 30 Aug 2010 20:19:18 +0100

--On 30 August 2010 16:10:15 +0000 Paul Vixie <[email-masked]> wrote:

> if everybody here could expand their horizons a bit, stop looking at this
> as a simple engineering problem where the simplest/cheapest solution is
> usually the right one, then we'd stop seeing the repeated refuge of "just
> use a provisioning hack and stop asking for a protocol change".  that
> will not work since the problem statement is in ICANN's regulatory regime
> not in the DNS.
>
> ICANN has been uncharacteristically clear about this, and yao has
> explained it several times, and i've explained it at least once.  no
> provisioning hack of any kind will answer ICANN's problem statement.
> please stop proposing it.

I am not saying it's necessarily the case here, but...

In the hypothetical situation where ICANN or anyone else for that matter
were to propose solving a political problem with an unpleasant technical
hack which cause adverse side effects, and possibly without fully thinking
through the problems space, I believe a valid potential response from the
working group concerned is "we think this is a bad idea and we are not
going to to support it".

Or, is what you are saying, that if ICANN proposes a technical solution
for a political problem, and says jump, we should merely ask how high?

To the specific point:

>  provisioning
> hacks are not a strong enough guaranty that synchronization will occur

>From a technical point of view, I am far from convinced that synchronization
is a good thing, whatever ICANN thinks. If it is, what ICANN gives, ICANN
can take away, and thus a contractual solution is perfectly possible. If
this (strong guarantee of synchorization) is the only reason to do this,
I would say "don't do it".

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Mon, 30 Aug 2010 20:23:01 +0000

> Date: Mon, 30 Aug 2010 20:19:18 +0100

neither.  i'm saying that the DNS is not just a technological device, it
is also extant as an economic and political device.  the root and its TLDs
have always been handled differently than private domains.  we've already
pulled DNSSEC off the rails once for TLD's (see 5155) and once for the root
(see RFC 5011) so i'm just not ready to hear that we won't take real world
needs into account when doing our engineering.

in fact an engineer who doesn't take real world needs into account cannot
succeed.  (see <http://oreilly.com/catalog/opensources/book/vixie.html>.)

> To the specific point:
> 
> > provisioning hacks are not a strong enough guaranty that
> > synchronization will occur
> 
> From a technical point of view, I am far from convinced that
> synchronization is a good thing, whatever ICANN thinks.

ICANN (speaking of the community, not the staff) is a hive mind and you can
not usefully ask what it thinks.  i'm describing its (reality) constraints.

> If it is, what ICANN gives, ICANN can take away, and thus a contractual
> solution is perfectly possible.

that's a pure engineering mindset speaking, and i strongly suggest otherwise.

> If this (strong guarantee of synchorization) is the only reason to do
> this, I would say "don't do it".

it's not the only reason.  and when i proposed SHADOW i had other uses in
mind, such as the symmetry i'd like to have in the namespaces at VIX.COM,
VIXIE.ORG, VIXIE.SF.CA.US, and maybe others i'm forgetting here.  the only
difference is, for me personally, provisioning hacks can also be used.  but
ICANN is not the only entity for whom that's not true.  any larger and more
complex domain holder could want to do multivendor in a way that would make
the "provisioning hacks" approach really expensive (in TCO terms.)

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Aug 2010 15:01:56 -0700

>not usefully ask what it thinks.  i'm describing its (reality) constraints.

It doesn't feel that way. It feels like you are describing the constraints that some parts of that hive feels, but certainly not all. If it was all parts, then ICANN would not now be putting into the root TLDs that "require" synchronization. That synchronization is not happening, which proves that the requirement is mislabeled. (Corrections from ICANN staff are welcomed here.)

>any larger and more

Of course. All the proposed solutions are "really expensive (in TCO terms)"; otherwise, we would have already probably picked the one that was clearly the least expensive. Instead, what we have discovered is that the costs for the different solutions are orthogonal and thus nearly impossible to compare.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Aug 2010 18:42:51 -0400

> of any kind will answer ICANN's problem statement.  please stop proposing it.

Where exactly is ICANN's problem statement?  As one of the chairs who
needs to agree to herd this work through the IETF, I'd like to see it.

The only actual evidence we have from ICANN is that they _can_ do what
they thought the synchronization stuff would achieve with
provisioning, because in fact they already have.

A

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

---

From: Alex Bligh <[email-masked]>
Date: Mon, 30 Aug 2010 23:45:36 +0100

--On 30 August 2010 20:23:01 +0000 Paul Vixie <[email-masked]> wrote:

> ICANN (speaking of the community, not the staff) is a hive mind and you
> can not usefully ask what it thinks.  i'm describing its (reality)
> constraints.

I don't think it is true that we cannot ask what it thinks. I think,
for instance, we can enquire (*) as to the purpose of synchronization,
especially where the proposal is arguably unhelpful to at least one
possible rationale for synchronization (application layer consistency).

(*) and if we receive no useful answer, do nothing.

-- 
Alex Bligh

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Aug 2010 18:46:39 -0400

> there is a character variant group in ICANN, which focus on discussion of the variant characters from different languages.

Good.  I would like for them to explain what problems they think they
have, and why they think those problems can be solved by changes to
the DNS.  I would like those explanations to take the form of textual
contributions to the WG for inclusion in some requirements statement.
We've already held two major sessions on this topic at IETF meetings,
and with limited (but important) exceptions we've had not too much
input from ICANN character variant group participants.

A

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

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 30 Aug 2010 18:59:12 -0400

On 8/30/10 12:10 PM, Paul Vixie wrote:
>> From: Stephane Bortzmeyer<[email-masked]>
>> ...

True, but it is self-inflicted difficulty.

The authors of the policy to add new gTLDs in 2000, in 2004, and in 
2008, did not constrain ICANN's choices from incremental, policy-based 
changes. ICANN Staff have chosen to implement the policy so as not to 
have incremental, policy-based changes, in the present, and thus far 
ICANN's Board have not chosen to have incremental, policy-based 
changes after the 2004 round.

Further, the initial authors of the IDN for ccTLDs policy, did not 
constrain the policy to one script per ccTLD, or the consequence of 
the UTC's Han Unification of referring to SC and TC as a single 
script. On just such crap serious problems follow.

> a specific language and has no relation to any ISO3166 TLD's namespace.")

Why CNNIC gets so many TLDs and some other applicant from a state that 
uses a script other than Han gets fewer is _not_ a "competitive 
issue". It is a management-of-difference issue.

I'm not aware of an application for an IDN TLD that is "basically 
another .COM" within the ccTLD IDN FastTrack. There is at least one 
such pending application, but it won't be made as an application for a 
ccTLD, and it exists in a policy framework in which a vendor is known 
to seek a priority claim to labels "like" .COM in several languages.

> the many hundreds/thousands of IDN TLD's yet to come.

This really assumes things not in evidence. The SC/TC issue is real, 
and it has been since ... before the CDNC/JET people were unable to 
get the intermediate table fix into IDNA2003. But the necessity for 
some form of provisioning-or-stronger mechanism is not generalized for 
other scripts where the density of variant-capable slots in a string 
is vastly less than 1.0.

> since the problem statement is in ICANN's regulatory regime not in the DNS.

I've never looked at this as a simple engineering problem. I was asked 
my advice in July 2001, I gave it. In November 2001 it became possible 
to resolve Chinese domain names correctly, at least where it mattered.

> ICANN has been uncharacteristically clear about this,

We must be sitting in different sections of the church.

At Brussels I listened to Chris Despain attempt to make a requirements 
statement. He wasn't able to. The next day I listened to <someone on 
this list> speak very loudly from the open mic at the poor guys 
(Arabic Script and Han Script ccTLD IDN FT implementers) sharing the 
stage with the non-policy-making ICANN IDN staffer at the lack of a 
clear requirements statement. He made the point to these poor honest 
implementers and the non-policy-making ICANN IDN staffer that a 
requirements statement was required.

>                                                          and yao has explained

This could be true, if there was an ICANN problem statement.

>> deploy IDN (actually, it is already done) without xNAME.

To repeat what I said after the very tall and very loud fellow ...

to the Han Script implementors -- "is it the case that most labels are 
five Han characters or less?"

to the Arabic Script implementors -- "is it the case that 'variant' 
characters are 'sparce' in the label space, and occur primarily at 
label boundaries?"

A "yes" answer to both questions, which is what was given by the 
implementers, leads to the conclusion that the SC/TC problem is very 
unlike the Arabic Script problem, the first being dense in the string 
space of labels, the latter being sparse in the string space of 
labels, and therefore we have a technical basis for distinguishing 
these two 'variant' cases from each other.

Further, the five-or-less property means that the "combinatorial 
explosion" has a sharp knee between 4 and 6 and a very small tail. 
With registry policy capable of restricting equivalence sets to five 
or fewer characters, "bundle" size remains feasible, hence 
provisioning remains feasible.

I want to re-iterate my admiration for the approach the CDNC members 
took in 2001, in considering cross-registration of equivalences within 
the four independently operated name spaces to achieve end user 
perception of correctness.

> issues that your personal domain does not have, so, the situations are not

As I pointed out early in this discourse, and you made the same point, 
arbitrary equivalence has use cases, and it is over-specification to 
think of equivalence as being at the same level, or with the same 
(assumed) administrative model.

It is true that _some_ IDN TLDs have issues (and I avoid the word 
"regulatory" because ICANN is a 501(c)(3), which enters into contracts 
for registry and registrar functions, as well as other relationships 
for registry functions, where the registry is associated with an 
iso3166-1 code point allocation.

But not all IDN TLDs.

I will submit an application for a gTLD with an Arabic Script string 
as the string to be delegated into the IANA root. No "regulatory" 
issues attach to any such application, or to the operation of a 
registry subsequent to delegation, only contractual issues. The same 
will be true for my application for a gTLD with a Han Script string, 
and my application for a gTLD with a Cyrillic Script string, and for 
anyone else's applications.

Eric

* The rhetorical "I", though it could actually be the literal me.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 30 Aug 2010 23:38:26 +0000

> Date: Mon, 30 Aug 2010 23:45:36 +0100
> I don't think it is true that we cannot ask what it thinks.

i didn't say you couldn't ask.  i said you couldn't usefully ask.

> I think, for instance, we can enquire (*) as to the purpose of
> synchronization, especially where the proposal is arguably unhelpful to
> at least one possible rationale for synchronization (application layer
> consistency).

to the extent that some solution will not serve existing applications at
all, then it won't matter whether it also helps ICANN fit its constraints,
since ICANN would not be able to "sell" (politically speaking) a solution
like that to its stakeholders.

i think ICANN has been pretty clear about why it wants this stuff.  i'm not
saying anything newsworthy in this thread.

> (*) and if we receive no useful answer, do nothing.

that would be bad engineering.  not all questions have useful answers.  it
is not our job here to judge the worthiness of ICANN's constraints.  let's
please not go down this avenue in any form.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Aug 2010 17:04:10 -0700

At 11:38 PM +0000 8/30/10, Paul Vixie wrote:
>i think ICANN has been pretty clear about why it wants this stuff.

why it wants != requirements

If you think ICANN has been pretty clear about its requirements, a URL would be handy. An ICANN staffer speaking up would be even more useful.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 30 Aug 2010 20:06:16 -0400

> needs into account when doing our engineering.

You forget that some of us actually watched that process and were
participants therein.

This group ignored the practical realities for five years before
finally accepting that ignoring them would not make them go away. In
2002 I stated that if OPTIN was accepted that DNSSEC would deploy in
.com, otherwise it would not. Everyone decided to call my bluff and
the moment was lost.

I wasn't bluffing. It has taken eight years to get back to that point.

> the "provisioning hacks" approach really expensive (in TCO terms.)

The fact that the provisioning hacks are too expensive does not mean
that the alternatives must work or be more practical.

Sure we can do a magic pointer approach but it won't work for any
people who don't have both an aware DNS resolver and are attempting to
contact an aware Web server. So during the introduction period the
service will work unpredictably. And that is the worst possible
outcome in my view.

When it comes to deployment I actually run models. I use simulations.
I have a methodology that allows me to identify stakeholders whose
cooperation is needed. In short I approach deployment as an
engineering problem.

What I am seeing from you here Paul is not an engineering approach. It
is something else.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 31 Aug 2010 09:16:59 +0900

> a specific language and has no relation to any ISO3166 TLD's namespace.")

What's wrong with

	CN.	NS	...
	CN0.	DNAME	CN.
	CN1.	DNAME	CN.
	CN2.	DNAME	CN.
	CN3.	DNAME	CN.
	  .
	  .
	  .

in the root zone?

If you also need "CN?" have RRs other than DNAME, let ICANN arrange
so. Same RRs in different "CN?"s can be same or different according
to the policy of ICANN.

							Masataka Ohta

PS

I'm tired of the boring attempt to modify DNS protocol only to combine
useless DNSSEC and useless IDN.

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 31 Aug 2010 10:48:50 +0800

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>; "Stephane Bortzmeyer" <[email-masked]>
Cc: <[email-masked]>; "Alex Bligh" <[email-masked]>
Sent: Monday, August 30, 2010 5:45 PM
Subject: Re: [dnsext] Re: DNSEXT charter and treating DNS names as "the same"

> making the applications perform similarly (as demonstrated several times).

if you talk about synchronized entries or synchronized names, it means that you have to make ieself and its childrens get the same DNS resolution.
that is also what the synchronized names mean.

> more flexible when 'the same thing' is sometimes wrong?

provision may make the names in one zone work, but may not make its childern zone work.

I think that we should be clear about one point we discussed before:

The question is not whether A and B are the same. It is "Resolving A and B leads to the same dns resolution result".

if you do not want to "Resolving A and B leads to the same dns resolution result", then the provision works, you may choose provision.

but if we want to ""Resolving A and B leads to the same dns resolution result"", then the provision does not work, we can not choose provision and may choose XNAME.

Jiankang Yao

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 31 Aug 2010 11:16:32 +0800

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: "Paul Vixie" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 31, 2010 8:04 AM
Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same")

> If you think ICANN has been pretty clear about its requirements, a URL would be handy. An ICANN staffer speaking up would be even more useful.

Tina from ICANN has a report in Brussels meeting. this may help us to understand it.

https://brussels38.icann.org/meetings/brussels2010/presentation-idns-dam-23jun10-en.pdf

also some idn seessions:
https://brussels38.icann.org/node/12683

https://brussels38.icann.org/full-schedule

---

From: David Conrad <[email-masked]>
Date: Mon, 30 Aug 2010 20:34:48 -0700

On Aug 30, 2010, at 3:01 PM, Paul Hoffman wrote:
> It feels like you are describing the constraints that some parts of that hive feels, but certainly not all.

My impression is that the specific problem affects a relatively small number of participants of the ICANN collective.  It's not that the other parts of the collective disagree with the constraints, it is more that the other parts don't (yet?) have the itch that the xNAME/SHADOW/etc. are proposed to scratch.

That is, folks in China and Greece (to my knowledge) have said "hey, there's a problem here" because they're facing that problem now.  As more IDNs get deployed, it's possible/likely/certain others will see the same problem.

> If it was all parts, then ICANN would not now be putting into the root TLDs that "require" synchronization.

The synchronization approach was (in my personal opinion) an egregious hack that was necessitated to address non-technical considerations and was done so with the (perhaps mistaken) assumption that the IETF would be providing a less egregious hack to deal with the more generic problem of "the same".

The fact that synchronization is required in (some of) the IDNs that are being inserted into the root now has no relation to whether all of ICANN believes a DNS protocol-based solution is desired.

> That synchronization is not happening, which proves that the requirement is mislabeled. (Corrections from ICANN staff are welcomed here.)

Not ICANN staff, but...

I wasn't aware that synchronization wasn't happening.  I believe the issue is that synchronization is (was assumed to be) a _temporary_ hack until a better solution came along and as such, the fact that it is going to be _really_ hard to ensure that all levels of names in a synchronized set are "the same" could be dealt with while people were waiting.

However, I am far from authoritative on this.

Regards,
-drc

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 31 Aug 2010 11:41:11 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, August 31, 2010 6:46 AM
Subject: Re: [dnsext] Re: DNSEXT charter and treating DNS names as "thesame"

> the DNS.  

they do not say that we must change the dns. they feel that the provision is just a short term sloution, not an ideal solution.

you may take a look at the following link:

also some idn seessions:

I think Tina from ICANN is also on the list. She may give us more documents or links or comments since there are many IDN related working groups in ICANN.

Jiankang Yao

>
>I would like those explanations to take the form of textual

---

From: David Conrad <[email-masked]>
Date: Mon, 30 Aug 2010 20:49:49 -0700

Andrew,

On Aug 30, 2010, at 3:42 PM, Andrew Sullivan wrote:
> Where exactly is ICANN's problem statement?  As one of the chairs who needs to agree to herd this work through the IETF, I'd like to see it.

An understandable request.  While not "ICANN's problem statement", I gather you do not believe http://tools.ietf.org/html/draft-yao-dnsext-identical-resolution-00 is sufficient?

> The only actual evidence we have from ICANN is that they _can_ do what they thought the synchronization stuff would achieve with provisioning, because in fact they already have.

I believe the concern is that this is analogous to the person who fell off the Empire State building being heard to say "So far, so good" as he passed each floor on the way down...

Regards,
-drc

---

From: Joe Abley <[email-masked]>
Date: Tue, 31 Aug 2010 00:23:23 -0400

> in the root zone?

Good question.

Part of the reason this thread continues to spiral around the plughole is that I don't believe anybody has taken the time to ask that question and others like it of non-technical policy people in a form they could understand.

I think a survey of existing mechanisms which could provide equivalence-type functionality (e.g. for registry operators and for end users) together with a clear description of the pros and cons of each would be really quite useful to guide policymakers. While we're at it, a clear indication that we might need to wait decades before certain classes of solution are ready to use might also come in handy (e.g. approaches that require changes to resolver behaviour). You never know, the result might be policy that is actually implementable.

I have a suspicion that to date the policy that is driving the noise we are hearing assumes that the technical problem space is unconstrained, which I think we believe (if we speak with one voice about anything) not to be true.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Tue, 31 Aug 2010 04:37:17 +0000

> Date: Mon, 30 Aug 2010 20:06:16 -0400
> From: Phillip Hallam-Baker <[email-masked]>
> 

i didn't forget.  i was there, and i was disgusted with the way that the
community ignored the clear need for opt-in.  you, sir, deserved better
treatment than you got.  and you were later proved right when several
CCTLD operators said "without opt-in there will be no DNSSEC in my CC".

> When it comes to deployment I actually run models. I use simulations.  I
> have a methodology that allows me to identify stakeholders whose
> cooperation is needed. In short I approach deployment as an engineering
> problem.

kewl.

> What I am seeing from you here Paul is not an engineering approach. It is
> something else.

that's off topic so i won't ask for details nor offer any reply to it.

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 31 Aug 2010 04:37:13 +0000

On Tue, Aug 31, 2010 at 12:23:23AM -0400, Joe Abley wrote:
> I think a survey of existing mechanisms which could provide
> equivalence-type functionality (e.g. for registry operators and for
> end users) together with a clear description of the pros and cons of
> each would be really quite useful to guide policymakers. While we're
> at it, a clear indication that we might need to wait decades before
> certain classes of solution are ready to use might also come in
> handy (e.g. approaches that require changes to resolver
> behaviour). You never know, the result might be policy that is
> actually implementable.

That document is under construction. Feel free to send text.

(That sounds flippant. It's not.)

> I have a suspicion that to date the policy that is driving the noise
> we are hearing assumes that the technical problem space is
> unconstrained, which I think we believe (if we speak with one voice
> about anything) not to be true.

Yep. And now we get to characterize the constraints in a way that
non-technical people will understand. Which is actually a manageable
task, and a problem statement that's coherent to us is a good step.

thanks,
Suzanne

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 31 Aug 2010 13:20:11 +0800

----- Original Message ----- 
From: "Masataka Ohta" <[email-masked]>
To: "Paul Vixie" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 31, 2010 8:16 AM
Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same")

>> a specific language and has no relation to any ISO3166 TLD's namespace.")

it does not wrong, but has some problems.

the proposed solution should work for different level domain names.

this issue has been dicussed in this list or dnsop list many times.

you may take a look at the message from .gr friend :

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2010/msg01306.html 

Jiankang Yao

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 31 Aug 2010 07:46:33 +0200

> An understandable request.  While not "ICANN's problem statement", I gather you do not believe http://tools.ietf.org/html/draft-yao-dnsext-identical-resolution-00 is sufficient?

I think that is a good start, but it doesn't talk for example on requirements regarding assignment of delegation to registries, i.e. requirements on delegations. Something I think ICANN should have a strong view on as that definitely have impact on regulative situation in for example many TLDs (i.e. competition regulation).

Note: I have not seen ICANN discuss that at all...so I do not think there are any requirements for such important matters. See the .POST discussions on how messy things are.

   Patrik

---

From: Alex Bligh <[email-masked]>
Date: Tue, 31 Aug 2010 08:08:51 +0100

--On 31 August 2010 13:20:11 +0800 Jiankang YAO <[email-masked]> wrote:

> > [DNAME]

Why? If the problem space is the ICANN non-technically driven one itself,
DNAME works fine so long as there are no other records at the zone apex,
doesn't it? I'm excluding here for the sake of argument problems arising
from the fact a large body of resolvers don't understand DNAME, because
an even larger body (100%) don't currently understand XNAME.

-- 
Alex Bligh

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 31 Aug 2010 15:22:58 +0800

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>; "Masataka Ohta" <[email-masked]>; "Paul Vixie" <[email-masked]>
Cc: <[email-masked]>; "Alex Bligh" <[email-masked]>
Sent: Tuesday, August 31, 2010 3:08 PM
Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same")

> doesn't it?
icann has discussed the dname for many years.
if it is good, it would have been used for the idn tld or second level idn.

you may also take a look at discussion here:

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg03016.html

Jiankang Yao

>
> I'm excluding here for the sake of argument problems arising

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 31 Aug 2010 00:26:47 -0700

+1

It's also worth noting that there is a clear bias in the discussion
towards some solution that is expressible on the wire (with signaling
of some kind) and in zone-files. This might be a case of "if you have
a hammer ..".

Given that even the most complicated of the use-cases we've seen so
far could be performed as a query-time rewrite in a handful of CPU ops
over microseconds in time - it would seem that making
domain-equivalence a simple configured feature of authoritative
name-servers could be a promising real-world solution. Isn't this the
purpose of the "@" label representation? So that single text
representations of zones could be used for multiple names? Maybe all
that's neccessary is a BCP pointing that out.

Placing the solution on the authoritative servers aligns the economic
incentives with the interested parties .. and could work without the
need for global resolver upgrades.

-- 
Colm

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 31 Aug 2010 15:38:01 +0800

----- Original Message ----- 
From: "Jiankang YAO" <[email-masked]>
To: "Alex Bligh" <[email-masked]>; "Masataka Ohta" <[email-masked]>; "Paul Vixie" <[email-masked]>
Cc: <[email-masked]>; "Alex Bligh" <[email-masked]>
Sent: Tuesday, August 31, 2010 3:22 PM
Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same")

> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg03016.html

there are also some discussions here.

http://www.ietf.org/mail-archive/web/dnsop/current/msg07700.html

---

From: Alex Bligh <[email-masked]>
Date: Tue, 31 Aug 2010 09:13:33 +0100

> if it is good, it would have been used for the idn tld or second level

With respect, saying "ICANN have talked about it for many years and nothing
happened" doesn't mean anything, and is certainly not an answer to
my question. As is the way of large multistakeholder
organisations, ICANN talks about lots of things for long periods of time,
sometimes goes down rat holes, and sometimes produces an answer. See,
for example, IDN TLDs.

> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg03016.html

This is one person saying "may be new RRs get introduced more quickly
than you think". I believe the latest significant RR was NSEC3. How
long did that take?

-- 
Alex Bligh

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 31 Aug 2010 16:54:06 +0800

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>; "Masataka Ohta" <[email-masked]>; "Paul Vixie" <[email-masked]>
Cc: <[email-masked]>; "Alex Bligh" <[email-masked]>
Sent: Tuesday, August 31, 2010 4:13 PM
Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same")

> sometimes goes down rat holes, and sometimes produces an answer. See,

true. " talked about it for many years and nothing
 happened" might not mean anything"
but
"there is a solution, and icann do not use it" is different with "the proposed solution is not good, and icann does not decide it "

most participants of dname dicussion in ICANN has the technic background. they think that there may have some problems if we use dname for idn tld or idn.
ICANN depends on these people for decision. it lasts for so many years because the technical people in icann or ietf can not recommend a good solution, not because that icann does not want to give a conclusion.

if you like to see more technical discussion about dname,
you may look here:

thanks.

Jiankang Yao

---

From: Alex Bligh <[email-masked]>
Date: Tue, 31 Aug 2010 10:12:36 +0100

--On 31 August 2010 16:54:06 +0800 Jiankang YAO <[email-masked]> wrote:

> most participants of dname dicussion in ICANN has the technic background.
> they think that there may have some problems if we use dname for idn tld
> or idn.

But what *are* the problems? Any more than those in the message listed
below?

> ICANN depends on these people for decision. it lasts for so many
> years because the technical people in icann or ietf can not recommend a
> good solution, not because that icann does not want to give a conclusion.
>

So, this sets out the following perceived problems:

* For D0. and D1. to be equivalent using DNAME, the authoritative
  registries below the D0. and D1. zone cuts need to be DNAME aware.
  To the extent that is accurate (is that really true of the DNAME
  target?), it would seem to apply to XNAME too.

* The root zone is very important (no arguments here), so ought to
  be running "stable technology" (ditto). XNAME is, however, newer
  than DNAME, in that it doesn't yet even exist.

* Growth of the root zone file. To which I'd argue we have a plenty
  of collective experience running zones with several thousand
  entries. But, if the requirement is for "strong binding" (i.e.
  ICANN don't trust contractual solutions) then the equivalence
  data *MUST* be put in the root zone, not in a delegated zone.
  This is exactly why it is being argued that the provisioning
  method does not satisfy ICANN's requirements.

Perhaps I have missed some.

Can I verify that this list of DNAME problems is your own
interpretation of them (and, to be clear, there is nothing
wrong with that) rather than a problem statement from ICANN?

-- 
Alex Bligh

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 31 Aug 2010 17:34:50 +0800

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>; "Masataka Ohta" <[email-masked]>; "Paul Vixie" <[email-masked]>
Cc: <[email-masked]>; "Alex Bligh" <[email-masked]>
Sent: Tuesday, August 31, 2010 5:12 PM
Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same")

> But what *are* the problems? Any more than those in the message listed

i think that icann needs the solution for IDN TLD and IDN.
If icann recommend DNAME for idn tld, someone may also use it for idn too.

since dname is mapping its children only,  it can not be used for alias.gr and alias1.gr.

there also some points here:

http://www.alvestrand.no/pipermail/idna-update/2008-January/000983.html

> wrong with that) rather than a problem statement from ICANN?

this is the discussion material from me, not ICANN's.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 31 Aug 2010 10:52:13 +0100

> since dname is mapping its children only,  it can not be used for

But if the problem space is ICANN TLDs themselves, how many TLDs
have records at their apex?

If you mean within the TLDs, then ICANN has no /technical/ control
of whether the registry make alias.gr and alais1.gr equivalent,
so the provisioning hack is the best you can get. Indeed it gives
ICANN *better* guarantees of equivalence than an XNAME solution
where XNAME is beyond the zone cut (i.e. in alias1.gr) as that
is up to the registrant rather than the registry.

> http://www.alvestrand.no/pipermail/idna-update/2008-January/000983.html

It's difficult to jump into threads, but John appears to be arguing
for DNAME use (see last paras).

-- 
Alex Bligh

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 31 Aug 2010 18:52:45 +0900

Alex Bligh wrote:

> But what *are* the problems?

The problem is that the concept of IDN is broken from the beginning.

Let DNAME, another broken concept introduced from broken activities
of broken IPv6, take care of it.

So great regulatory power of ICANN should be able to force people
use IDN and DNAME widely.

						Masataka Ohta

---

From: [email-masked]
Date: Tue, 31 Aug 2010 09:51:31 +0000

> Part of the reason this thread continues to spiral around the plughole is that I don't believe anybody has taken the time to ask that question and others like it of non-technical policy people in a…

	sigh... one can never be sure that non-technical policy people will understand.
	eight years ago(2001/2002), JPRS and CNNIC both tested that construct in the 
	RS.NET testbed.  we know it works for some form of "equivalence".

> I think a survey of existing mechanisms which could provide equivalence-type functionality (e.g. for registry operators and for end users) together with a clear description of the pros and cons of…

	i beleive the dnsext wg is producing such a survey.  which is kind of odd, if the target
	audience is policy makers... "...behold the Internet Policy Task Force (IPTF)..."

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 31 Aug 2010 08:32:30 -0700

>https://brussels38.icann.org/meetings/brussels2010/presentation-idns-dam-23jun10-en.pdf

With all due respect, I do not see anything in here that could be called "pretty clear" about requirements. Sending links to presentations that discuss possible solutions but do not discuss the problems is not helpful to this discussion.

>https://brussels38.icann.org/node/12683

And the same here. I see presentations on well-known IDN issues, not clear statements of requirements for equivalence.

>https://brussels38.icann.org/full-schedule

And that's just insulting.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 31 Aug 2010 12:32:49 -0400

> That is, folks in [...] Greece (to my knowledge) have ...

Good point David, the tonos issue is unlike the Arabic Script variants 
and unlike the SC/TC equivalences.

Eric

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 31 Aug 2010 12:46:25 -0400

Hi,

This is still sent with the
baffled-chair-trying-to-get-problem-statement hat on.

> they do not say that we must change the dns. they feel that the provision is just a short term sloution, not an ideal solution.

Right.  But this WG isn't about the ideal solution.  The ideal
solution involves replacing DNS with a completely new protocol that is
internationalized from the ground up.  I have previously suggested
that people who want to do that should start work on it, perhaps with
a bar BOF or something.  I don't predict success, but I wish such an
effort well.

> https://brussels38.icann.org/meetings/brussels2010/presentation-idns-dam-23jun10-en.pdf

I had a look at that.  I also listened to the audiocast when Tina made
that presentation.  It still doesn't tell me much. 

Here are the relevant bits:

Slide 8 outlines the different ways that people use the term
"variant".  It also explicitly notes that "translation" is not
"variant", so the people who want ".org in another language", whatever
that would mean, are not asking for variants.

Slide 11 says that a dialogue is needed, that the requirements haven't
been communicated, and that there are a coupld possible ideas kicking
around one of which is long specified but not well tested, and another
of which isn't even specified yet.

That's it.  That's all the outline of the issues that directly
impinges on the DNS in the entire slide deck.  The rest of the
discussion is about what might get registered and what the rules maybe
ought to be.  But "name available somewhere" can be done with
provosioning, and so we still don't know why that's inadequate.

Now, you have argued more than once that what is needed is a protocol
rule that enforces the sameness across a delegation boundary (that's
what BNAME is for).  What this really amounts to is a claim that we
need in-protocol support to ensure compliance with a particular policy
decision.  That's a defensible claim in principle, but it comes with
the obligation to explain why the rest of the DNS users need to pay
the cost of this additional feature (new features always entail a
cost, if only of development and testing) and why alternatives aren't
just as good.  Those arguments haven't so far been clear enough, I
think, to make the case.

My current, personal thinking is along the lines Joe Abley posted
up-thread.  We need to get a complete picture of all the things that
can in fact be done right now, and all the things that people want to
be able to do, as near as we can put that together; we combine with
those a list of all the known side-effects of these strategies.  We
point the people who we think have issues here, and try to find out
whether they understand the message.

Only after that work is showing some effects do we undertake changes
to the protocol.

Does that approach make sense?

A

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

---

From: David Conrad <[email-masked]>
Date: Tue, 31 Aug 2010 13:15:34 -0700

On Aug 31, 2010, at 9:46 AM, Andrew Sullivan wrote:
> What this really amounts to is a claim that we

I'd agree that it'd be interesting to compare the one-time cost of development/testing/deployment of a new feature to the ongoing operational cost of synchronization.  I suspect coming up with reasonable estimates for both would be challenging.

> We need to get a complete picture of all the things that

Sounds reasonable to me.

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Tue, 31 Aug 2010 22:24:26 +0000

On Aug 31, 2010, at 9:46 AM, Andrew Sullivan wrote:
> What this really amounts to is a claim that we need in-protocol support
> to ensure compliance with a particular policy decision.  That's a
> defensible claim in principle, but it comes with the obligation to
> explain why the rest of the DNS users need to pay the cost of this
> additional feature (new features always entail a cost, if only of
> development and testing) and why alternatives aren't just as good.  Those
> arguments haven't so far been clear enough, I think, to make the case.

nor were they for RFC 5011 or RFC 5155, yet somehow we (eventually) did the
right thing, which was to enable maximal deployment at reasonable shared cost.

---

From: "Patrik Faltstrom (pfaltstr)" <[email-masked]>
Date: Wed, 1 Sep 2010 00:54:24 +0200

On 31 aug 2010, at 18:48, Andrew Sullivan <[email-masked]> wrote:

> and all the things that people want to
> be able to do

And, to repeat myself, I want resolution of A and B to result in "the same thing" from an applications point of view *without* doing multiple delegations as multiple delegations have implications on competition legislation etc.

If the application can know what the canonical name is, that is a bonus as it make http, tls etc negotiations easier.

   Patrik

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 1 Sep 2010 01:18:21 +0000

> Does that approach make sense?

I think this is more or less what I said in the charter discussion in
Maastricht. Even if it's not, the answer to your question is "Yes,"
with only the caution that analysis of what *could* reasonably be done
to the protocol has already begun and will, to some extent, proceed in
parallel with the discovery procss you're proposing of what *should*
be done.

Suzanne
(hat in hand)

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 1 Sep 2010 09:23:36 +0800

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 31, 2010 11:32 PM
Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same")

> With all due respect, I do not see anything in here that could be called "pretty clear" about requirements. Sending links to presentations that discuss possible solutions but do not discuss the pro…

if the internet users think that name A and B are variants or alias,
the problem is that "name A and B needs to  get the same DNS resolution result".

The question is not whether A and B are the same.  if you think that the problem is that "The question is whether A and B are the same. ",

that may not be clear. but defining of whether or why A and B are the same is out of our wg.

our job is to make name A and B  get the same DNS resolution result if the users need to do so.

> And the same here. I see presentations on well-known IDN issues, not clear statements of requirements for equivalence.

this will help someone to understand the IDN issues related to this problem.

> And that's just insulting.

someone may require more idn background or context, they can look for more IDN sessions in this link.

if you think that it is insulting, I am sorry about it.

JIankang Yao

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 31 Aug 2010 22:04:30 -0400

> ... I want resolution of A and B to result in ...

i think i'll cease offering what little i think i bring here, but i'll 
settle for being able to make useful assertions about the temporal 
properties of the difference of resolution.

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 1 Sep 2010 11:11:03 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 01, 2010 12:46 AM
Subject: A next step? (was: [dnsext] Re: DNSEXT charter and treating DNSnames as "thesame")

> a bar BOF or something.  I don't predict success, but I wish such an

if we don't use dns, icann may disappear.

the efforts without dns should base on the next generation of internet.

current name resolution is based on dns. so we have to do something based on dns.

if we try to  shied away from this question,  it is  failing in our duty to make dns work for all the internet users. 

> provosioning, and so we still don't know why that's inadequate.

thanks chair for your hardworking .
 
> just as good.  Those arguments haven't so far been clear enough, I

1. there has billions of internet users who use IDN instead of millions.
2. current IDN TLD or IDN need it.
3. Provision may work in the one-level domain names or on one zone. it can not work for all levels domain names if there are delegations of the children names of different levels.
4. before IDN appears, we may ask the same question "ABC.example is ok, why there should have IDN.example?"
5. name equivalence in the sense of identical resolution is a general-purpose function of DNS. IDN is a just good user case of it. our proposed solution is a general solution for all names.
6. New technologies, tools or products are not always interested at the beginning, users are enlightened and guided to get more and more involved.
7.  Some requiremenmts might be only or not easily observed by some of us, but there has a requirement. If we only do things which are urgently needed when the requiremenmts could be observed by all, i guess maybe, we now had a totally different world.
8. Since identical resolution is needed definitely by the IDN users NOW and, more or less needed by others in the future.

Jiankang Yao

---

From: "Cindy Wang" <[email-masked]>
Date: Wed, 1 Sep 2010 11:33:40 +0800

And, identical resolution should happen at both the nodes and their sub-trees, which couldn't be achieved by provision anyway. Am i right?

Cindy Wang
CNNIC

---

From: Alex Bligh <[email-masked]>
Date: Wed, 01 Sep 2010 07:34:40 +0100

--On 1 September 2010 09:23:36 +0800 Jiankang YAO <[email-masked]> wrote:

> The question is not whether A and B are the same.  if you think that the
> problem is that "The question is whether A and B are the same. ",
>

Disagree. This begs the question. At the very least at the investigation
stage we need to determine whether want the same DNS result or applications
to perform the same, as these two diverge.

-- 
Alex Bligh

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 1 Sep 2010 14:53:50 +0800

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>; "Paul Hoffman" <[email-masked]>
Cc: <[email-masked]>; "Alex Bligh" <[email-masked]>
Sent: Wednesday, September 01, 2010 2:34 PM
Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same")

> to perform the same, as these two diverge.

"want the same DNS result "  fall in the scope of this wg.

 does "applications to perform the same" fall in this wg?

Jiankang Yao