Subject: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Apr 2010 10:51:17 -0400

Dear colleagues,

I'm speaking only for myself, here, in trying to come to some
conclusions in light of the discussion we had in Anaheim about DNS
"name equivalences" and so on.  Importantly, I want to convey that I
haven't discussed this with Olafur and that I have not reached any
conclusion.

We have been investigating two things in parallel:

    1.  What the requirements would be for some kind of additional
    aliasing mechanism for the DNS.

    2.  Whether there is any protocol work that DNSEXT should do in
    support of (1).

ICANN has issued some questions and answers
(http://www.icann.org/en/topics/idn/fast-track/synchronized-idn-cctlds-faq-en.htm)
in support of their "Proposed Implementation Plan for Synchronized IDN
ccTLDs"
(http://www.icann.org/en/announcements/announcement-22mar10-en.htm).
The Q&A makes perfectly clear that, at least as far as ICANN is
concerned, whatever synchronized TLDs are, they have nothing to do
with the DNS.  To the extent that two synchronized domains are
supposed to have similar zone data, that is entirely a matter for
provisioning tools and contracts.

ICANN's plan might be understood to suggest that, even if there is a
problem here to be solved (and I guess there is, or ICANN wouldn't be
doing something about it), no protocol work is needed in order that it
could be addressed.  Are others in agreement with that?  If so, then
it would appear that the WG does not need to consider this topic any
more as a possible work item.

If you do not agree with that conclusion, it would be interesting to
me to hear why not, and what you think needs support in the protocol
that cannot be accommodated in ICANN's plan.

Best regards,

Andrew

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

---

From: Kim Davies <[email-masked]>
Date: Fri, 9 Apr 2010 08:28:57 -0700

> that cannot be accommodated in ICANN's plan.

I think it would be fair to say the ICANN staff's view is that we are highly desirous of a protocol-level solution to this problem. However there are immediate non-technical imperatives to launch synchronised domains in some fashion and this is an approximation that can be accomplished within the current framework. Operators of synchronised domains would be required to migrate from this interim arrangement to any technological solution the technical community can come up with.

So, no, I don't think the intent of the ICANN proposal is to suggest this is the final solution to the problem.

kim

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Apr 2010 11:41:38 -0400

On Fri, Apr 09, 2010 at 08:28:57AM -0700, Kim Davies wrote:
> I think it would be fair to say the ICANN staff's view is that we
> are highly desirous of a protocol-level solution to this
> problem. However there are immediate non-technical imperatives to
> launch synchronised domains in some fashion and this is an
> approximation that can be accomplished within the current
> framework. 

Excellent.  Now, if you could just give me an operational definition
of "synchronised domain", we'd be in business.  The ICANN Q&A makes it
clear that it's a matter of users not being surprised.  It doesn't
even require the A records for a pair of subordinate (respective)
labels to be the same, the zone example notwithstanding (and I can
think of plenty of ways in which having them different would be a way
to make users less surprised).  As far as I can tell, domains are
synchronized just in case the top-level operator says so.

So what problem are you going to solve with a protocol-level solution
that isn't solved here already?

> Operators of synchronised domains would be required to
> migrate from this interim arrangement to any technological solution
> the technical community can come up with.

Quite apart from the novel jurisprudence entailed by a US corporation
"requiring" anything of foreign sovereign states, I don't understand
how you can make this blanket requirement for a technical solution we
haven't invented yet.  Maybe it won't work for the case in question.  

Moreover, it seems that the ICANN plan is going to give us an
unpredictable number of new deployed solutions with which we can't be
incompatible.  Right?

A

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

---

From: Paul Vixie <[email-masked]>
Date: Fri, 09 Apr 2010 15:45:09 +0000

> From: Kim Davies <[email-masked]>
> Date: Fri, 9 Apr 2010 08:28:57 -0700
> ...

this is compatible with my own design constraints, which included:

	Must not require stubs or recursives to be upgraded, since there
	are millions of these and the tail is long

	Must be an Internet Standard, not a proprietary or adhoc extension,
	to facilitate multivendor operation

	Must not place any burden on registry, which may be regulated (so,
	autoinsertion into root zone, no!)

	Authority server operators, protocol implementors, and registrars
	can accept burdens, since they have incentives, and are few in
	number

BNAME and SHADOW both meet these criteria, in that they would require action
only unilaterally (by the zone's authority server implementors/operators).

as such, a fast tracked response by this WG which was similar to "make BNAME
and SHADOW available" would still be very well timed to meet kim davies'
(ICANN's) stated objectives.

note that other methods besides BNAME and SHADOW may be superior once a
problem statement is generally agreed.  i'm using them here as examples of
things this WG could do that would still be relevant even given ICANN's
current zone synchronization fast-track proposal, referred to up-thread.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 9 Apr 2010 09:35:02 -0700

At 8:28 AM -0700 4/9/10, Kim Davies wrote:
>I think it would be fair to say the ICANN staff's view is that we are highly desirous of a protocol-level solution to this problem.

That statement does not match with what is written in the Q&A at <http://www.icann.org/en/topics/idn/fast-track/synchronized-idn-cctlds-faq-en.htm>: "Synchronized" in the context of this process relates solely to policy and procedural requirements. There is no technical mechanism by which synchronized IDN ccTLDs will be made to be identical at the DNS protocol level.

Or are you differentiating "ICANN staff" from "ICANN" (as many of us do)?

> However there are immediate non-technical imperatives to launch synchronised domains in some fashion and this is an approximation that can be accomplished within the current framework. Operators of synchronised domains would be required to migrate from this interim arrangement to any technological solution the technical community can come up with.

Where in the Q&A or the main document is there a discussion of such migration? This is a serious question for this WG.

>So, no, I don't think the intent of the ICANN proposal is to suggest this is the final solution to the problem.

The above quote, and other similar text in the proposal and the Q&A, indicate otherwise. Getting something definitive from ICANN will have a significant impact on this WG.

--Paul Hoffman, Director
--VPN Consortium

---

From: Kim Davies <[email-masked]>
Date: Fri, 9 Apr 2010 10:10:44 -0700

> that isn't solved here already?

I'll caveat my answer with saying I am somewhat involved in this synchronised domain concept, but thus far limited to answering questions from colleagues on what would be the impact on IANA's root zone operations. I hope more directly involved colleagues will chime in if I am off base here.

The fine details of the implementation of any synchronised TLD plan are not developed yet. The basic notion is that using contractual language between ICANN and the TLD operator, the TLD operator would be expected to take steps to keep multiple trees in synch, even through they are technically separate delegations at the root level. Administrative changes to the TLD delegation would likely need to be kept in synch. 

In the introduction of the draft implementation plan[1], it reads "The issue relates to instances in the Fast Track Process where more than one official language or script exists within a country/territory, and where requests for multiple corresponding strings are considered equivalent. In these cases, those accessing domains under any of the strings expect that such domains will resolve to the same address or value. Strings meeting these requirements, and operated in a way to meet community expectations are referred to as synchronized IDN ccTLDs."

A basic assumption of the draft model is that the only tools available in the root zone at present are NS records. It could be some other technology, be it DNAMEs or other alternatives are appropriate, but there is nothing right now tested and deployable to the point it can be confidently put into production in the root zone in the near future.

> haven't invented yet.  Maybe it won't work for the case in question.  

If a technical solution presents itself that involves altering the root zone to a different set of records to make two TLD structures match, then the intention is ICANN will migrate from NS records in the root to the new solution over some transition period.

> unpredictable number of new deployed solutions with which we can't be

I think staff estimate this addresses a few corner cases, which is not entirely predictable but is a relatively small amount. But the use case is the same for each of the potential synchronised ccTLDs. I am not sure if that answers your question?

I have a feeling by sticking my head up, I am about to be called on for not paying enough attention to the CLONE/BNAME etc. discussions recently...

kim

[1] http://www.icann.com/en/topics/idn/fast-track/proposed-plan-synchronized-idn-cctlds-22mar10-en.pdf

---

From: Kim Davies <[email-masked]>
Date: Fri, 9 Apr 2010 10:11:54 -0700

...

>From the FAQ:

"Should technical developments facilitate alternative mechanisms for supporting variants of TLDs in the root zone which are found to be preferable to provisioning variants using distinct delegations, ICANN will develop an appropriate phase-in period and operators of synchronized IDN ccTLDs will need to migrate as appropriate to the new methodology."

So, yes, the current proposal is for a policy/procedural only mechanism, but intending to move to a technical one when possible.

kim

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Apr 2010 14:05:35 -0400

Dear colleagues,

I'm going to push hard in this mail, because I really want to
understand what work we think is needed to be done in this space given
the evidence before us.  Again, I wish to emphasise that I'm speaking
for myself, in trying to understand our requirements gathering, and I
have not made up my mind.  

On Fri, Apr 09, 2010 at 10:10:44AM -0700, Kim Davies wrote:
> 
> The fine details of the implementation of any synchronised TLD plan
> are not developed yet. The basic notion is that using contractual
> language between ICANN and the TLD operator, the TLD operator would
> be expected to take steps to keep multiple trees in synch, even
> through they are technically separate delegations at the root
> level. Administrative changes to the TLD delegation would likely
> need to be kept in synch.

The trouble is, we have no precise definition of what it would mean
for them to be "in synch", and this bears directly on what we might
conceivably be able to do here.  If existing provisioning-side
approaches are good enough and safe enough to do this already, today,
for the root zone and, according to the Plan, with some sort of
commitment that it will carry all the way down the tree, why do we
need to do any more work?  For more details on what this all could
mean, see below.  First, an administrative note.

Remember, as a WG chair one of my jobs is to make sure the WG doesn't
take on work it is incapable of finishing.  Moreover, we are
responsible for a mature protocol with a large installed base and a
long history of painful protocol extensions (look at the demonstrated
facts around TCP use, the long history of DNSSEC deployment, and the
fact that EDNS0 continues to be problematic in some places, for
examples).  I expressed openness towards this aliasing topic because
operators were claiming that the solutions we have now could not meet
their needs.  But at the time some people said, "This is a simple
provisioning and contract issue, and there's no need for more work."
If ICANN now actually implements some sort of aliasing using only
contracts and provisioning rules, then that is evidence for the
conclusion that the WG need do no more.  Adding more things to the
protocol adds complexity, and therefore we need a much better argument
than, "We think it would be nice," in order to consider seriously big
protocol additions.  Finally, there's the administrative problem of
adequate review: this WG has a hard time reviewing even simple
documents, and the aliasing proposals all have big implications for
topics like DNSSEC.  We have too the complaint that any formal
aliasing mechanism opens whole new opportunities for phishing and so
on, so there is a raft of security issues that we'd have to
investigate if we take on this work.

So, if I put all that up against something already implemented (which,
assuming it "works" for some value thereof, means that the problem is
solved), I have a hard time seeing why the WG would want to do
anything to the DNS protocols.

Now, to the substance of your claim.  The Q&A posted yesterday does
require that operators make changes to all synchronized TLDs at the
same time, but that nowise requires that the trees be "in sync", for
any ordinary meaning of the word.  On the contrary, the Q&A says
plainly that these are two completely separate delegations, and that
the only criterion for whether things are synchronized is whether
users' expectations are met.  Nowhere is that criterion
operationalized, but because it's a matter of user experience this WG
doesn't have to care: it's outside our competence to solve.  I can
certainly imagine plenty of ways in which users' expectations could be
best met by having completely different RDATA in two completely
different zones, so I don't see any reason why there is any
implication at all for the DNS here.
 
> In the introduction of the draft implementation plan[1], it reads
> "The issue relates to instances in the Fast Track Process where more
> than one official language or script exists within a
> country/territory, and where requests for multiple corresponding
> strings are considered equivalent. In these cases, those accessing
> domains under any of the strings expect that such domains will
> resolve to the same address or value. Strings meeting these
> requirements, and operated in a way to meet community expectations
> are referred to as synchronized IDN ccTLDs."

I think it will not be a surprise that that definition has led to a
lot of gnashing of teeth.  I'm going to leave aside the issue with
"language or script", because this isn't an internationalization
forum.  I'm also going to ignore the fanciful idea of "resolving to a
value".  For the purposes of this WG, the problem is that I don't know
what the targetted behaviour is.

Suppose that we have TLD1 and TLD2, and they're supposed to be
synchronized.  TLD1 comes from one repetoire of Unicode characters.
Call it range1.  TLD2 comes from another repetoire of Unicode
characters.  Call it range2.  The only restriction is that range1 and
range2 have at least one character that differs between them (they're
not equivalent sets.  In the unlikely event that any people who know
about writing systems are reading this, I understand that this
simplifying assumption is already really bad.  Never mind that).  Now,
suppose we have any sets of labels, each of which is either in range1
(symbolized r1) or range2 (symbolized r2).  Which of the following
behaviours is desired:

        a.  Should DNS names in the zones underneath the two
        synchronized zones be exactly (bit-for-bit) equivalent to one
        another?  For example, for a fully qualified domain name of
        the form r1.r1.tld1, must there always and only be a
        synchronized entry r1.r1.tld2?

        b.  Should all and every label under TLD1 be expressed in LE1
        and all and every label under TLD2 be expressed in LE2?  For
        example, for a fully qualified domain of the form r1.r1.tld1
        must there always and only be a synchronized entry
        r2.r2.tld2?

        c.  Should every label at every level of the DNS be expressed
        in both LE1 and LE2 (the combinatorial case)?  For example,
        for a fully qualified domain name of the form
        r1.r1.r1.tld1, would it be necessary also to have
        r1.r1.r1.tld2, r2.r1.r1.tld2, r2.r2.r1.tld2,
        r2.r2.r2.tld2, r1.r2.r2.tld2, and so on?

Those are three different aliasing behaviours.  For the purposes of
this WG, we don't care what the linguistic issues underlying this are,
but we need to understand which of these are target behaviours and
which not, so that we can (if we're going to do the work) address
them.

ICANN's answer, as near as I can make out from the Plan and the Q&A,
is that we don't have to worry about it, because the right rules will
be used for provisioning and for checking that behaviour conforms to
users' expectations whatever happens.  That's fine and good, and it
means we don't have to do any work.

Moreover, ICANN can't possibly mean anyway that the DNS trees are
going to be "synced", even allowing for the issues surrounding loose
coherence, TTLs, refresh times, and so on.  That's because lots of
these RRs _cannot_ be equivalent by definition: RRSIGs, NSEC(3)s, DSs,
SOAs, and so on need to have zone-specific or owner-specific RDATA.
This is a hard requirement of the protocol.  ICANN's answer to that
today is, "Right, and you don't have to worry about it because these
are just different delegations in the DNS."  That's good, but it again
leads me to the conclusion that there is no work that this WG needs to
do on this topic, because it can all be handled at the provisioning
and contractual side.

So I still don't understand how it is that ICANN's plan is not
evidence that this WG has nothing to do in the area of aliasing --
i.e.  that all the concerns that we thought we'd previously heard turn
out to be solvable by provisioning mechanisms.  What is the problem
that needs solving?

Best,

A

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

---

From: John Levine <[email-masked]>
Date: 9 Apr 2010 18:46:20 -0000

>doing something about it), no protocol work is needed in order that
>it could be addressed.  Are others in agreement with that?

It is my impression that making two domains look or act "the same"
depends at least as much on the behavior of web servers, MTAs, and
other non-DNS software as on anything we could possibly do.

R's,
John

---

From: David Conrad <[email-masked]>
Date: Fri, 9 Apr 2010 08:47:29 -1000

Andrew,

On Apr 9, 2010, at 8:05 AM, Andrew Sullivan wrote:
> conclusion that the WG need do no more.  

No, it isn't.  Synchronized domains is obviously a hack and it absolutely will not scale (I personally have my doubts it will even scale at n=1, but that's probably just me).  It is not a generic solution and applies only at the TLD level.

> What is the problem that needs solving?

If I remember correctly, it was that DNAME was felt by some to be an insufficient solution to the generic aliasing problem.

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Apr 2010 15:01:01 -0400

On Fri, Apr 09, 2010 at 08:47:29AM -1000, David Conrad wrote:

> It is not a generic solution and applies only at the TLD level.

That is not what ICANN's documents currently claim, because the Plan
says (and the Q&A repeats) that the synchronization will be propagated
all the way down the trees.  If that claim is not completely empty,
then similar mechanisms can be followed all the way down.

> If I remember correctly, it was that DNAME was felt by some to be an
> insufficient solution to the generic aliasing problem.

Yes.  And now we have a particular proposal that does it all by
provisioning and contracts, and I'm not even sure which of the
scenarios (if any) I outlined is aimed at.  I think the answer is "all
of them", and I think that is therefore an existence proof that
everything can be done in policy & provisioning today.  (I think I've
now said this every way I can think to do, so I won't repeat it in
detail again.)

If the claim is that policy & provisioning won't scale, then it'd be
nice to know what the desired scaling properties of anything we might
do need to be, along with the other details I've asked for. 

With emphasis: no decision here.  I'm just trying to understand the
problem we're trying to solve.

A

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

---

From: Jim Reid <[email-masked]>
Date: Fri, 9 Apr 2010 20:06:47 +0100

On 9 Apr 2010, at 19:05, Andrew Sullivan wrote:

> out to be solvable by provisioning mechanisms.

Frankly, I no longer understand ICANN's plan or what it might mean.  
Both in a general sense and for its impact on the DNS. Perhaps I'm  
just being more obtuse than normal and there is nothing to worry  
about. However if there is wider uncertainty or confusion, it needs to  
be cleared up. And soon. ICANN's consultation closes early next week.

> What is the problem that needs solving?

I don't know. It seems ICANN is saying it'll be OK for "synchronized  
domains" in "different scripts" (whatever ICANN mean by these terms)  
to be loosely coherent. If that's the case and there's a consensus for  
that view at the IETF, then we're done. There's nothing to see here,  
move along.

OTOH, Kim's just said ICANN staff would like a protocol-level  
solution. Well, that is very unlikely to be achieved in line with the  
plan's timetable for equivalent ccTLDs. If ICANN goes ahead with  
something else before this protocol solution is ready -- which assumes  
they give this WG a clear problem statement to work on and provide the  
metric for determining success -- then that opens up a whole raft of  
new issues. Migrating from an interim approach to the protocol  
solution, backwards compatibility & interoperability, etc, etc. Maybe  
those using some interim policy/procedural solution will have no  
interest in migrating to a protocol solution.

Remember ICANN can't impose things on ccTLDs as they can with gTLDs.  
Almost no ccTLDs have a contract with ICANN. It doesn't involve itself  
in ccTLD activities because that's a matter of National Sovereignty.  
So if ICANN goes ahead with a policy/procedural solution now, it may  
be impossible to put that genie back in its bottle later. Or deny that  
policy/procedural solution to current and new gTLDs.

I also have concerns that ICANN's interim policy/procedural solution  
will impose or distort the constraints on whatever protocol work this  
WG does.

The fuzziness is rather unsettling.

---

From: Doug Barton <[email-masked]>
Date: Fri, 09 Apr 2010 12:20:35 -0700

On 04/09/10 08:41, Andrew Sullivan wrote:
> "requiring" anything of foreign sovereign states, 

Andrew,

This comment is unhelpful, and inappropriate. As you yourself have asked
in the past, it would be helpful if we could stay focused on the
technical aspects of the issue(s) and not go down ratholes regarding
whether or not we agree with various policy aspects.

I realize that being asked to provide what amounts to be (to some extent
at least) a technical solution to a policy/legal problem is distasteful
to some in the group. However, this is the world we live in, you may
choose not to participate. But if you choose TO participate it should be
done with civility.

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Apr 2010 15:30:17 -0400

> whether or not we agree with various policy aspects.

I think you're entirely right to point out that it's irrelevant to the
technical matter, and I therefore withdraw it.  

I still believe there is a practical matter that impinges on the
alternatives open to the WG if some top-level domains claim to have
some system for keeping different trees "in sync", for whatever "sync"
means.  For practical purposes we will not be able to do anything that
does not provide all the features of those (to-be-deployed) systems.
I note that it will also be quite a bit harder to know what things we
have to be compatible with if we do not understand what the features
of those to-be-deployed systems are.  This practical matter goes
directly to the question of whether this WG ought to take on the work,
since if there's no reasonable prospect for success of a work item we
simply can't adopt it as part of the charter.

> But if you choose TO participate it should be done with civility.

I'm not sure what it was I said that was uncivil, but I certainly
didn't intend to be.  To those who understood my remarks to be
uncivil, I apologise.

A

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

---

From: David Conrad <[email-masked]>
Date: Fri, 9 Apr 2010 10:06:12 -1000

Andrew,

> then similar mechanisms can be followed all the way down.

Sorry, I was unclear.  The solution is not generic and applies only at the TLD level in the sense that it is a requirement imposed by ICANN on the registries and it is the registries' responsibility to ensure that the synchronization propagates down the tree for all the synchronized names under the TLD.

In theory, I suppose a domain name holder could apply this for the names they have registered, but I suspect they'd rather use DNAME.

> of them",

No.  As I understand it, synchronized domains is attempting to address a very small subset of the aliasing problem, specifically linguistically/culturally identical albeit visually dissimilar strings that users expect to behave identically in the Fast Track IDN ccTLD program. 

> do need to be, along with the other details I've asked for. 

I would assume we'd want the same scaling properties as any other aspect of the DNS.  The scaling concerns I have is that synchronized domains requires verification that the trees are remaining synchronized.  For one or two trees, that might be feasible (depending on how much splay there is in the tree).  However, imagine thousands of synchronized domains.  I honestly can't believe this would actually work.

Regards,
-drc

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 09 Apr 2010 17:33:12 -0400

David,

Assuming just for the moment that we are discussing two proposed
entries in the IANA root zone:

	1. 中国, xn--fiqs8s, "chung guo", "China", zh-hans

	2. 中國, xn--fiqz9s, "chung guo", "China", zh-hant

Could you explain to me what "applies only at the TLD level" means?

Assuming that there is one or more entry in each of the zones, and at
least one of these is non-leaf, at what point does the ICANN posited
mechanism cease to apply?

I don't need a prompt answer, I'm simply asking because of the
distinction between "applies only at the TLD level" and what I
understood from the (rather peculiar, process and text) ICANN text
which seems to ask for a recursive descent complete mechanism.

Thanks for taking the time to pull on the slippery end of a worm.

Eric

---

From: John Levine <[email-masked]>
Date: 9 Apr 2010 21:42:04 -0000

>No.  As I understand it, synchronized domains is attempting to
>address a very small subset of the aliasing problem, specifically
>linguistically/culturally identical albeit visually dissimilar
>strings that users expect to behave identically in the Fast Track IDN
>ccTLD program.

That's my understanding, too.  It's not a technical problem, it's a
political problem, countries such as China that use non-Roman
character sets want domain names entirely written in their own
language.  That's a perfectly reasonable thing to ask for, but as
we've seen in painful detail, there's no reasonable way to migrate
mechanically from DNS names in mixed ASCII and IDN to all IDN.

As far as I can tell (and I hope Kim corrects me if I'm wrong), ICANN
has no compliance plan for synchronized domains, nor any enforcement
plan other than perhaps a polite reminder if they get out of sync.  In
practice, this probably won't make matter, since I expect the most
likely sequence of events is that names that already have all but the
last component in IDN will just flip from .cn to .<china> or whatever.
There's no obvious incentive to make names not match, so it'll
probably work well enough. Other than trying to check for ways that
this plan would break the DNS for others, I don't see a role for us.

R's,
John

---

From: David Conrad <[email-masked]>
Date: Fri, 9 Apr 2010 11:46:17 -1000

Eric,

In my follow-up to Andrew's note, I tried to clarify.  Will try again.

> Could you explain to me what "applies only at the TLD level" means?

It means that if example.com decided to implement synchronized domains starting at the third level that they manage, ICANN would (of course) have no role.  The synchronized domains are a proposed solution to deal with a particular set of labels that originate at the TLD level.

That is, this isn't a generic solution to the domain aliasing problem I thought DNSEXT was looking into.

Apologies for the lack of clarity.

Regards,
-drc

---

From: Douglas Otis <[email-masked]>
Date: Fri, 09 Apr 2010 15:23:42 -0700

> Sorry, I was unclear.  The solution is not generic and applies only at the TLD level in the sense that it is a requirement imposed by ICANN on the registries and it is the registries' responsibilit…
John Klensin expressed a desire for a means to determine name bundles, 
such as tld-1, tld-2, and tld-3 represent the same TLD.  This would not 
scale, but there is a way for one domain to authorize any other domain 
in a scalable fashion.

Domains below TLD bundles would need to be cloned or synthesized using 
CNAMEs.  Cloning will represent added cost for domain holders to ensure 
unified mailboxes, purchase a bundle of certificates, etc.  To assist in 
that effort, one might imagine domains could contain meta-information 
describing a name bundle set.  This might require something similar to 
what Paul Vixie has described in:

http://tools.ietf.org/search/draft-vixie-dnsext-dnsshadow
> In theory, I suppose a domain name holder could apply this for the names they have registered, but I suspect they'd rather use DNAME.
DNAME does not offer a workable solution as this requires a non-aliased 
label in which to publish a single redirection.

There was draft by Jiankang YAO et al, to use BNAME as a means to 
synthesize CNAMEs from the BNAME onward.

http://tools.ietf.org/id/draft-yao-dnsext-bname

This copies the NS records, but neglects treatment for MX records which 
are not to use CNAME as targets.

Based upon advice given by a content delivery provider, tens of 
thousands of corporate domains now use a CNAME to locate an intermediate 
host in mail's journey to its final destination.  Only the final 
destination has a valid MX record.  John Klensin insisted a synthesis 
approach would be unacceptable as a result of the MX issue.  However, 
BNAME synthesis would help consolidate recognizable names and the 
certificates needed.
> No.  As I understand it, synchronized domains is attempting to address a very small subset of the aliasing problem, specifically linguistically/culturally identical albeit visually dissimilar strin…
IDNA2008 declares some domains as being illegal.  One could presume such 
domains would return NXDOMAIN rather than being aliased to a legal 
character-set that had been previously case-folded, as example.  
Depending upon how that might be resolved, the scope could be bigger 
than expected.
>> If the claim is that policy&  provisioning won't scale, then it'd be
> I would assume we'd want the same scaling properties as any other aspect of the DNS.  The scaling concerns I have is that synchronized domains requires verification that the trees are remaining synchronized.  For one or two trees, that might be feasible (depending on how much splay there is in the tree).  However, imagine thousands of synchronized domains.  I honestly can't believe this would actually work.\
>    
In the case of zone cloning, there would be increased overhead related 
to signatures being created during the cloning process, and a lower 
cache hit rate that would affect both client and server.  Whenever 
aliased domains have been referenced, clients would see a greater impact 
with CNAME synthesis.  One would therefore hope that normally the alias 
is displayed.

As far as obeying the rules, it would seem that only zone cloning can 
achieve this goal, but either approach could be made to work.

-Doug

---

From: Brian Dickson <[email-masked]>
Date: Fri, 9 Apr 2010 23:36:35 -0300

I think there is a bit of a log-jam in terms of local goals of the
groups which necessarily involved,
versus the potential global goal-set which has the possibility of
exceeding all local goals, with minimal
protocol change.

ICANN are concerned with the root and TLDs, but there ends their mandate.
Our WG needs clear requirements to avoid rat-holing.
The TLDs need to provision and serve whatever is mandated by ICANN.
DNS software vendors need RFCs to ensure interoperability.
And the registrants, particularly in the IDN space, need something of
real value,
especially beyond just the TLDs, to make it worth doing IDNs in the first place.

I think it would be a useful exercise to "proffer" solution "sets" -
slightly more abstract than
particular implementations or protocol-specific IDs, but which
associate a potential
set of goals, along with the set of restrictions presumed, and the
impact to protocol-level,
provisioning, and scoping the changes (e.g. along the lines of Paul
Vixies analysis
of which DNS parties are or are not impacted by the protocol changes).

Putting forward a set (possibly of size 0, 1, or other small integer)
and getting feedback from
the other groups, is what IMHO is needed to break the log-jam.

Being able to say, "Here is what we can do, please choose one" limits
our rat-holes, if we choose
to not offer rat-holes up as options. And, at the same time, if it is
easy to do something which provides
an "all of the above" solution, nearly trivially, and with changes
only to elements which were recently added,
the long-tail problem can mostly be factored out. (I am thinking of
DNSSEC validators as the impacted element,
as an example case - they're new, and changing them in ways that are
still backwards compatible to the current
rules, is likely to see rapid and complete uptake, among those who
already have validators deployed.)

It's a bit backwards, but if we have some things we know we can
deliver without great pains or efforts,
being able to ask "Is this what you were thinking? Or how about this?
Or this? Or none of the above?",
might make the conversation go faster and easier. And if we get
anything other than "none of the above",
as a consistent answer, then our part is as simple as saying, "Fine, we do so."

IMHO.

Brian

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sat, 10 Apr 2010 07:36:42 -0400

> ICANN are concerned with the root and TLDs, but there ends their mandate.

Please see rfc1591. In particular Section 3, parts 2 and 3.

> The TLDs need to provision and serve whatever is mandated by ICANN.

ICANN is a California domiciled 501(c)(3) corporation which enters
into contracts with what it calls "registry operators" (aka
"contracted parties"). Contracts do not contain "mandates", unlike
regulations. ICANN is not a regulatory body, authorized by some
specific enabling legislation.

In broad terms, ICANN has contractual relationships with some (about
20) "registry operators" (far fewer actually independent "registry
backend service providers", seven I think, pre-coffee), and memorada
with some other "registry operators".

> especially beyond just the TLDs, to make it worth doing IDNs in the first place.

The overwhelming bulk of that particular work has already been done,
first in the IDNA WG, completed seven years ago, and more recently in
the IDNAbis WG, recently completed.

The problem statement here is either an administrative convenience
statement for arbitrary similarity, or the edge cases arising from a
very limited number of equivalent (in some sense) code points in the
third-party repertoire, or the specific case of intelligibility and
therefore equivalence (in some sense) of arbitrary substitution of
code points in two sub-repertoires, commonly denoted "Simplified" and
"Traditional" Chinese (aka "SC/TC equivalence").

The utility of non-LDH labels, even if bootstring encoded from an LDH
alphabet, and available only through presentation, does not depend on
any work this group can conceivably take.

Eric

---

From: Brian Dickson <[email-masked]>
Date: Sat, 10 Apr 2010 13:04:00 -0300

I think we are (all) in agreement, to some degree.

Here's what I'm trying to say, obviously not clearly enough to date:

There are currently mechanisms with limited ability to "deliver"
multiple names for the same data: CNAME and DNAME.
Those are limited mechanisms, which do not handle all cases.
And also, quite importantly, they do not in and of themselves support
DNSSEC validation without additional work by the Signer.

There are also brute-force means by which multiple names can be
enumerated, which does not use any DNS protocol elements.
Brute force, however, puts the burden on maintaining parallel zones on
the registrant.

The problem is scaling.

What we don't yet have, in terms of problem statement, is an answer to
what the scaling requirements are.

If the answer is "two", then likely no protocol work is needed. Two
scales nicely. I do not believe "two" is the answer, however.

If, on the other hand, the answer is P (as in P vs NP), polynomial
scaling, then I think we need to contemplate providing solutions in
the WG.

An example of polynomial is the expansion of regular expressions of the form:
{$A|$B|$C|...}
where
$A == $x.{$a|$b|$c}.{$d|$e}
$B == {$f|$g}.{$h|$i}.{$j|$k}
$C == $y.{$l|$m}.$z
and so on.

We haven't *yet* been given that as a requirement, at least from ICANN
or other groups.

However, if the real world users, i.e. registrants and end-users,
expect to be able
to refer to things by such multitudes of names, and get "the same" answers,
then scalability issues suggest having the technological means of
keeping the zones
completely identical is a firm requirement. And I believe that means
DNS protocol work,
either directly to do this, or indirectly to support non-DNS
implementations, e.g. literally
by means of indirection.

I also believe that *use* of DNS protocol technology envisioned needs
to be optional, and that
the brute force and existing CNAME/DNAME solutions all need to be
allowed and supported.

One size does not fit all.

And the sizes currently available do not include XXL, which is the real problem.

Brian

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sat, 10 Apr 2010 12:44:59 -0400

> scaling, then I think we need to contemplate providing solutions in

It is traditional to speak of "binomial explosion" when discussing the
issues involved in label formation using characters which are
interchangeable in the SC and TC character repertoires (overlooking
nuances). I'm not a native reader of Chinese, it is possible to find
words (identifiers) with up to 8 characters, and, as in German,
agglomerate madly to make longer words (identifiers) ...

However, labels of length greater than some number less than 8, for
which the registry (or registries, recalling the circa-2000 level of
cooperation between the CDNC ccTLD registries) offer "similarity",
ventures into self-inflicted injury territory.

So, larger than 2, less than P.

Eric

---

From: Paul Vixie <[email-masked]>
Date: Sat, 10 Apr 2010 16:57:53 +0000

> Date: Sat, 10 Apr 2010 13:04:00 -0300
> From: Brian Dickson <[email-masked]>
> ...

this is because our hands are tied by the installed base.  if we were willing
to upgrade all stub and recursive resolvers and all applications, the rest
would be trivial :-).

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sat, 10 Apr 2010 13:27:30 -0400

> to upgrade all stub and recursive resolvers and all applications, the rest

I'll have a double shot of whatever he's having.

---

From: Doug Barton <[email-masked]>
Date: Sat, 10 Apr 2010 12:19:41 -0700

Andrew,

What was the result of your request for comments on the ietf@ list on
this topic? If the results have already been published and I missed
them, apologies, a pointer will suffice.

Doug

--

---

From: "George Barwood" <[email-masked]>
Date: Sun, 11 Apr 2010 19:29:57 +0100

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 09, 2010 3:51 PM
Subject: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work

> that cannot be accommodated in ICANN's plan.

I should say first that I am not very clear on the issue.

I don't think work is strictly necessary, but it may still be desirable.

My simplistic intuition is that if .CN and .中国 and .中國 are 
aliases, it may be worthwhile to represent this information in the DNS.

This should allow caching resolvers to need to store only one copy of
the sub-tree, provided they have support for whatever mechanism is defined
to communicate the alias information.

It may also have other benefits, I think that finding resolving aliases at the
earliest possible time makes good sense.

It seems that the existing alias mechanisms are not satisfactory, therefore
defining a new resource record type capable of expressing the alias
information would be sensible.

Best regards,
George Barwood

---

From: Niall O'Reilly <[email-masked]>
Date: Sun, 11 Apr 2010 22:59:21 +0100

>     2.  Whether there is any protocol work that DNSEXT should do in

	[...]

> could be addressed.  Are others in agreement with that? 

	Yes, but a subsequent message from Kim Davies clarifies this as 
	intended to be an interim position.

> If so, then

	This doesn't follow, because it's a general conclusion drawn
	from a particular case.  ICANN is just one of the players on 
	the DNS stage.  

> that cannot be accommodated in ICANN's plan.

	I believe that ICANN's plan is only of marginal relevance to 
	the questions mentioned at (1) and (2) above.  At most, ICANN's
	plan may give rise to an additional opportunity to avail of any
	solution which may emerge for question (1).  On the other hand, 
	the question arises already in existing ccTLD operations, prior 
	to, and independently of, the implementation of ICANN's plan.

	Possible use cases which would be served "by some kind of 
	additional aliasing mechanism for the DNS" seem to me to be 
	well covered in Paul Vixie's slide-set for the interim audio 
	meeting held on 16 Feb 2010, and (very usefully) include an 
	example which is not related to variant IDNA strings.

	Drafts (BNAME and SHADOW) are already available addressing
	these suggested use cases.  It seems to me that it would be 
	useful for a number of those with a material interest in the
	outcome to make clear statements on this list (as some have 
	already done privately) in respect of the following questions:

	What their interest is;
	In what way existing aliasing (replication or indirection)
	  mechanisms are (or appear to be) inadequate for them;
	What size of "equivalence cluster" they anticipate needing
	  respectively for a single label and for an FQDN;
	Whether (with reasons) SHADOW appears a useful solution;
	Whether (with reasons) BNAME appears a useful solution.

	This should give a clear impression of what benefit, if any,
	might flow from any further work on this topic.

	So far, the discussion on this list of this topic seems to
	have been dominated by people either whose native language
	is English, or for whom the Latin alphabet is a close enough
	approximation to meeting their needs.  Without meaning either 
	to impugn anyone's acquired expertise or to play down the
	value of proxy advocacy, I suggest that two observations are 
	pertinent: first, that such a group is likely not best 
	qualified by experience to articulate the problem;  secondly, 
	that dominance by such a group may tend to marginalize those 
	who are so qualified.

	If no-one speaks up, I'm inclined to agree with Andrew that
	"it would appear that the WG does not need to consider this 
	topic any more as a possible work item", but not because of
	anything to do with ICANN's plan.

	I hope this helps.

	Niall O'Reilly

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 11 Apr 2010 23:21:59 +0000

> 	intended to be an interim position.

There's also now a blog post at blog.icann.org that reiterates (more
or less) what Kim said here.

> 	from a particular case.  ICANN is just one of the players on 

All other issues raised by the specific ICANN consultation aside (and
there are plenty) I think this is the key observation for purposes of
this WG and its need to determine what work might lie before in
defining and operationalizing what "the same" might mean in the DNS.

ICANN, as the operator of the IANA, is responsible for a key registry,
the root zone. However, it is not responsible for all registries, and
even if a loose correspondence between separate delegations meets
ICANN's need for "the same" in terms of behavior for some or all of
its delegations, it's quite possible that other registries will need
different behavior obtained by different means-- not inconsistent with
ICANN's requirements, whatever they are, but still subject to
additional constraints arising from additional requirements. (It's a
common situation in registry policy and operations that the operator
of a child domain will have constraints and needs to which the parent
is not subject, and there's no reason to think it won't happen here.)

> 	anything to do with ICANN's plan.

I think the part of your message I elided recaps the discussions the
WG has had, including the conclusions previously reached and the
drafts already offered. I agree with you that ICANN's inferred
position, even if actually held there, doesn't change where the WG
stands.

However, as above, ICANN is an important operator that appears to have
an interest in the idea of expressing "aliasing" or "sameness" in the
DNS. Accordingly, I look forward to contributions from ICANN staff to
defining what can and can't be done with separate delegations in this
area and how additional requirements may be clarified and met.

Suzanne
(speaking for myself)

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sun, 11 Apr 2010 19:55:50 -0400

>     intended to be an interim position.

While I appreciate Kim's efforts to clarify, 1) the Board level
process which created the unusual sequence of drafts we are offered is
without precident [the key here if interested is absence of Board
working group process, generating a text of record before its authors
were formally constituted], and 2) Staff comments in a bottom-up,
multi-stakeholder policy making organization are simply Staff
comments, and 3) the issue nexii (note the plural) are with the Han,
Cyrillic, and Arabic Scripts authorities, and not necessarily with the
change control authorities for the IANA root.

I agree with Kim that the best interpretation of a problematic
document and process, and situation, attempting a problem statement,
is that it is transitional.

>     from a particular case.  ICANN is just one of the players on     the
> DNS stage. 

While true, that observation doesn't get to either the necessary
agency, if it is not ICANN, nor to the problem statement, and
therefore the mechanism(s) which might be adequate.

>     I believe that ICANN's plan is only of marginal relevance to     the
> questions mentioned at (1) and (2) above. ...

Agree. ICANN's request is quite limited as to where similarity exists,
and what similarity means. On the other hand, prior to the rather
widespread belief among policy people at ICANN Seoul that DNAME was
sufficient, the question really hadn't been put to this WG, unless I
was asleep, which could be the case.

That is to say, for what ever reason, it is unlikely that we would be
here, now, absent the post-Seoul policy consultation(s), though we
could be "here" at some later point, without external impulse.

... At most, ICANN's
>     to, and independently of, the implementation of ICANN's plan.

While possible true, in the sense that the Greek tonos issue was known
here, if you really want to put a flaming stake through the heart of
the person ultimately responsible for there being an issue, I suggest
the author of the "one script per" allocation model, from the
Anglophone head of the ccNSO. This absurdity leads some to calling
SC/TC a "variant" issue, to disguise two scripts, and utter
indifference to the 12 scripts (and 22 languages) for India. It does
however work for most of the Arabic Script issues.

>     additional aliasing mechanism for the DNS" seem to me to be     well
> covered in Paul Vixie's slide-set for the interim audio     meeting held
> on 16 Feb 2010, and (very usefully) include an     example which is not
> related to variant IDNA strings.

Paul's not the only one who's suggested that alias has rationals other
than label inter-intelligibly out of a sequence of code points
admitting one or more alternative code points in the constructed string.

>     already done privately) in respect of the following questions:

BNAME has the unusual property that it precludes delegation. This has
side effects.

>       respectively for a single label and for an FQDN;

Please see my prior note.

>     approximation to meeting their needs....

This was present when the IDNA WG rejected the CNDC proposal for
intermediate tables, to rectify errors made in Han Unification, by the
authors of the repertoire, in 2003.

  ... Without meaning either     to
> impugn anyone's acquired expertise or to play down the
>     pertinent: first, that such a group is likely not best     qualified
> by experience to articulate the problem;  secondly,     that dominance
> by such a group may tend to marginalize those     who are so qualified.

I will agree that error arising out of lack of subject matter
expertise took place in 2003, and in 2009, and more importantly, prior
to 2003, but in another organization. However, the locus of policy
formation is, as you observe partially correctly, only partially
defined, and therefore even if this working group were formed of
"cloud ascended sages", it could not be completely correct, only
partially so. Additionally, there are no restraints  on CNNIC
technical staff, and other CDNC and JET technical staff, from full
participation, now that Anaheim and the visa limitation problem is
finally behind us.

>     anything to do with ICANN's plan.

We all have our views.

I'm partial to graph theory as a motivation, and DNSSEC or proof
properties generally as a pervasive recursive descent problem.

Eric

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 12 Apr 2010 10:48:15 +0200

On 12 apr 2010, at 01.21, Suzanne Woolf wrote:

> It's a
> is not subject, and there's no reason to think it won't happen here.

Correct, but, what troubles me is the following text in the plan for implementation from ICANN. I.e. this is what ICANN requires from the applicant (see http://icann.org/en/topics/idn/fast-track/proposed-plan-synchronized-idn-cctlds-22mar10-en.pdf, page 4):

> 2.	Documentation of adequate and verifiable procedures that the requester will use to enable convergence at every level of the IDN ccTLD, including information about the steps the requester will take to remove any divergence that might occur. Such documentation must include descriptions of the registry’s plans to:
> 
> 2.1. Enable through a technical mechanism that synchronized domains resolve to the same address or value in each level of the DNS tree;
> 
> 2.2 Require in a registration policy that synchronized domains resolve to the same address or value in each level of the DNS tree;

> 
> 2.3 Ensure compliance with the registration policy for synchronized domains;
> 
> 2.4 Provide timely reports on synchronized IDN ccTLD experiences following the delegation and implementation of the synchronized IDN ccTLDs;
> 
> 2.5 Migrate in a safe, stable and timely manner to improved technical standard for the delegation and management of synchronized IDN ccTLDs if established, and applicable for such delegations.

This text must be changed, at least from my point of view, for the text in what Kim writes, and the Q&A, and the blog, to be able to be true. The text implies to me that ICANN requires the applicant to not only show that they will do policing, but also how they will do it, and that it is doing it. And that it reports to ICANN about it. Now, this in turn imply that ICANN will approve/disapprove what the applicant is suggesting, and that ICANN might say something if the registry is not doing "good enough job".

My personal view is that *if* some registry want to play around with policies, do bundling etc, let them do it. But do not think the parent that approve the delegations can enforce something "in each level of the DNS tree". That implies a responsibility (on ICANN ultimately) that should not exist. Not even implicitly.

   Patrik

---

From: Brian Dickson <[email-masked]>
Date: Mon, 12 Apr 2010 08:04:42 -0300

Without going into the policy issue(s) (as they're not directly a WG
issue, IMHO),
I'd say the proposed plan does help inform the requirements for sameness.

It seems to me, that the requirements (valid or not) heavily favor
mechanisms that provide the semantic of "hard link" rather than
mechanisms that do "parallel provisioning".

I'd say this is especially so in the context of DNSSEC (signatures
and/or validation).

Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 12 Apr 2010 12:23:23 -0400

> them, apologies, a pointer will suffice.

I did not receive any comments that were not either on that list or on
namedroppers, save some comments by John Klensin, who told me that he
would not, under any circumstances, re-join namedroppers.  John's
comments were substantially the same as those he made at the mic in
the Anaheim meeting.

Best,

A

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

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 12 Apr 2010 12:44:04 -0400

> 	from a particular case.  ICANN is just one of the players on 	the DNS 
> stage.  

That is true, but I think I owe the WG a clearer version of the
argument against additional work.  So here it is.

The WG currently has no work item here.  What we have been doing is
investigating whether there is work that we might do to make whatever
the problem is (and we don't know exactly what that is, but it has
something to do with making names aliases for one another) less acute.

As WG co-chair, one of my jobs is to determine whether in fact we have
work to do here -- i.e. whether there is a new deliverable that shows
up on our charter and results in protocol changes or clarifications.
I emphasise again that I am still working through that.  One way that
I work through such things is to make the strongest arguments I can
for a given case, and see whether there are persuasive
counter-arguments.

In this case, I am attempting to make the strongest argument I can
that we have no work to do.

Conclusion: The DNSEXT WG should not do any protocol work on the topic
of aliases in the DNS.

Premise 1:  The WG should only make additions or changes to the
DNS protocol when that is required.

Premise 1.1:  The DNS is an old and mature protocol with a large
installed base.

Premise 1.2:  Old, mature protocols with large installed bases are
expensive to change.

Premise 1.3:  Previous DNS extensions and additions have taken a long
time to be deployed.

Premise 1.4: Additional mechanisms in a protocol add complexity, which
is to be avoided.

Premise 2: Work on aliases in the DNS is not required.

Premise 2.1: Any aliasing needed is possible to do using existing
provisioning and contractual arrangements.

Premise 2.1.1: ICANN is planning to do aliasing by provisioning and
contractual relationships, and will require such mechanisms to work
all the way down the tree.

Premise 1.1 and 1.2 require conjunction, so if the two premises are
not both true, then they do not provide good support for premise 1.
Premise 1.3 supports premise 1 independently.

Premise 1 has the form A only if B (changes only if required).
Premise 2 denies the consequent of premise 1, and so the argument is
formally valid: if A then B (== A only if B), not B, therefore not A.

So far, the primary counter-arguments have come in three forms.  One
is that 2.1.1 is false because the ICANN plan is of limited scope.  I
don't know that I buy that limitation: there is no formal limitation
of scope in the existing plan, so in fact there's nothing to prevent
the current plans from resulting in many additional delegations.  The
only restriction is that users are supposed to be not surprised.
Unless ICANN has developed a great deal of user interface expertise
while I wasn't looking, I don't think it's really competent to
evaluate that; so there's just no formal choke on what the plan needs
to be able to cope with.  (A variant of this objection is that the
ICANN plan actually won't scale, no matter what ICANN is saying
publicly.)

The second is that 2.1 is false because there are cases not covered by
the ICANN plan.  I'm still waiting for details here.  Because ICANN's
plan is transitive all the way down the tree, this is at least doubtful.

The third is really a denial of premise 1.4: that premise 1.4 is too
broad, and that limited additions to the DNS do no harm.

This is my reading of the discussion and arguments so far.  If I've
missed a point someone made, I apologise.  (It would be good to hit me
with a clue-stick.)

> 	approximation to meeting their needs.  Without meaning either 	to impugn 
> anyone's acquired expertise or to play down the
> 	pertinent: first, that such a group is likely not best 	qualified by 
> experience to articulate the problem;  secondly, 	that dominance by such 
> a group may tend to marginalize those 	who are so qualified.

I think this is an excellent observation.  If there are needs that are
unrelated to language issues, this would also be a good time to bring
them up.

Best regards,

A

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

---

From: Dmitry Burkov <[email-masked]>
Date: Mon, 12 Apr 2010 21:13:50 +0400

> comments were substantially the same as those he made at the mic in
I missed this reference on the list.
John clearly expressed his position
http://forum.icann.org/lists/sync-idn-cctlds/msg00004.html

Dima

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Apr 2010 17:16:27 +0000

> Date: Mon, 12 Apr 2010 12:44:04 -0400
> From: Andrew Sullivan <[email-masked]>
> 

i think i disagree with your conclusion on the following basi.

basis 1. aliasing has potential customers other than icann.
basis 2. icann has asked for some kind of standardized automation.
basis 3. dname is crippled by not affecting its ownername.
basis 4. cname is crippled by not affecting its children.
basis 5. parallel delegations would benefit from standardized automation.

on the basis of #3 and #4 above, i think that BNAME should be adopted.

on the basis of #5 above, i think that SHADOW should be adopted.

on the basis of #1 and #2 above, i don't think that icann's Q&A document
takes any of this off the table.

i am willing to do authorship and editorial work to support BNAME & SHADOW,
assuming that others here are willing to review the drafts.  if all that is
in place, then we should proceed with drafting.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Apr 2010 19:11:06 +0000

> From: "George Barwood" <[email-masked]>
> Date: Mon, 12 Apr 2010 20:05:32 +0100
> 
> The problem with BNAME is I think that DNSSEC validators must perform
> special processing (similar to DNAME), or validation errors will occur -
> the CNAME records will not validate without special processing.
> 
> Thus it is not backward compatible with already deployed validating
> resolvers*

security complicates things, i see what you mean.  unless we can synthesize
the RRSIG that covers the synthesized CNAME, this would be a real problem.

> One point that makes me uneasy is why DNAME was not defined to redirect
> itself.
> 
> Was there a reason for this?

we wanted to be able to use DNAME at zone apexes, and the rule against CNAME
and other data sharing an owner name made it really complicated.  the use
case for DNAME (which has disappeared) was bit string label PTR RRs, for
which this mattered.

> * A possible alternative that IS backwards compatible might be to return
> the normal non-BNAME answer, and supply the BNAME as additional
> information ( say in the authority section ) that can be used by BNAME
> aware clients.  Was this considered? ( Just a wild idea - I have not
> thought for a long while on this ).

since the non-BNAME answer might be out of zone, this isn't an approach.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Apr 2010 21:34:58 +0000

> Date: Mon, 12 Apr 2010 21:50:27 +0100
> 
> By "normal" I mean the answer which would be given if BNAME were not
> invented, which would usually be a referral.

i think it would usually be an NXDOMAIN.

> ... I suggest that $INCLUDE is good enough for producing copies of zones,
> and the objective should be to minimize cache memory requirements for
> state-of-the-art resolvers ( especially in view of the larger requirement
> due to DNSSEC ).

as a side note, i've been cautious in my SHADOW work to only speak in terms
of zone transfers, and not in master file format or directives there (such
as $INCLUDE).  many authority DNS providers do not have anything like master
file format and just use an external database (SQL) or internal database (BDB)
for zone storage, and some only allow changes through the external database
interface or through RFC 2136 UPDATE commands.  others allow one-time import
of "master file format" (which they sometimes mistakenly call "BIND format").

while there are also some authority implementations who do not use zone
transfers to synchronize their authority servers, everybody seems to offer
zone transfers (at least AXFR and often also IXFR).  so, when i described
mirroring in the SHADOW proposal, i described it in those terms.  i guess
this means i don't think it's realistic to defend "master file format" as a
part of the DNS specification, but if so, consider that it does not appear
"on the wire" and as such there is no possible interoperability test for it.
(would "$INCLUDE DKA0:[SYS.DATA]FILE.DAT" fail such a test even though it
would work fine on the VAX/VMS server that the master file came from?)

> There is also a question of whether applications should re-write domain
> names based on BNAME records before submitting requests to web servers
> etc. That avoids the necessity of issuing multiple SSL certificates for
> these domains in the long run, but possibly raises delicate security
> questions.

it's also a change to the application, which i specifically ruled out in my
own work.  if we're going to make a material difference to DNS within our
own lifetimes we're not going to be changing anything except the zone's own
authority servers and perhaps the zone's ancestor's authority servers.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Apr 2010 10:02:04 +1000

In message <19005DAF043444A092106B6CDB1EBA25@localhost>, "George Barwood" writes
:
> special processing (similar to DNAME), or validation errors will occur - the CNAME
> records will not validate without special processing.
> 
> Thus it is not backward compatible with already deployed validating resolvers*

So what?  We know how to deal with this.

Use the DNSSEC algorithm to signal that there may be a BNAME in the
zone the same way as we use the DNSSEC algorithm to signal that
there may be NSEC3 records in the zone.
 
> One point that makes me uneasy is why DNAME was not defined to redirect itself.
> 

Yes.  The current behaviour allows companies to alias zones without involving
the parent zone.

> * A possible alternative that IS backwards compatible might be to return the
> normal non-BNAME answer, and supply the BNAME as additional information
> ( say in the authority section ) that can be used by BNAME aware clients.
> Was this considered? ( Just a wild idea - I have not thought for a long while on this ).

You return a CNAME or a BNAME, never both for the same qname, based
on whether the client signals BNAME understanding (EDNS option).

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: John Levine <[email-masked]>
Date: 13 Apr 2010 04:14:39 -0000

>basis 5. parallel delegations would benefit from standardized automation.

I'm not at all sure this is true.  ICANN's current plan says "not
surprising" rather than "same bits".  It is possible that ICANN is
wrong, and people would prefer the same bits, but it is also quite
possible that they are right, and providing the same bits doesn't
solve a big enough problem to be worth new mechanism.

R's,
John

---

From: "George Barwood" <[email-masked]>
Date: Tue, 13 Apr 2010 07:04:35 +0100

----- Original Message ----- 
From: "Mark Andrews" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Paul Vixie" <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 13, 2010 1:02 AM
Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work 

> there may be NSEC3 records in the zone.

The "so what" is that it will be unsafe to deploy BNAME as defined in the current draft
because it can cause validation errors with validating resolvers that have not been updated
to support BNAME. Maybe there are so few validating resolvers currently deployed that
this is not a problem, but I think it at least needs consideration.

> Yes.  The current behaviour allows companies to alias zones without involving

Thanks, I see. I wonder if DNAME, while not perfect, is sufficient to solve
most of the problem without updating the standard. Probably going over old ground here.
 
> on whether the client signals BNAME understanding (EDNS option).

I don't think that helps : a validating resolver that doesn't support BNAME will still
fail because the CNAME record is not signed ( assuming DNSSEC has been fully deployed ).

---

From: Andreas Gustafsson <[email-masked]>
Date: Tue, 13 Apr 2010 12:17:04 +0300

Paul Vixie wrote:
> of zone transfers, and not in master file format or directives there

I don't think you have, because draft-vixie-dnsext-dnsshadow-00 makes
a distinction between "relative" and "fully qualified" names, and that
distinction only exists in master files and not in zone transfers.
Since names in zone transfers are encoded in the DNS wire format, they
are always effectively fully qualified.

In particular, the technique describe in the last sentence of the
following paragraph can't be applied to zone transfer data:

   2.2.1. For example, if an Amber zone at VIX.COM has a master file
   which describe an apex MX RR with an unqualified MX EXCHANGE domain
   name such as MAIL1, then the MX target in the Amber zone will be
   MAIL1.VIX.COM.  A Shadow of this zone whose apex is VIXIE.SF.CA.US
   will show this MX EXCHANGE as MAIL1.VIXIE.SF.CA.US.  This may require
   configuration changes to supporting applications such as SMTP
   servers.  This behaviour can be prevented by using fully qualified
   names wherever the name of the Amber zone, and not the name of its
   various Shadow zones, is to be published in the RDATA.

-- 
Andreas Gustafsson, [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Apr 2010 20:52:29 +1000

In message <8DA2E211CC484529B2BC222063C45A03@localhost>, "George Barwood" write
> this is not a problem, but I think it at least needs consideration.

Has the draft passed last call?  How to deal with this has been
described multiple times.  We don't need to write it into the draft
while we are still discussing the basic BNAME concept.  We know we can
make it work.

> most of the problem without updating the standard. Probably going over old

Indeed.

> fail because the CNAME record is not signed ( assuming DNSSEC has been fully deployed ).

Apply the rules above and a validating resolver that doesn't
understand BNAME will always treat the zone containing the BNAME
as insecure as it won't understand the algorithm.  A BNAME aware
resolver will get the records and any relevent signatures provided
there is a BNAME aware path between it and the authoritative server.

Mark

---

From: Florian Weimer <[email-masked]>
Date: Tue, 13 Apr 2010 12:57:50 +0200

> that cannot be accommodated in ICANN's plan.

When submitting a message, an email client needs to know what type of
IDN transofrmation to apply, to avoid to do something to the addresses
which is lossy, so that the server still can translate it to something
expected by the network (if any such translation is necessary).

This needs protocol support, but since email submission does not
generally have access to DNS information, a protocol which is purely
DNS-based cannot provide a solution.  Any attempt to deal with this in
DNS alone (whether through protocol extensions or through clever
provisioning) will eventually lead to complaints that some domains do
not work right, and further protocol work outside DNS.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 13 Apr 2010 11:15:48 -0300

In addition to the below comments from Paul, there are other reasons
to consider adding to the WG charter, and additional ways in which
some or all of the problems can be resolved.

I am not convinced that limiting the proposals here to already-written
drafts, or to a specific number of new drafts (e.g. 1 or 2), is
strictly necessary. If there is a third way, which has enough
different about it to differentiate it from the other methods, and
presuming the three ways are independent (neither inter-dependent nor
mutually exclusive in any aspect), all three ways should be
considered.

The additional reason to consider adding to the WG charter is:
- DNSSEC validation of "alias" zones through any of the aliases
 -- this would change some of the validation rules, but the benefit
would be the ability to secure zones whose parent(s) are not currently
signed
 -- e.g. if foo.example.com is AKA foo.example.cctld1, and com and
example.com are signed, but cctld1 is not, then having DNSSEC
validation via aliases would mean that it would be possible for foo to
be validated regardless of which name it was known by (example.com or
example.cctld1).

The third way is to merely support DNSSEC validation using modified
rules, and to handle the aliases through parallel delegations (NS and
DS), with a much smaller subset of DNSKEYs (and signers) than the full
set of aliases, including the possibility of just one signer (parent
alias).

With this way, the parallelism itself can be handed by metadata on the
authority server(s).

The linkage between the zone identity and zone contents is built by
the authority server from its metadata.
The linkages can be relatively trivially made N:1 instead of 1:1 (name
to zone-content), on most implementations.
And the implementations are then free to do the needed stuff for
handling zone updates/transfers based on the multiplicity of zones.

Changing metadata and in-server behavior does not change anything on
the wire, which is why it is mostly non-WG stuff, other than
describing to implementers what the big idea is - suitable for putting
in a nice Appendix to a small ID on the DNSSEC validation rule
changes.

I'd be happy to write this up in a draft, if there is WG interest in
the proposal, and thus would be interested in hearing from folks
willing to review it.

Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 14 Apr 2010 00:26:55 +1000

In message <1A3CBDCF9402473A930431B4880CD5EC@localhost>, "George Barwood" write
s:
> So when a BNAME is placed in the root zone for .CN, the previously secure
> root zone becomes insecure for all resolvers that have not been updated.

Yes.
 
> I'm not sure that is better than simply having validation failures on names
> that depend on BNAME.

It's much better than having lookups fail because of validation failures.
 
> Still, maybe this is getting too far ahead. I'm stopping here.

By the time BNAME is added to the root zone there will be multi-vendor
support for it.  It won't be deployed in a vacum.

Mark

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 13 Apr 2010 17:11:21 +0200

> in place, then we should proceed with drafting.

I am signing up to this.

   Patrik

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 13 Apr 2010 11:45:02 -0400

>> in place, then we should proceed with drafting.

Ditto.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Apr 2010 16:48:14 +0000

> Date: Tue, 13 Apr 2010 12:17:04 +0300
> From: Andreas Gustafsson <[email-masked]>
> 
> Paul Vixie wrote:
> > ..., i've been cautious in my SHADOW work to only speak in terms of
> > zone transfers, and not in master file format or directives there ...
> 

agreed.  this is an open issue, and i spoke (quoted above) too glibly.

> following paragraph can't be applied to zone transfer data:

see also:

4. Open Issues

   4.1. Using a different default origin and then not touching fully-
   qualified names is weak.  It plays especially poorly with fully
   dynamic zone content or database back ends.  We either need to tail-
   replace the Amber apex with each Shadow apex, or we need to add new
   signalling somehow.

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Wed, 21 Apr 2010 12:08:45 +0300

Dear Niall, Dear Andrew, Dear DNSEXT members,

I am sorry I have not been able to answer this email sooner.

I noticed by reading this that the xNAME discussion has taken a slippery
road to oblivion but for the wrong reasons.

I am happy our request for xNAME has found some allies due to the ICANN
request but in reality we are talking about issues that are close but not
the same. I am pretty sure nobody will ever wish to set up an email account
of the type mail@tld1 and wish to make it operative for mail@tld2. If you do
not face such a problem then why not using the DNAME for this equality
issue?

However, this is not the case if you discuss domain names under a TLD. If
there where two ways to spell shinkuro.com, both of them correct, would
Andrew wish to receive all of his emails correctly? I believe he would.

In this case you have to set up a mechanism that redirects all emails to the
email he considers the correct one. This could happen by setting up the same
email in each domain. What if this was the case for each email account of a
company and you had four ways of typing the company domain name, each one of
them correct, depending on character case or set? What if this was the case
for the domain name itself in the http protocol?

The user experience is significant if you wish the IDNs to move forward in
each language. It would be a great benefit if this equality mechanism was
set up in the DNS because it is really needed. It is the same need that
created DNAME, which in reality is a sub-mechanism of our request. We would
like DNAME to start right from the top, as it was discussed before(a
mechanism that operates like DNAME+CNAME from the first level of equality
and below that).

Please do not consider this discussion over because ICANNs request for TLD
equality could easily be bypassed by proposing DNAME as a solution. The
DNAME option is not enough for our ccTLD needs.

Kind Regards,

Vaggelis Segredakis

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Niall O'Reilly
Sent: Monday, April 12, 2010 12:59 AM
To: Andrew Sullivan
Cc: [email-masked]; Niall O'Reilly
Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias
maybe-work

	[...]

	What their interest is;

	I hope this helps.

	Niall O'Reilly

---

From: "YAO Jiankang" <[email-masked]>
Date: Wed, 21 Apr 2010 17:30:45 +0800

+1

even if  TLD does not want "xname",  the 2nd level domain name will want it, the 3rd level and more will need it.
"xname" is a general solution for all levels' domain names.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Apr 2010 10:03:08 -0400

> Andrew wish to receive all of his emails correctly? I believe he would.

But the BNAME proposal, as written, wouldn't allow this either.  That
is, if you had (some.label.tld BNAME other.label.tld), then you could
not use some.label.tld as the target of an MX record, any more than
you'd be allowed to do that with a CNAME.  BNAME clearly does not
solve the "mail server issue" for aliasing any more than CNAME does.

> mechanism that operates like DNAME+CNAME from the first level of equality

Given the three types of redirection that I previously outlined, which
of them (and to what extent) do you think the BNAME proposal solves?
To remind, I offered these three candidates (see
http://ops.ietf.org/lists/namedroppers/namedroppers.2010/msg00890.html).
I repeat what I previously wrote, with a modification to avoid this
ratholing into a question about TLDs.  It's fully generalizable:

 Suppose that we have [name1] and [name2], and they're supposed to be
 equivalent.  These names may be made of more than one label.  [name1]
 comes from one repetoire of Unicode characters.  Call it range1.
 [name2] comes from another repetoire of Unicode characters.  Call it
 range2.  The only restriction is that range1 and range2 have at least
 one character that differs between them (they're not equivalent sets.
 In the unlikely event that any people who know about writing systems
 are reading this, I understand that this simplifying assumption is
 already really bad.  Never mind that).  Now, suppose we have any sets
 of labels, each of which is either in range1 (symbolized r1) or
 range2 (symbolized r2).  Which of the following behaviours is
 desired:

         a.  Should DNS names in the zones underneath the two
         synchronized zones be exactly (bit-for-bit) equivalent to one
         another?  For example, for a fully qualified domain name of
         the form r1.r1.[name1], must there always and only be a
         synchronized entry r1.r1.[name2]?

         b.  Should all and every label under [name1] be expressed in LE1
         and all and every label under TLD2 be expressed in [name2]?  For
         example, for a fully qualified domain of the form r1.r1.[name1]
         must there always and only be a synchronized entry
         r2.r2.[name2]?

         c.  Should every label at every level of the DNS be expressed
         in both LE1 and LE2 (the combinatorial case)?  For example,
         for a fully qualified domain name of the form
         r1.r1.r1.[name1], would it be necessary also to have
         r1.r1.r1.[name2], r2.r1.r1.[name2], r2.r2.r1.[name2,
         r2.r2.r2.[name2], r1.r2.r2.[name2], and so on?

My understanding of the BNAME proposal is that it will work fine for
(a) and (c) but not (b), that for (c) it requires no less work than
just using DNAME except that for DNAME you also need an A record at
[name1] and [name2] for every DNAME, and that exactly one of the
alternative trees will be allowed as a target for MX records.  Is that
your reading as well?

Best,

A

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

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 21 Apr 2010 17:45:12 +0100

Fragmentary replies follow, each with a different subject header.
	[Scary: maybe I'm channeling Jim? 8-)]

	I'll try to be brief and candid.  
	Please don't infer any disrespect.

> solve the "mail server issue" for aliasing any more than CNAME does.

	The "mail server issue" is a non-issue.

	Owner names matter; they're visible to end-users.

	MX targets shouldn't matter; they're for zone admins
	and mail-service admins to worry about.  Likewise
	for the name used in an SMTP command.  BNAME may
	marginally raise the required-clue threshold for such
	people.  So what?

	Best regards,
	Niall O'Reilly

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Apr 2010 13:02:56 -0400

> 	marginally raise the required-clue threshold for such

So what is the mail problem?  

My impression was that the problem had to do with people mistakenly
setting up their mail under the _wrong_ domain, because they try to
set it up under their preferred spelling and not in the canonical
zone.  If that's not the problem, what is the problem?

It can't be that a CNAME target is not allowed to be the target domain
for mail, because §5.1 of RFC 5321 makes clear that it can be (and
what to do when encountering a CNAME there).  It might be that it's
sort of a pain to make multiple A & AAAA entries in multiple zones for
the target domain, if one were to use DNAME.  That would be a
compelling argument, except that to make BNAME work all resolvers for
MTAs in the world would need to be updated to understand BNAME _and_
RFC 5321 would need to be updated (by some other WG) to say what to do
with such cases.  This goal seems to me to be fantastically unlikely
within the next 10 years, which means that some other
provisioning-type workaround will be needed until then, and so we
might as well just work on the provisioning stuff and be done with it.

So I'm still not sure what the problem is the WG is asked to solve.

A

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Apr 2010 10:46:01 -0700

> not face such a problem then why not using the DNAME for this equality
DNAME and CNAME cannot coexist at the same node, and DNAME does not 
offer an alias for itself.  Names registered at either a TLD or SLD, can 
not include DNAME RRs, as this would inhibit delegations to other 
domains.  On the other hand, BNAME copies NS RRs into the alias, and 
will likely synthesize CNAMEs whenever a client indicates, through the 
lack of a new option, that it does not support a new BNAME paradigm.

Synthesized CNAMEs within MX RRs could cause a problem with some MTAs, 
which might depend upon non-aliased names to avoid mail loops or 
excessive overhead.  In today's email environments, CNAMEs as targets 
for border MTAs do not appear to cause significant issues, however John 
Klensin promised such a change will not be acceptable, nor is it clear 
how synthesized CNAMEs will be supported by DNSSEC.

The Shadow zone solution does not appear to suffer from these problems 
while also offering a means to provide "equivalent" domains.  John 
Klensin also suggested there was a need to determine the bundle members 
of equivalent domains.

While Paul said something different in this regard, it seems possible to 
request RRs at relative name boundaries within the shadow zone that 
could contain information aimed at facilitating the management of shadow 
zone replication, such as access control info, the name of the Amber 
zone, replication error hold-off.  Finding the Amber Zone name at the 
relative name boundary might provide a partial solution, however John 
did not explain what problem was needing solved with respect to the 
name-set.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Apr 2010 11:06:47 -0700

On 4/21/10 10:02 AM, Andrew Sullivan wrote:
> what to do when encountering a CNAME there).
Don't confuse using CNAME for a mail domain, as opposed to having CNAME 
as a target for the MX record.

-Doug

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 21 Apr 2010 19:29:35 +0100

As before, with intended brevity, candour, and respect ...

>  range2 (symbolized r2).  Which of the following behaviours is

	[suggestions a, b, and c are elided here]

	This question ("Which of the following ...") is a matter of 
	registry policy, whether that registry be ICANN, a TLD, or the 
	administrator of some deep subsidiary zone.  It's not the problem 
	we're looking for, and we should best avoid it.  Articulating, 
	supporting, and (even!) policing such policy is for the registry 
	concerned.  This WG need not concern itself with repertoires or 
	writing systems.  Such things belong in a different layer.  

	[Choosing a number for that layer is left
	 as an exercise for the reader. 8-)]

	An outcome of each such registry policy is that a requirement 
	arises to support a number of sets (equivalence classes, but
	that's not important just now) of administratively equivalent
	domain names.  Each such set has properties such as 
	multiplicity and fan-out.  The latter may have to be 
	considered at either or both (!) the label and zone levels.

	For a registry to deal with such a set of domain names, the
	first question is, how to do the provisioning.  The second is,
	how this can be simplified by adding sophistication to the
	protocol.  That's where this WG comes in: downstream of the
	black box which accepts names expressed in repertoires and
	writing systems, and produces clusters of equivalent names.

	Best regards,
	Niall O'Reilly

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 21 Apr 2010 11:40:22 -0700

On Wed, Apr 21, 2010 at 11:06 AM, Douglas Otis <[email-masked]> wrote:
> Don't confuse using CNAME for a mail domain, as opposed to having CNAME as a
> target for the MX record.

What's the big deal in supporting CNAME records in MX record targets?
The entire argument for not allowing MX records to point to CNAME
records is because it's not handled by additional section processing,
but aside from delegations, additional section processing is an
*optimization*.

Maybe they think the Internet will fall apart if this optimization
wasn't available, but a huge number of domains use third-party mail
hosting providers which don't work with additional section processing
either.  Even gmail.com doesn't use in-bailiwick mail exchangers.

Clearly even today MTAs can't rely on caches including A/AAAA records
for the mail exchanges in the additional section of their MX query
responses, so they'll have to do explicit queries anyway.  So why
forbid the usual CNAME processing in those extra explicit queries?

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 21 Apr 2010 19:46:58 +0100

> ratholing into a question about TLDs.  It's fully generalizable:

	It may be fully generalizable, but your examples don't
	seem to cover the gamut of cases.  I'm not certain that
	this matters, as serendipitous implementation may drag 
	them in anyway.

	The additional cases I'm thinking of are the following.

	(d?) Equivalence arises between names with different
	label counts (Vixie example); and

	(e?) a common suffix (TLD label, or sequence of more
	significant labels nearest the root) has multiplicity
	of unity (current situation under .GR).

	ATB,
	Niall O'Reilly

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 21 Apr 2010 19:57:19 +0100

> So what is the mail problem?  

	A distraction.
	A non-issue.
	There is none.

	To paraphrase the message from Doug Otis: it's
	about (LHS) keys, not about (RHS, RDATA) values.

	ATB,
	Niall O'Reilly

---

From: Jim Reid <[email-masked]>
Date: Wed, 21 Apr 2010 20:04:27 +0100

> What's the big deal in supporting CNAME records in MX record targets?

Well for starters it's a protocol violation. See Section 10.3 of  
RFC2181.

Bad Things can also happen with MTAs when the target of an MX record  
is not the canonical host name. A common misconfiguration is to use a  
CNAME which the MTA then finds points at itself, causing loops or  
erroneously bounced mail. When sendmail is involved, this gives rise  
to the delightful "I refuse to talk to myself" error: http://www.sendmail.org/faq/section4#4.5 
.

Changing the DNS protocol here would be unwise because of the impact  
it would have on broken MTAs that do The Wrong Thing. A protocol  
change would also break the installed base of MTAs that do The Right  
Thing and can't/won't go chasing CNAMEs.

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 21 Apr 2010 20:23:04 +0100

On 21/04/10 18:46, Douglas Otis wrote:
> [...] On the other hand, BNAME copies NS RRs into the alias

	I've never thought of making a zone apex the target
	of a CNAME.  This may be unusual, or even perverse, 
	but is it actually forbidden?  If not we have the
	potential effect already since RFCs 1034 and 1035.

	And a zone cut could be below the target of a DNAME,
	couldn't it?

	ATB,
	Niall O'Reilly

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Apr 2010 15:42:56 -0400

> as a target for the MX record.

I don't believe I did.  I was pointing out that that couldn't be "the
mail problem".  The only mail problem we might have is that an MX
can't point to a CNAME.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Apr 2010 15:44:14 -0400

>> So what is the mail problem?  

Ok, except since Vaggelis is the one who says there is this problem,
I'd like to know what it's supposed to be.  Remember, we're trying to
figure out whether there's a problem to solve.  Step 1 in that is
"describe problem", I think.

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

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 21 Apr 2010 20:51:26 +0100

On 21/04/10 20:23, Niall O'Reilly wrote:
>     of a CNAME.  This may be unusual,

	Doh!
	Thinking in wrong layer.  Hubris. ...

www IN CNAME @

	OTOH, copying NS RRs into the alias isn't a new
	phenomenon.

	ATB,
	Niall O'Reilly

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Apr 2010 15:56:54 -0400

Thanks for the continued effort in clarifying these issues.  It's
really very helpful.  I'll try to be terse too.

On Wed, Apr 21, 2010 at 07:29:35PM +0100, Niall O'Reilly wrote:

> 	This question ("Which of the following ...") is a matter of 	registry 
> policy, whether that registry be ICANN, a TLD, or the 	administrator of 
> some deep subsidiary zone.  It's not the problem 	we're looking for, and 
> we should best avoid it.  

It's exactly the problem we're supposed to be solving, in that those
are three possible meanings of "equivalent" and they are nowise the
same thing.  If we're going to claim that we're supporting aliasing,
we need to be crystal clear on what we can and cannot do.  If it turns
out that all the things we actually can do solve no actual problem
that actual users actually have, then I do not believe the WG will
ever complete the work, and I will conclude we should not add it to
the charter.  

> such policy is for the registry 	concerned.  This WG need not concern 
> itself with repertoires or 	writing systems.  Such things belong in a 
> different layer.  

On this we completely agree.  I'm trying to understand use-cases, but
I am not pretending that we will be able to "solve" some linguistic
problem.  

> 	domain names.  Each such set has properties such as 	multiplicity and 
> fan-out.  The latter may have to be 	considered at either or both (!) the 
> label and zone levels.

Exactly right.  So, what among the possible properties here are we
capable of solving, and do those align with the needs of the potential
user population?  I maintain that the latter question is more
important than the former.

A

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Apr 2010 07:38:56 +1000

> 	about (LHS) keys, not about (RHS, RDATA) values.

Aliases are a issue on *both* sides.

If you use addresses as aliases then you need to configure the MTA
to know all the possible permutations so accept the email as the
sending MTA won't re-write the mail domain component as it does
when presented with a CNAME.

If you use CNAME or addresss as aliases then you need to configure
the MTA to know all the possible permutations for MX processing.
This is critical when the MTA is *not* the best preference MX.

If the MTA is the best preference MX then the mail gets delivered
before MX processing occurs but that assumes the MTA knows the
aliases for all the domains it is supposed to accept email for.

The same thing *may* apply with SRV.  It depends if the target is
store-and-forward or not.

Mark

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 21 Apr 2010 23:14:52 +0100

On 21/04/10 20:56, Andrew Sullivan wrote:
> [...]  So, what among the possible properties here are we

	Absolutely!

	Would you attach even more importance to alignment of a 
	solution to the needs of an actual user population?

	http://www.ίδρυματεχνολογίασέρευνασ.gr/
	http://www.xn--ixadahbbkgke5djpgxb1al0bfgtp0b.gr/

	is one element of an eight-fold bundle, actually in use,
	but implemented (IIUC) as a four-fold bundle to save on 
	overhead.  Potentially, when .GR implements IDNA2008, 
	this becomes a 32-fold bundle, as two additional
	character-equi-ambivalences (sic!) will be introduced, 
	increasing the binary logarithm of the multiplicity 
	from 3 to 5.

	Whenever a [dot-Greece-in-Greek] TLD appears, there is
	potential for a 2- (or, if the existing .GR is counted
	in, 3-) fold increase in multiplicity.  That's an
	anticipated need for nearly 100 "images" of a zone to 
	be projected into the DNS.

	Vaggelis has told us that he sees BNAME as a better 
	solution for what he has to deal with already today
	than the awkward current solution of using DNAME with 
	apex (not zone apex, but DNAME apex) back-filling.

	IMHO, BNAME is worth doing because it meets an
	existing, rather than potential need.

	In addition, by avoiding the replication of data, BNAME
	promises to contain the combinatorial explosion.  This
	problem seems not to be well contained by the SHADOW
	concept.  I'm not suggesting that there are no converse 
	reasons for preferring SHADOW.

	ATB,
	Niall O'Reilly

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 21 Apr 2010 23:35:18 +0100

> Aliases are a issue on *both* sides.

	Indeed, but respectively separable as (OT1H) DNS 
	and (OTO) application issues.

	Of course we need to keep an eye to consequences,
	but we probably also need to partition the problem(s).

	ATB,
	Niall O'Reilly

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Apr 2010 09:14:26 +1000

> lack of a new option, that it does not support a new BNAME paradigm.

What NS's?  BNAME is a singleton like CNAME is a singleton.  It exists
with itself and DNSSEC records proving its existance.  It does not
co-exist with NS, SOA, A, MX, AAAA or any non-DNSSEC records.

> how synthesized CNAMEs will be supported by DNSSEC.

Actually it is perfectly clear on how we do this.  We have done a
similar exercise before and know exactly how to do this.

DNSSECbis servers don't support NSEC3 but somehow we managed to
introduce NSEC3 without breaking all the DNSSECbis servers.  We
just do the same thing when we introduce BNAME.  i.e. use DNSSEC
algorithms to signal if the zone may contain a BNAME and only those
validators that understand BNAME will treat it as secure.  Everyone
else will treat the zones as insecure.

How to do this has been pointed out multiple times now.
 
> Klensin also suggested there was a need to determine the bundle members 

Shadow zones are just as bad, if not worse for MTA's.  You don't get the
self repairing properties of the CNAME so more email will bounce.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Apr 2010 17:21:14 -0700

On 4/21/10 4:14 PM, Mark Andrews wrote:
> What NS's?  BNAME is a singleton like CNAME is a singleton.  It exists with itself and DNSSEC records proving its existance.  It does not co-exist with NS, SOA, A, MX, AAAA or any non-DNSSEC records.
>    
http://tools.ietf.org/html/draft-yao-dnsext-bname-01

While the introduction makes a singleton type claim, it defines this as 
meaning there can be only one BNAME per node.  The process defined in 
section 4.1 "Processing by Servers" for item b of step 3 indicates 
inclusion of the NS records.  To permit aliasing an entire domain, the 
NS and BNAME resources will appear at the same node.  It does seem there 
might need to be exceptions with respect to CNAME synthesis, however the 
current BNAME draft offers little guidance in that respect.
>> The Shadow zone solution does not appear to suffer from these problems  while also offering a means to provide "equivalent" domains.  JohnKlensin also suggested there was a need to determine the bundle members  of equivalent domains.
> Shadow zones are just as bad, if not worse for MTA's.  You don't get the self repairing properties of the CNAME so more email will bounce.
>    
You have said this before, but we have experienced problems with perhaps 
 >1% of email senders refusing aliased MX target, against tens of 
thousands of domains.  This had been done following advice given by a 
content delivery provider.  Alternatively, there isn't any difficulty in 
setting up MTAs to forward to a desired domain.  It would seem both John 
and I disagree that CNAMEs provide a better solution for MX records.  
This will also be true with NS, SRV, and PTR records. :^(

MX records are normally located at the same name as NS, and SOA, which 
is also where the BNAME will need to reside.  But this is problematic, 
since it is indeed illegal for CNAMEs to coexist with these other resources?

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Apr 2010 11:02:04 +1000

In message <[email-masked]>, Douglas Otis writes:
> > What NS's?  BNAME is a singleton like CNAME is a singleton.  It exists with
>  itself and DNSSEC records proving its existance.  It does not co-exist with 
> NS, SOA, A, MX, AAAA or any non-DNSSEC records.
> >    
> inclusion of the NS records.

You failed to take into account Section 3.3. The relevent sentence
has been isolated below.

3.3. The BNAME Rules

   There are two rules which governs the use of BNAMEs in a zone file.
   The first one is that there SHOULD be no descendants under the owner
   of the BNAME.  

		   The second one is that no resource records can co-
   exist with the BNAME for the same name. 

					    It means that if a BNAME RR
   is present at a node N, there MUST be no other data at N and no data
   at any descendant of N. This restriction applies only to records of
   the same class as the BNAME record.

> To permit aliasing an entire domain, the 
> NS and BNAME resources will appear at the same node.

No.  BNAME gets added to the "parent" zone.   When we were designing
DNAME we needed to decide if it aliased itself and we decided not to
as aliases of itself required the "parent" to support DNAME.

BNAME still needs more work.  A non-BNAME aware client should never
see a BNAME record unless it is explicitly requested.  Conversly a
BNAME aware client should never see a synthesised CNAME as long it
is is talking to BNAME aware servers.

Sending both the DNAME and CNAME is one of the things we got wrong
with DNAME.  Another thing we got wrong was not signaling DNAME
understanding from the start.  We also didn't understand how to
introduce a change like DNAME with DNSSEC.

We don't need to repeat these problems with BNAME.

The current BNAME draft also fails to account for DNAME in the
processing rules.

Mark

---

From: Douglas Otis <[email-masked]>
Date: Wed, 21 Apr 2010 19:54:36 -0700

> is is talking to BNAME aware servers.
Thank you for the clarification.

It seems most domains are fairly flat, but this seem to suggest a 
departure from current practices of being flat and referencing MX 
records at zone apexes.

For example,  take the domain "example.com."  Most domains locate MX 
records at the zone apex, where in this instance, it would be at 
"example.com."  It would not be practical to place a BNAME in ".com" 
which needs to contain NS records for delegation.  But BNAME could 
reside in a sub-domain of say "2.example.net" to be BNAME aliased with 
"example.com." is that right?  So...

# example.net using BNAME might look like:
example.net. IN NS dns-svr.example.net.
2.example.com. IN BNAME example.com.

# example.com supporting BNAME might then look like:
example.com IN NS dns-svr.example.com.
example.com IN MX 10 mail-svr.example.com.

However, since a subdomain is needed to isolate BNAME from other 
resources, a similar structure is possible using DNAME as follows:

# example.net using DNAME might look like:
example.net IN NS dns-svr.example.net.
example.net IN DNAME example.com.

# example.com supporting DNAME might then look like:
example.com IN NS dns-svr.example.com.
2.example.com IN MX 10 mail-svr.example.com.

The difference between BNAME and DNAME would be an ability to tailor the 
isolation labels within name bundles.  However Shadow zones could 
eliminate pesky isolation labels all together. :^)

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Thu, 22 Apr 2010 14:01:48 +1000

> departure from current practices of being flat and referencing MX 

No, it doesn't.
 
> which needs to contain NS records for delegation.

Why not?  It should be no harder to add BNAME records to com once
the servers support BNAME than it is to add NS records.

> But BNAME could 

You are making this much more complicated than it really is.

---

From: "YAO Jiankang" <[email-masked]>
Date: Thu, 22 Apr 2010 14:19:25 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: "Vaggelis Segredakis" <[email-masked]>
Cc: "'Niall O'Reilly'" <[email-masked]>; <[email-masked]>; "'Sotiris Panaretou'" <[email-masked]>
Sent: Wednesday, April 21, 2010 10:03 PM
Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT aliasmaybe-work

> solve the "mail server issue" for aliasing any more than CNAME does.

I think that Vaggelis is hoping to make [email-masked] and [email-masked] to resolve to the same MX records or address if you want to make shinkuro1.com to be equal with shinkuro2.com.
He has no intention to make shinkuro1.com  to be the  target of an MX record in real configuration. In your example,  yes, we could
 not use some.label.tld as the target of an MX record in real configuration, but we can use shinkuro2.com (or other.label.tld in your example) as the  target of an MX record.
both shinkuro1.com and shinkuro2.com will get the same MX record if shinkuro1.com BNAME shinkuro2.com is applied.
both some.label.tld and  other.label.tld will get the same MX record if some.label.tld BNAME other.label.tld is applied.

if bname is used, Vaggelis' worry will disappear since the mail to  [email-masked] and [email-masked] will go to the same email serve and be dilvered to same email box.

Jiankang Yao

---

From: "YAO Jiankang" <[email-masked]>
Date: Thu, 22 Apr 2010 15:00:15 +0800

----- Original Message ----- 
From: "Douglas Otis" <[email-masked]>
To: "Mark Andrews" <[email-masked]>
Cc: "Vaggelis Segredakis" <[email-masked]>; "'Niall O'Reilly'" <[email-masked]>; "'Andrew Sullivan'" <[email-masked]>; <[email-masked]>; "'Sotiris Panaretou'" <[email-masked]>
Sent: Thursday, April 22, 2010 10:54 AM
Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work

> 2.example.com IN MX 10 mail-svr.example.com.

your example is  so complex so that I can not have the clear idea of what it is.

> isolation labels within name bundles.  

the difference BNAME and DNAME  is not what you said.

the Abstract in bname draft said:
"
   This document defines a new DNS Resource Record called "BNAME", which
   provides the capability to map itself and its subtree of the DNS name
   space to another domain.  It differs from the CNAME record which maps
   a single node of the DNS name space, from the DNAME which maps the
   subtree of the DNS name space to another domain.
"

for example,

if dname is used,
 color.com dname colour.com

query for every subdomain of color.com such as t1.color.com will go to colour.com domain for answer.
query for color.com will go to its own domain color.com for answer.

if bname is used,
 color.com bname colour.com

query for color.com  and every subdomain of color.com such as t1.color.com will go to colour.com domain for answer.

for your concern of  CNAME leading to MX, yes, we should be caution of CNAME/DNAME/BNAME loops.

if there are no loops, the synthesized CNAME will finally lead to the MX record or address,

the first sentense of the second paragraph in section 5.1 in RFC 5321 said, 
"
   The lookup first attempts to locate an MX record associated with the
   name.  If a CNAME record is found, the resulting name is processed as
   if it were the initial name.
"

Jiankang Yao

>However Shadow zones could

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Apr 2010 11:22:55 +0100

On 21 Apr 2010, at 10:08, "Vaggelis Segredakis" <[email-masked]>  
wrote:
>
> In this case you have to set up a mechanism that redirects all  
> emails to the email he considers the correct one. This could happen  
> by setting up the same email in each domain. What if this was the  
> case for each email account of a company and you had four ways of  
> typing the company domain name, each one of them correct, depending  
> on character case or set?

Any decent mail server will make it easy to configure domain-level  
aliases with one line of configuration per domain.

> What if this was the case for the domain name itself in the http  
> protocol?

For HTTP you are better off doing a client-side redirect to the  
preferred domain. Again it's one line of configuration per domain.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Thu, 22 Apr 2010 13:53:28 +0300

Dear Tony,

I have no objection that you can work around these issues on the client
side. However, the IDNA and IDNA2008 protocols were created to allow users
who would like to use domain names in their native character sets to do so
without any strange behavior from the domain name side. Further more, I
would say without extra cost and complexity.

This is not the case with Greek IDNs and I think other languages as well. If
you need multiple domain names to represent *each* word in your language it
is necessary to get all the help you can get as a user to keep things simple
and cost effective.

We as a registry and many registries who have to bundle domain names will
appreciate the ability of DNS to make these domains act as one on user
request. This way the IDNA protocol will have the chance to really serve the
users and become a useful alternative to the Latin domain names.

Since the bundling option could not be a part of the IDNA2008, it was
necessary to bring our request to the DNSEXT group. From our side it is
obvious that the DNAME has something missing, we ask for this to be remedied
with xNAME. The solution has to come from within the DNS itself so that the
registry can be a part of it.

Kind Regards,

Vaggelis Segredakis

-----Original Message-----
From: Tony Finch [mailto:[email-masked]] On Behalf Of Tony Finch
Sent: Thursday, April 22, 2010 1:23 PM
To: Vaggelis Segredakis
Cc: Niall O'Reilly; Andrew Sullivan; <[email-masked]>; Sotiris
Panaretou

Tony.

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Apr 2010 16:08:37 +0100

> would say without extra cost and complexity.

I was under the impression that the point of IDNA was that application
software has to do the work, not the DNS :-)

There's no way that a new feature in the DNS can trigger the kinds of
application-level redirects that you asked about. Your question might be
more properly directed at the IMA working group for email; I'm not sure
where would be right for HTTP.

I note that in the 1980s, SMTP clients were required to canonicalize
domain names by resolving CNAME records. This practice was dropped in the
1990s. Current practise is that MXs must be aware of all the domains that
they wish to accept email for, including CNAME aliases, and these will
typically be configured explicitly.

HTTP name-based virtual hosting is in a similar situation to email. With
IP-based virtual hosting the HTTP server doesn't need to care about what
name it is called by; however there are a number of reasons it is better
for the server to redirect requests to the preferred spelling: to ensure
that bookmarks and links from other pages use the preferred name; to avoid
duplicate entries in caches; to simplify x.509 certificate requirements;
etc.

Having said that, perhaps the DNS can be used to simplify the server-side
configuration. Instead of explicitly configuring all the aliases for a
domain, the server could be configured to accept any BNAME pointing at the
preferred name. (This is different from the old SMTP CNAME
canonicalization since it's opt-in for each server that wishes to support
it, rather that being globally (un)implemented by clients.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Apr 2010 11:33:32 -0400

On Wed, Apr 21, 2010 at 11:14:52PM +0100, Niall O'Reilly wrote:
> 	Would you attach even more importance to alignment of a 	solution to the 
> needs of an actual user population?

Yes.  And I'm with you so far.

> 	but implemented (IIUC) as a four-fold bundle to save on 	overhead.  

Right.  I understand the problem.

What I do not understand is what it is we're supposed to be able to do
about it.

> 	Vaggelis has told us that he sees BNAME as a better 	solution for what 
> he has to deal with already today
> 	than the awkward current solution of using DNAME with 	apex (not zone 
> apex, but DNAME apex) back-filling.

And I want to know how it's better.  The BNAME at
xn--ixadahbbkgke5djpgxb1al0bfgtp0b.gr is going to occlude things
underneath it, I think.  If that's right, then what does one do with
xn--ixadahbbkgke5djpgxb1al0bfgtp0b.xn--ixadahbbkgke5djpgxb1al0bfgtp0b.gr?
Does this work out to be a combinatorial explosion anyway?  If so,
would it be better to work on improved provisioning tools, so that
provisioning with the DNAME+back-filling approach (which is what's
possible today) is just easier?  This latter approach has the notable
benefit that exactly zero additional deployed resolvers need to be
upgraded to make it work.  It isn't plain to me how that will be the
case for BNAME.

Note that a resolver that only undersntands CNAME might get annoyed by
a BNAME, since the BNAME is at the same name as the CNAME, and that's
not supposed to be allowed.  Moreover, we have a DNSSEC problem with
BNAME, because we have existing deployed validators that know nothing
about BNAME.  If we use the same signing approach as was used with
DNAME, then, we might expect validation failures.

A

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

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 22 Apr 2010 17:43:46 +0100

[...]
>> Vaggelis has told us that he sees BNAME as a better solution for
>> what he has to deal with already today than the awkward current
>> solution of using DNAME with apex (not zone apex, but DNAME apex)
>> back-filling.
> 
> Does this work out to be a combinatorial explosion anyway?

	If the BNAME were used in the parent zone as a pseudo-delegation,
	only the canonical zone instance would need to be maintained and
	supported, rather than all the stub-apices carrying SOA/NS/DNAME
	(DNS metadata) and possibly A/AAAA/MX/whatnot (node data) which 
	are needed today.

	With BNAME, each additional member of the bundle would require 
	just one extra BNAME RR, not an extra zone.  With cascaded 
	bundled zones, delegation would only needed from each canonical
	zone to the child canonical zone.  This promises to avoid the
	combinatorial explosion.

> If so,
> possible today) is just easier?

	At scale, I doubt it.  At some stage, and I don't know where
	the break point would lie, a large number of lightweight zones
	just becomes too heavy.  Moreover, distance from the root,
	measured by label count, increases the burden of the 
	combinatorial effect.  I suggest that distance from the root 
	is probably also strongly correlated with dilution of clue and
	scarcity of resources.  Thus, the burden would fall on those
	least prepared to bear it.

> This latter approach has the notable

	Mark Andrews seems to thing that tailoring the response
	according to an opt-in flag in the query is enough to make
	BNAME fly, and to allow appropriate assistance to be offered
	to BNAME-ignorant resolvers.

> DNAME, then, we might expect validation failures.

	I think MarkA has addressed all of this in a recent message.

	ATB
	Niall O'Reilly

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Apr 2010 13:07:40 -0400

On Thu, Apr 22, 2010 at 05:43:46PM +0100, Niall O'Reilly wrote:

> 	(DNS metadata) and possibly A/AAAA/MX/whatnot (node data) which 	are 
> needed today.

But if you did this on the parent side of the zone cut with DNAME and
A and AAAAs for the synonyms, why wouldn't that work as well?  Note
that in this case, the A and AAAA isn't glue: it's authoritative data
in the parent, I think.  (The A and AAAA are only needed so that
direct lookups for, say, http://synonym, rather than e.g.
http://www.synonym, will work.)

A

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Apr 2010 13:15:21 -0400

No hat.

> else will treat the zones as insecure.

I find it a little strange that on the one hand we've had people
wringing their hands about us potentially running out of algorithm
numbers, and on the other hand we're prepared to use up twice as many
numbers as we have allocated on the day a new RRTYPE of this sort is
used.

I'm not saying that's the wrong answer, but surely all the people who
were uncomfortable with the algorithm allocation document are going to
be unhappy with the above answer too, right?

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

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 22 Apr 2010 19:08:37 +0100

> http://www.synonym, will work.)

	1x zone update
	(n-1)x transaction request to parent
	Parental latency and clumsiness

	Ask any teenager! 8-)

	ATB
	Niall O'Reilly

---

From: Douglas Otis <[email-masked]>
Date: Thu, 22 Apr 2010 11:20:21 -0700

> > departure from current practices of being flat and referencing MX

I am confused then and need your help.

> > For example,  take the domain "example.com."  Most domains locate
> > MX records at the zone apex, where in this instance, it would be
> > at "example.com."  It would not be practical to place a BNAME in
> > ".com" which needs to contain NS records for delegation.
>

Doesn't section 3.3 rule 2 exclude this possibility?  There are 13 NS 
records at ".com" pointing to root name servers?  What would it mean to 
have just a CNAME at ".com" and wouldn't an aliased domain still need to 
include resources that will exclude CNAME or BNAME?  What am I missing?

3.3. The BNAME Rules

    There are two rules which governs the use of BNAMEs in a zone file.
    The first one is that there SHOULD be no descendants under the owner
    of the BNAME.  The second one is that _no_ resource records can co-
    exist with the BNAME for the same name. (except resources for DNSSEC).

> > But BNAME could reside in a sub-domain of say "2.example.net" to
> > be BNAME aliased with "example.com." is that right?  So...
>

Resource records at zone apexes will exclude inclusion of BNAME RR and 
will also prevent any language specific descendants down this path.

This would suggest BNAME requires conventions for resource isolation 
labels of perhaps always using numbers such as "200" to reference email, 
"201" to reference http, "202" to reference SRV, etc.   Conventions to 
allow users a means to guess the locations of redirected services, much 
like "www" locates http,  other services being redirected will then need 
conventions specific for each language, or perhaps this could be number 
based.  By making it numbers based, BNAME would not needed, and just 
DNAME could be used.  IMHO, the shadow draft appears able to deal with 
existing practices, and BNAME does not.  In addition, BNAME works 
against having a flatter name space and being able to use the zone apex 
for locating services such as email, im, etc.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Apr 2010 09:08:45 +1000

In message <[email-masked]>, Douglas Otis writes:
> have just a CNAME at ".com"

When you buy a <foo>.COM domain you would get the choice of adding
NS records for <foo>.COM *or* adding a BNAME for <foo>.COM.  You
don't add *both* NS records and a BNAME.  Adding a BNAME would
remove the NS records from the COM zone, adding a NS RRset would
remove the BNAME from the COM zone.
 
This is not rocket science.  It does require registries and registrars
to update their processes but that is nothing new.  AAAA and DNSSEC
required updates to the processes.

> and wouldn't an aliased domain still need to 

I can't think of any records that would be needed. There is no
glue required for a BNAME.  You would be dependent on COM being
signed if you wanted <foo>.COM to be signed rather than being able
to sign it yourself.

A signed BNAME takes less resources than a signed delegation and
would be roughly equivalent to a unsigned delegation once you add
up the multiple NS records and glue.

BNAME + RRSIG(BNAME) + NSEC{3} + RRSIG(NSEC{3})
NS + DS + RRSIG(DS) + NSEC{3} + RRSIG(NSEC{3})

Mark

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 23 Apr 2010 10:27:19 +0800

----- Original Message ----- 
From: "Douglas Otis" <[email-masked]>
To: "Mark Andrews" <[email-masked]>
Cc: "Vaggelis Segredakis" <[email-masked]>; "'Niall O'Reilly'" <[email-masked]>; "'Andrew Sullivan'" <[email-masked]>; <[email-masked]>; "'Sotiris Panaretou'" <[email-masked]>
Sent: Friday, April 23, 2010 2:20 AM
Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT alias maybe-work

> include resources that will exclude CNAME or BNAME?  What am I missing?

do you mean that in the root zone there can have 13 NS records for .com while there will only one BNAME record for .com if BNAME is applied?
so you think that 13 is safer or robuster than 1?

yes, you can have many NS records as you want; but you can have only one BNAME record.

in the root zone,

you can have

COM. NS A.GTLD-SERVERS.NET.
COM. NS G.GTLD-SERVERS.NET.
COM. NS H.GTLD-SERVERS.NET.
COM. NS C.GTLD-SERVERS.NET.
COM. NS I.GTLD-SERVERS.NET.
COM. NS B.GTLD-SERVERS.NET.
COM. NS D.GTLD-SERVERS.NET.
COM. NS L.GTLD-SERVERS.NET.
COM. NS F.GTLD-SERVERS.NET.
COM. NS J.GTLD-SERVERS.NET.
COM. NS K.GTLD-SERVERS.NET.
COM. NS E.GTLD-SERVERS.NET.
COM. NS M.GTLD-SERVERS.NET.

if you want COMPANY. to be same with COM.,
you need to have this record in the root zone:

COMPANY.  BNAME COM.

although there is only one record for BNAME,

the robustness COMPANY. gets is as same as what the .COM gets since every query for .COMPANY will be directed to .COM while .COM has 13 NS records.

Jiankang Yao
CNNIC

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 23 Apr 2010 10:39:53 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: "Niall O'Reilly" <[email-masked]>
Cc: "Vaggelis Segredakis" <[email-masked]>; <[email-masked]>; "'Sotiris Panaretou'" <[email-masked]>
Sent: Thursday, April 22, 2010 3:44 AM
Subject: Re: [dnsext] Re: Aliasing and MX

> I'd like to know what it's supposed to be.  

as a registry, we have some experience of why dname is not used in many registries.
.gr is a registry.

normally, the registry only provide the NS records in the TLD zone, no A record or MX record.

someone registers  color.tld and colour.tld.
in current practise, we will put in TLD zone
color.tld. NS namerserver;
colour.tld. NS nameserver;

if we want color.tld and colour.tld. to get the identical resloution,
we may put  in TLD zone

color.tld. NS namerserver;
colour.tld. DNAME color.tld;

now the user expect [email-masked] and [email-masked] to be same.

in order to get the same address for [email-masked] and [email-masked] ,

in the color.tld zone, we need
color.tld MX a.color.tld
a.color.tld A 192.168.1.1

in the TLD zone,

we need 
colour.tld MX a.color.tld

but unfortunately, most registries do not provide the A record or MX record service.

even the registry provides the service of MX record, it is not comfortable for customers who must update the MX records in the registry every time he wants to update it.

so if there has a BNAME,

we may put  in TLD zone

color.tld. NS namerserver;
colour.tld. BNAME color.tld;

now the user expect [email-masked] and [email-masked] to be same.

the user only configure everything in the color.tld zone, not in TLD zone.

Jiankang Yao

>Remember, we're trying to

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 23 Apr 2010 10:58:20 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 23, 2010 1:15 AM
Subject: BNAME, Synthesized CNAME, and DNSSEC (was: [dnsext] ICANN's"synchronized domains" and the DNSEXT alias maybe-work)

> be unhappy with the above answer too, right?

IPv4 address is exhausting soon, but  I have never heard that IANA will refuse to allocate the IPv4 address to customers.

I only heard that IANA is trying to allocate the address to those who need it.

when IPv4 address is running out, the IPv6 will come.

Does protocol design follow the customer's needs?

If we do not satisfy the needs of customers,  it may cause more unhappy.

I think that the IPv4 address example may apply here.

:)

Jiankang Yao

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Apr 2010 14:47:54 +1000

> numbers as we have allocated on the day a new RRTYPE of this sort is

Firstly it wouldn't be double.  You would create aliases for
RSASHA256, RSASHA512, NSEC3DSA and ECC-GOST.  RSAMD5, DSA, RSASHA1
and NSEC3RSASHA1 would not get aliases.  One could argue about
NSEC3RSASHA1 but I believe it is reasonable not to create a alias
for it.

That leaves 4 new algorithms B-RSASHA256, B-RSASHA512, B-DSA, B-ECC-GOST
which all support NSEC3 and BNAME.

Secondly one very rarely changes the rules associated with validation.
This shouldn't be thought of as a new type but a new method of
synthesis.

Mark

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 23 Apr 2010 09:49:11 +0100

On 21/04/10 20:56, Andrew Sullivan wrote:
> It's exactly the problem we're supposed to be solving,

	I'm sorry.  I see what you mean.  
	I wasn't seeing the wood for the trees.
	[ I should heed my own choice of Subject: line. 8-) ]

> in that those are three possible meanings of "equivalent"

	Two of them, yes; the other, arguably not.

> and they are nowise the same thing.

	Agreed.

	Now, back to what they were, to save people some searching ...

>          r2.r2.r2.[name2], r1.r2.r2.[name2], and so on?

	In (a) and (c), [name1] and [name2] are equivalent, and (a) may
	(modulo some fine detail) be seen as a degenerate case of (c).

	Case (b) is so pathological that I believe it is best placed
	explicitly out of scope.  This case represents a giant cluster 
	of equivalences between corresponding pairs of FQDNs.  These
	pairwise equivalences are not hierarchically aggregable, even
	at the level of a leaf zone.

	Case (b) is an excellent example of how a particular choice
	at the policy level may lead to an intractable "requirement"
	for implementation.

	IHTH
	ATB
	Niall O'Reilly

---

From: "Yao Jiankang" <[email-masked]>
Date: Fri, 23 Apr 2010 21:00:07 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: "Vaggelis Segredakis" <[email-masked]>
Cc: "'Niall O'Reilly'" <[email-masked]>; <[email-masked]>; "'Sotiris Panaretou'" <[email-masked]>
Sent: Wednesday, April 21, 2010 10:03 PM
Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT aliasmaybe-work

> (a) and (c) but not (b),

my understanding is that BNAME works for case (b) too.

if you want  r1.r1.[name1] to be equal with r2.r2.[name2], your assumption is r1=r2.

so we set

 .name1 BNAME . name2 in the top zone.

in .name2 zone,
we just set
 r2.r2.name2 BNAME r1.r1.name2
or 
   r2.name2 BNAME  r1.name2

Jiankang Yao

> that for (c) it requires no less work than

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Apr 2010 11:53:47 -0400

On Fri, Apr 23, 2010 at 09:49:11AM +0100, Niall O'Reilly wrote:

> 	explicitly out of scope.  This case represents a giant cluster 	of 
> equivalences between corresponding pairs of FQDNs.  These

It's interesting that you might want to rule (b) out of scope, because
one of the most plausible interpretations I was able to construct of
the ICANN "synchronized domains" plan was in fact this one.  Several
people told me that (c) was for sure out of scope, and others told me
that (a) wouldn't actually solve the problem people had.

I'm sorry it's taken me this long to get across what I'm worried
about.  I agree with you that (b) is a serious problem, and is
probably something we're not going to be able to accommodate very
easily (unless I've missed something in the BNAME proposal.  More on
this down-thread).  But this is why I think it very important we come
to some agreement on what the problems are we're trying to solve (or
even simply that we can't solve).

A

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Apr 2010 12:02:32 -0400

>  r2.r2.name2 BNAME r1.r1.name2

That collapses to case (c), because both zones end up with a copy of
everything, all the way down, right?  That is, if you look up
r2.name1, you get redirected to r2.name2, no?  So, to be strict, this
doesn't meet the rule because of the "always and only" restriction.

If that's acceptable, then ok.  But I'd been led to believe that it
was not.  On the contrary, I'd been let to believe that one
implementation, actually the target of the synchronized domains
proposal, implements two completely different trees.  In that
particular case, one tree uses one subset of a script, and the other
tree uses a different subset of the same script.  If you're in the
"script subset 1 tree", and you use a character from "script subset
2", you don't get anywhere.  Perhaps you have details of a use case in
mind that would be more relevant, though?

Best,

A

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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Apr 2010 12:11:52 -0400

No hat.

> NSEC3RSASHA1 but I believe it is reasonable not to create a alias

Why are those ones special?  I can probably see the argument for MD5,
but the rest look to me to increase fragility.

Note, also, that we have recently sent a document about assignment of
code points out to the IESG.  I'd be astonished if we didn't allocate
some more code points before BNAME is standardized.

> This shouldn't be thought of as a new type but a new method of

I can accept this argument.  I'm just pointing out that people were
pretty uncomfortable with the potential to go through code points to
allocate, and if this is our answer we're going to use them up even
faster.

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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 24 Apr 2010 02:27:44 +1000

> but the rest look to me to increase fragility.

NSEC3DSA is a superset of DSA so you don't need a alias for DSA that
only does BNAME and not NSEC3.

> allocate, and if this is our answer we're going to use them up even

Not really.  Just a step not a multiplication.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 23 Apr 2010 12:48:37 -0400

>     at the policy level may lead to an intractable "requirement"

I thought I pointed out that label length, while arbitrary in theory,
as identifiers may, like words are, be built as compounds of Han
characters, is predominantly five or fewer total Han characters, and
that, orthogonally in theory but not independent in fact, characters
for which a SC form exists have a higher stroke count than many
characters present in two and more character names, and therefore,
identifiers.

That is, the correct characterization is not powers of 2, and
therefore bounded above by 9,223,372,036,854,775,808 (2^^63, "xn--"
being tossed aside like the base of a stalk of celery), but something
quite a bit smaller, as the frequency of characters for which no
simplified equivalence exists will be (a) 1 in identifiers composed
and intended to be resolved only in the PRC, and greater than zero in
identifiers composed, or intended to be resolved, outside of the PRC.

My wild-ass-guess is that for strlen(label) <= 5, that the average for
equivalency classes is bounded above by 2^^3, that is, on average, at
least two characters do not exist in a simplified form.

My wild-ass-guess is also that registries that offer equivalence
without length restriction venture into self-injury terrain.

However, having offered this observation previously, I've no idea why
the exponential explosion is still lying around, periodically being
used to blow the feet off of any proposal to actually look at the
SC/TC problem as anything other than inherently intractable.

I suppose I should use darker electrons or something, to obtain a bold
effect for legibility, or electrons with sufficient spin to obtain an
italic effect, for the same purpose.

Case (b) is an excellent example of using less intellect than is
available to misstate a problem and arrive at a deliciously
intractable outcome.

Eric

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Apr 2010 12:56:32 -0400

> SC/TC problem as anything other than inherently intractable.

I don't actually think a combinatorial case is inherently intractable,
first.  But second and more importantly, we're not here trying to
solve the TC/SC problem.  If we were, our lives would be easier.  What
we are trying to do is create what I've come to think of as synonymy
in the DNS, and if we have a way in which the solutions we pursue
become seriously intractable, we need to be aware of that, _even if_
those solutions happen to solve a different class of problems.

> available to misstate a problem and arrive at a deliciously

What is the misstatement in (b)?  The point in (b) is that the trees
are distinct from one another, that each FQDN in either is a synonym
for something in another tree, and that at least one label that would
be permitted in the one tree is not allowed in the other tree.
Somebody might want that, and people have claimed to me that people
_did_ want that.  I don't know whether anyone does, but we can surely
admit that it's a possible case even if we subsequenrly decide that
it's not a problem worth solving.

A

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

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 23 Apr 2010 13:45:08 -0400

Where, other than in the SC/TC problem, does this exist?

>     a giant cluster

Eric

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Apr 2010 13:55:30 -0400

> Where, other than in the SC/TC problem, does this exist?

It makes no difference.  We can't start screwing with the protocol in
order to solve that particular problem and no other.  We have to solve
the general problem if we're solving anything in the DNS.

It's quite another matter when you're dealing with particular
provisioning systems or policies.  But as I put up on the screen in
Anaheim (the slides are available from the meeting materials site), we
are not undertaking to solve the linguistic variants problem in this
WG.  We are not linguistically competent to do that, and anyway we're
at the wrong layer.  That is not to say we ignore linguistic variants
as a use-case: it's what tickled this topic into our laps.  But if
there's something to do here, it is simply more general than that.

A

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

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 23 Apr 2010 19:04:47 +0100

> if you want  r1.r1.[name1] to be equal with r2.r2.[name2], your assumption is r1=r2.

	I think Andrew meant class (b) specifically to
	exclude r1=r2.

	ATB
	Niall O'Reilly

---

From: Douglas Otis <[email-masked]>
Date: Fri, 23 Apr 2010 11:50:13 -0700

On 4/22/10 7:27 PM, YAO Jiankang wrote:
>  do you mean that in the root zone there can have 13 NS records for
>  .com while there will only one BNAME record for .com if BNAME is
>  applied? so you think that 13 is safer or robuster than 1?

Mark made it clear, once adopted, only one resource record is able to 
appear in a parent zone.  That's impressive.   It seems the intro and 
rules should better clarify the definition of singleton, which should 
also include exceptions for DNSSEC related resources.  Perhaps I am 
wrong,  but it seems there might also be a need to ensure possible 
CNAMEs returned be merged with any previous BNAME RR.  There should also 
be a statement that this may require signing by different administrative 
entities.   There should also be a warning that targets for NS, SRV, MX 
or PTR RR should not to be below a BNAME.

Normally greater attention is given names higher in the hierarchy, 
especially since wildcards have already made it easy to diffuse a name.  
BNAME provides another diffusion property likely to have similar and 
perhaps greater impact when the top of the hierarchy is used to diffuse, 
as this will reduce effectiveness of URI normalization techniques that 
attempt to consolidate name diffusion. :^(

The Shadow approach seems more likely to produce greater stability and 
also ensures signing can be accomplished by a single entity across all 
related names, and might also reduce transactional growth.  Either way, 
a solution is necessary.

-Doug

---

From: Ted Hardie <[email-masked]>
Date: Fri, 23 Apr 2010 12:49:42 -0700

> there's something to do here, it is simply more general than that.

I am still trying to parse Eric's upstream comment, but I will point out that
there are two potential classes of variants here:  ones for which there is
a two-way mapping and one for which the transform is one way.  In the
first case labour maps to labor and labor maps to labour (or colour to color
and color to coulor).  The trick is with languages for which this is not the
case, because multiple characters collapse.  The TC/SC problem is hard
because multiple characters in TC map to the same character in SC, so going
back from SC to TC requires context.  This was pointed out as long ago
as the Salt Lake City IETF discussions on it, when James Seng and I
described one particular instance of it.  That instance is where
the "fa" in hair (頭髮）(toufa) and the "fa" in economic development (發展）
(fazhan) got mapped to the same simplified character （头发 and 发展）
respectively.  If you are presented with only 发, you can't know which
character to map to in TC by any automated means.

Luckily, I don't think we're being asked for that.  I think we're being asked to
create something that allows zone maintainers to say 發展.example and 发展.example
are declared to be equivalent (for whatever value of equivalent we mean).
But I think I understand it to be something that the zone maintainer has to
say for each equivalence and the querier has to discover for each equivalent
entry.  (There may be generation tools or online synthesis, but from the
protocol perspective, the zone maintainer declares it for each equivalence
and the querier discovers it for each.) Put another way, I cannot
assume any time I
encounter a 发 somewhere underneath 发展.example that it also maps to 發; it has to
be discovered each time, lest I screw up onthe occasion when the entry
is for a site
about the role of hair stylists in economic development.

Is this how other people understanding what we're being asked here?

regards,

Ted

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 23 Apr 2010 17:29:09 -0400

<DNSEXT chair hat=on>

On 23/04/2010 12:47 AM, Mark Andrews wrote:
> In message<[email-masked]>, Andrew Sullivan writes:
>> No hat.
>>

This assumes no new algorithms will be added until after BNAME is 
defined :-).

Mark is right, when ever we change the DNS control plane, we need to 
renumber some DNSKEY algorithms that are in use.

At the same time do we need to put in place a requirement that new
algorithm specifications list what control plane version the
algorithm is defined for?

This is starting to smell like sub-typing of the worst kind, but I do 
not know how to do it differently. Changes in the DNS control plane are
infrequent but we have had a few.

>> be unhappy with the above answer too, right?

I would phrase it differently, people unhappy with the algorithm 
allocation document realized this might happen and worried about the 
consequences.

As we saw earlier this month, there are people that want to get an
allocation of a DNS key algorithm number in order to be able to
distribute keys used by an application (HIP) with no specification
of DNSSEC use.
Question: should this be allowed or should we tell them to go to a
different number space?

One item the working group needs to get a statement/evaluation to put a
limit on explosion in hash algorithms.
AFICT for all practical purposes due to
	the structured nature of records,
	size restrictions on RRset's
and 	the relatively "short" lifetime of signatures.

there is no need in foreseeable future to have stronger hash
algorithms than x bit effective strength.
I do not know what x is but SHA-256 should be sufficient for a
long time.

The advise from NIST on hash algorithm use is aimed at the general case.
The DNSSEC use is so different that the recommendations are not
applicable.

	Olafur

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Apr 2010 17:32:51 -0400

> renumber some DNSKEY algorithms that are in use.

Sure.  But the cost of that is one of the things we are trading off in
deciding whether we make those changes.  That includes BNAME.

A

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

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 23 Apr 2010 18:02:30 -0400

On 4/23/10 1:55 PM, Andrew Sullivan wrote:
> It makes no difference.

That is not an answer. That is, if there were no other instance of the
problem but the SC/TC equivalence problem (or bug or feature, as one's
taste dictates), then "it makes no difference" would mean that working
without clue would be just as efficient as working with clue.

I presume it matters modestly that the request is not of the form "our
labels are all of length 63 - strlen("xx--"), and each character of
each label takes on a value from two totally disjoint sets", that is,
that if the length is on the order of 5 characters, and the two sets
are not totally disjoint, we actually get some problem statement
improvement.

  We can't start screwing with the protocol in
> there's something to do here, it is simply more general than that.

Heavens Andrew, this isn't about language or variants, its about some
silly sodding string generators over some alphabets. It matters from a
lot of engineering perspectives if we're looking at equivalence
classes of size 576,460,752,303,423,488 or of size 8.

Eric

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 23 Apr 2010 15:55:46 -0700

> algorithm is defined for?

Is there a reason for needing to renumber algorithms like this?  E.g.,
is there a reason you couldn't just chain identifiers together?

Suppose NSEC3 had defined a generic "NSEC3" key type.  The public key
field could then just embed another 8-bit algorithm field followed by
that algorithm's respective public key data.

So instead of

  foo.com DNSKEY ... RSA-NSEC3 [rsa-key]
  foo.com DNSKEY ... DSA-NSEC3 [dsa-key]

you'd have

  foo.com DNSKEY NSEC3 RSA [rsa-key]
  foo.com DNSKEY NSEC3 DSA [dsa-key]

Then new keys can continue to define just a specific algorithm, and
new DNS control planes also only need one new identifier each.

---

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 26 Apr 2010 15:45:42 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, April 24, 2010 12:02 AM
Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXTaliasmaybe-work

> If that's acceptable, then ok. 

I think that that is the case for synchronized domains.

if you have time, you can take a look at RFC 3743 and you will have clearer image about this.

> But I'd been led to believe that it
> proposal, implements two completely different trees.  

 two completely different trees are just instances of synchronized domains.

>In that

in Chinese character example,
script subset 1: simplified chinese
script subset 2: traditonal chinese
for every chinese character R S T, there will have simplified chinese verion R1, S1, T1;
tradional chinese version R2, S2, T2

for the second level Chinese domain registration under .org TLD,

the registrant requesting for R1S1, will get R1S1.org, R2S2.org, R1S2.org, and R2S1.org total four domain names.

there will have  R1S1.org and R2S2.org trees, which are in your case (b).
there will also have R1S2.org, and R2S1.org trees. These four trees should be same, which fall in your case (c).

so case (c) is what the synchronized domains want or the proper description.

if under the TLD T,

we hope that  R1S1.T1, R2S2.T1, R1S2.T1,  R2S1.T1,  R1S1.T2, R2S2.T2, R1S2.T2,  R2S1.T2 all 8 domain names (trees) to be same.
R1S1.T1 and R2S2.T2 are just instances of all 8 domain names (trees).

for more information, you can look at rfc3743.

for the color example,

we expect color.color, colour.colour, color.colour and colour.color four domain names  (trees) to be same.

Jiankang Yao

---

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 26 Apr 2010 16:05:33 +0800

----- Original Message ----- 
From: "Niall O'Reilly" <[email-masked]>
To: "Yao Jiankang" <[email-masked]>
Cc: "Andrew Sullivan" <[email-masked]>; "Vaggelis Segredakis" <[email-masked]>; <[email-masked]>; "'Sotiris Panaretou'" <[email-masked]>
Sent: Saturday, April 24, 2010 2:04 AM
Subject: Re: [dnsext] ICANN's "synchronized domains" and the DNSEXT aliasmaybe-work

> I think Andrew meant class (b) specifically to

he means r1=r2 (r1 and r2 are same in the meaning or exchangeable), but does not want  r1.r2.[name1] to be equal with r2.r2.[name2].

if r1<>r2,  why does there have  r1.r1.[name1] to be equal with r2.r2.[name2]?

Jiankang Yao

---

From: Niall O'Reilly <[email-masked]>
Date: Mon, 26 Apr 2010 09:58:39 +0100

On 26/04/10 09:05, YAO Jiankang wrote:
> he means r1=r2 (r1 and r2 are same in the meaning or exchangeable),
> but does not want r1.r2.[name1] to be equal with r2.r2.[name2].
> 

	Andrew understood it was a requirement from someone.
	You've made it clear it's not one of yours.

	I think that's progress: one less thing to worry about,
	unless someone else shouts.

	ATB
	Niall O'Reilly

---

From: Ray Bellis <[email-masked]>
Date: Mon, 26 Apr 2010 11:35:58 +0000

> potential effect already since RFCs 1034 and 1035.

It's often used by (less clueful) people wanting to make 'example.com' and
'www.example.com' point at the same web server.

They put an A record in the apex, and then point 'www' back to the domain
itself.

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 26 Apr 2010 11:53:03 -0400

> if you have time, you can take a look at RFC 3743 and you will have clearer image about this.

I'd read that before.  I've been led to believe that only some of the
IDLs at any given level that would normally have been generated under
3743 conventions were in fact being generated, in order to avoid a
large fan-out of many domains.  Perhaps that's the case anyway, but
it's not actually a goal, just an effect of having to compromise.

> R1S1.T1 and R2S2.T2 are just instances of all 8 domain names (trees).

And so, similarly, subsequebt delegations would have to be 

    R1S1.R1S1.T1
    R2S2.R1S1.T1
    R1S2.R1S1.T1
    R2S1.R1S1.T1
    R1S1.R2S2.T1

and so on, all the way through, right?  If that's ok, then that's
indeed case (c) and case (b) just drops out.  Yay!

Is there _anyone_ who needs case (b), then?  If not, we'll rule it out
of the list of problems we're trying to solve.

A

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

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 27 Apr 2010 11:50:56 +0800

----- Original Message ----- 
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Monday, April 26, 2010 11:53 PM
Subject: Re: [dnsext] ICANN's "synchronized domains" and theDNSEXTaliasmaybe-work

> and so on, all the way through, right?  

yes, you can delegate them all.

for those who require RS under the domain R1S1.T1,

the current practise is that we delegate R1S1.R1S1.T1 and  R2S2.R1S1.T1.

the R1S2.R1S1.T1 and  R2S1.R1S1.T1 are optional, we delegate it or reserve it for the registrant based on the registrants' requirement.

>If that's ok, then that's

+1

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 27 Apr 2010 09:32:38 -0400

On 23/04/2010 6:55 PM, Matthew Dempsky wrote:
> On Fri, Apr 23, 2010 at 2:29 PM, Olafur Gudmundsson<[email-masked]>  wrote:

Excellent question, at one point in DNSSEC development we talked
about doing KEYALG + HASHALG as two different fields in the KEY Record 
(yes this was that long ago). I think the reason we decided to not go
this direction was the fear of sub-typing (think TXT misuse).
We wanted an explicit statement what was in use and no one thought we
could possibly have an explosion in new Crypto algorithms.

This discission was firmly based on our understanding of DNS at the
time. Since then we have gained much better understanding of the "DNS 
control plane", and the implications that a changes in the control plane
affect resolvers and zones.

When we were arguing (in 2002-2003) about the type code rollover 
(KEY/SIG/NXT --> DNSKEY/RRSIG/NSEC) there was a proposal to use the
protocol field in the DNS KEY record to indicate the change (i.e. use 4 
instead of 3). I do not of the top of my head remember why the WG 
decided to renumber rather than change protocol, but it may have had to 
do with resolver could not decide what to do until after they had the 
DNSKEY record for a domain).

DNAME and wild-card clarify became major forces during DNSSEC-bis in
advancing the community understanding of the DNS control-plane issues,
NSEC3 drove the point home. The most important point is to make sure 
that validating resolvers do not try to validate answers from zones the
validator where "unknown" DNS "controls" are in use, thus we blind them 
with new algorithm numbers.

So the long winded answer to your question is: "Yes if we decided to do 
that in 2001-2002, but the train has left the station".
We still have the option of starting to take advantage of the "protocol 
number" IFF we know that current validators check the value and barf at 
unknown protocol versions, AND we replace the DS with one that includes 
the protocol number (another big control plane change).

	hope this helps
	Olafur (DNSEXT historian)

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 27 Apr 2010 10:36:53 -0700

On Tue, Apr 27, 2010 at 6:32 AM, Olafur Gudmundsson <[email-masked]> wrote:
> NSEC3 drove the point home. The most important point is to make sure that
> validating resolvers do not try to validate answers from zones the
> validator where "unknown" DNS "controls" are in use, thus we blind them with
> new algorithm numbers.

Agreed, but I don't see how this ruled out the possibility of an NSEC3
pseudo-algorithm.

> So the long winded answer to your question is: "Yes if we decided to do that
> in 2001-2002, but the train has left the station".
> unknown protocol versions, AND we replace the DS with one that includes the
> protocol number (another big control plane change).

To be clear, I'm not talking about updating the protocol number.  I
was sloppy with my previous DNSKEY example, so let me try again with
concrete examples.

Right now, isc.org has this as one of its DNSKEY records:

isc.org.		7200	IN	DNSKEY	256 3 5 (
    BEAAAAPFYUryQxBgg/QaG6iBM52jIsyn8m5o3CmIsLwzKIHEAGYGyq8M
    h9dFkwHe0ACYHV/m3PK9jYflBsMJutqCFVH532Mg08qzTByO1VbErKKR
    6mdKRTswErMuz7FXaFT2RZIKxdMtFesmP2LTLaW8drasPgR1rB+cMZmY
    RkC1IWkHwQ==
    )

Algorithm 5 is RSASHA1.

If we want to deploy BNAME and follow the same way that NSEC3 was
done, then we'll allocate a new algorithm id for RSASHA1-BNAME, which
has an equivalent key layout to RSASHA1 but indicates the zone uses
new features.  Also, for RSASHA1-NSEC3-BNAME, ECC-GOST-BNAME, etc.
Then when people want to start using BNAME, they would simply change
the 5 in the above record to the new number.

What I'm asking is why isn't a *single* new algorithm id allocated for
a pseudo-algorithm "BNAME".  Suppose it's given the id 42, then you
could change the above record to:

isc.org.		7200	IN	DNSKEY	256 3 42 (
    BQRAAAADxWFK8kMQYIP0GhuogTOdoyLMp/JuaNwpiLC8MyiBxABmBsqvDIfXRZMB
    3tAAmB1f5tzyvY2H5QbDCbraghVR+d9jINPKs0wcjtVWxKyikepnSkU7MBKzLs+x
    V2hU9kWSCsXTLRXrJj9i0y2lvHa2rD4EdawfnDGZmEZAtSFpB8E=
    )

(The base64 blob here decodes to the same byte string as the original
base64 blob, except prepended with the byte "5".)

A BNAME aware validator can then recognize the BNAME pseudo-algorithm
identifier 42, look at the BNAME "key data" and see from the first
byte 5 that it also understands RSASHA1, and know how to validate the
zone.

Similarly, the same BNAME pseudo-algorithm id can be used to avoid
having to allocate extra algorithm ids for RSASHA1-NSEC3-BNAME,
ECC-GOST-BNAME, etc.

The only issue I can potentially see is that a validator might know
how to validate some BNAME keys (e.g., ones with embedded RSASHA1 keys
but not ECC-GOST), but I don't see a reason this would actually be a
problem.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Apr 2010 10:16:52 +1000

> but not ECC-GOST), but I don't see a reason this would actually be a

While it is do able (the oid and private id space demonstates that)
you still have all the combinations of extensions to deal with.

Note when I described this every id that supported BNAME also
supported NSEC3 and plain DNSSEC.  You don't get BNAME support
without NSEC3 support.  Going forward I would not expect new
algorithms to not support both BNAME and NSEC3.

So it is the cost of implementing this vs 3 extra algorithm
numbers.

Note we will NEVER run out of algorithm numbers even if we add a
new one every day.  We will just switch move the algorithm number
into the start of the public key. <len><value> more than likely
signaled by algorithm 255.  This is why 255 is currently reserved
so we can design this escape path when we need to.

Mark