Subject: Re: [dnsext] making one zone/domain act like another

From: Jorge Amodio <[email-masked]>
Date: Mon, 14 Dec 2009 15:45:57 -0600

> Following up on two things - the recent thread on changing the DNAME and the
> discussion of Yao Jiankang's draft presented at IETF 76 - there seems to be
> a desire to be able to make two zones "behave the same."

Are you looking into that as a way of serving a particular zone/s
under different IDNs ?

Jorge

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Dec 2009 16:53:14 -0500

>Are you looking into that as a way of serving a particular zone/s

No - just making one domain "act" like another.  For whatever the purpose.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Dec 2009 14:12:42 -0800

>Are you looking into that as a way of serving a particular zone/s

It is *way* bigger than that. Think "multihoming for the DNS".

--Paul Hoffman, Director
--VPN Consortium

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 14 Dec 2009 23:33:41 +0100

I would call that "anycasting name servers". If I understand Ed
properly he hints to a desire in some circles to have two or more
namespaces look the same, the only difference being the name of a
parent.

	jaap

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Dec 2009 14:46:31 -0800

>namespaces look the same, the only difference being the name of a

Yes, I was being too glib. Think "what Jaap just said", which is much clearer than my attempted analogy.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jorge Amodio <[email-masked]>
Date: Mon, 14 Dec 2009 18:30:06 -0600

> namespaces look the same, the only difference being the name of a

I guess you mean exactly the same zone data but with different SOA
without having to duplicate the zone db, right ?

Jorge

---

From: Doug Otis <[email-masked]>
Date: Mon, 14 Dec 2009 17:09:55 -0800

> without having to duplicate the zone db, right ?

In Hiroshima, there were Japanese developers that wanted different 
ideograms to access same the same website.  They considered the issue 
analogous to upper and lower case in ASCII.  IMHO, this type of issue 
should be considered analogous to look-alike domains and not upper/lower 
case.  To be safe, this might require defensive domain registration. 
Rather than allowing the two ideograms to select the same website, it 
would be safer to wildcard (deprecate) one of the ideogram options and 
have it reference a page that explains which ideogram is supported 
within the TLD.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Dec 2009 18:28:43 -0800

At 5:09 PM -0800 12/14/09, Doug Otis wrote:
>In Hiroshima, there were Japanese developers that wanted different ideograms to access same the same website.  They considered the issue analogous to upper and lower case in ASCII.  IMHO, this type of issue should be considered analogous to look-alike domains and not upper/lower case.  To be safe, this might require defensive domain registration. Rather than allowing the two ideograms to select the same website, it would be safer to wildcard (deprecate) one of the ideogram options and have it reference a page that explains which ideogram is supported within the TLD.

Please don't hijack the thread, and please don't tell others who have studied problems a lot longer than you what their problems are analogous to.

For those who are on namedroppers but not IDNAbis: think of the two FQDNs with a single owner who wants the two names to be synonyms. ibm.com and ibm.net is a reasonable example. It does not matter how the two names came into existence; in fact, that is a rathole that is not relevant to the question.

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Dec 2009 14:06:30 +1100

In message <p0624083ec74ca3deb3c9@[10.20.30.158]>, Paul Hoffman writes:
> >In Hiroshima, there were Japanese developers that wanted different ideograms
>  to access same the same website.  They considered the issue analogous to upp
> er and lower case in ASCII.  IMHO, this type of issue should be considered an
> alogous to look-alike domains and not upper/lower case.  To be safe, this mig
> ht require defensive domain registration. Rather than allowing the two ideogr
> ams to select the same website, it would be safer to wildcard (deprecate) one
>  of the ideogram options and have it reference a page that explains which ide
> ogram is supported within the TLD.
> 
> Please don't hijack the thread, and please don't tell others who have studied
>  problems a lot longer than you what their problems are analogous to.
> 
> For those who are on namedroppers but not IDNAbis: think of the two FQDNs wit
> h a single owner who wants the two names to be synonyms. ibm.com and ibm.net 
> is a reasonable example. It does not matter how the two names came into exist
> ence; in fact, that is a rathole that is not relevant to the question.

And we made a decision 10+ years ago that "ibm.net dname ibm.com" +
adding some MX records etc. at ibm.net would be a reasonable way to
do this as it didn't require the TLD to support DNAME.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 14 Dec 2009 22:21:04 -0500

Dear colleagues,

On Mon, Dec 14, 2009 at 06:28:43PM -0800, Paul Hoffman wrote:

> For those who are on namedroppers but not IDNAbis: think of the two
> FQDNs with a single owner who wants the two names to be
> synonyms. ibm.com and ibm.net is a reasonable example. It does not
> matter how the two names came into existence; in fact, that is a
> rathole that is not relevant to the question.

Speaking both as a co-Chair, but without having consulted Olafur, and
as someone who has followed idnabis pretty carefully, I have three
things to say about Paul's remark, in decreasing order of
chair-hat-ness:

    1.  What Paul said about irrelevant ratholes is exactly right.
    This WG is about protocol, and not policy.  Ed Lewis put this
    differently up-thread, but the point is the same: it makes
    _no difference why_ the "two domains" need to be "the same".
    There is a policy-driven protocol need here, and what we're about
    is the protocol.  So let's focus on that issue.

    2.  The key questions boil down to, "What does 'synonymous' mean
    in this context?" and, "What does 'two names' mean in this
    context?"  We have to answer both of these questions at the same
    time, with respect to one another (we used to call this
    "synoptically", but I don't know if we do any more).  DNAME, for
    instance, makes "the same" mean "everything underneath".  That's
    not the desired meaning of "the same".  CNAME makes "two names"
    mean "these two identical names" without including the
    delegations; that's also not the desired meaning in this case.  We
    need to reach something that solves these two meanings at the same
    time.  

    3.  Without wearing any hat, I think ibm.com and ibm.net are poor
    examples, because they're plainly under different DNS trees.  An
    alternative example that I think should be at least comprehensible
    to English speakers is colour.example and color.example.  I don't
    think I've met a competent reader of English who's never
    encountered both "color" and "colour" forms without recognizing
    them as different spellings of "the same" word.  Now imagine that
    you had a keyboard that could input "colour" or "color" but not
    both.  This is the situation in some parts of the world with
    respect to "variants", so there is a real acute use case here.
    But even if there weren't one, synonyms in the DNS tree are an
    obvious feature, and one for which we already have two imperfect
    solutions.  We're the people with the expertise to make a perfect
    one, and if we don't then I predict someone will come up with
    something we don't like.  So, I exhort us to tackle this problem.

Best,

A

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

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 14 Dec 2009 22:28:38 -0500

Speaking only for myself, but fully aware of where I left my hat:

> do this as it didn't require the TLD to support DNAME.

That sounds like an appeal to tradition: "This is what we decided some
time ago; it was good enough then, so it's good enough now."  

Our users are saying it's _not_ good enough.  I'd like to believe that
we're interested enough in our users' problems that we have some
reason to continue as an IETF WG.  If our response to, "Users have a
problem," is, "Lovely bird!  Beautiful plumage!" then perhaps we ought
to pack up our tents and go home.  Many of you know that I am a
fervent advocate of tent-packing; but as long as we're camped out, I'd
like for us to tackle problems people bring us.  If the present
example isn't such a case, then there aren't any, and we can shut down
the WG.

A

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Dec 2009 14:49:31 +1100

> time ago; it was good enough then, so it's good enough now."  

It was a engineering trade off.  It works fine for lots of people.
I used it myself for years.

I've got no objections with defining another record which aliases
itself and its children.  Just don't change DNAME.  It works as
intended.

Mark

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Dec 2009 05:18:49 +0000

> Date: Mon, 14 Dec 2009 22:21:04 -0500
> From: Andrew Sullivan <[email-masked]>
> 
>     ...  So, I exhort us to tackle this problem.

ok.  here's the five proposals on the table, and a preference shown.

1. dname alone:

we did DNAME the way we did for the reasons mark andrews has recounted:
it had to work at a zone apex.  this was in support of bitstring labels
and their attendant PTR's, which have since been deprecated, but DNAME
is in use today and does what it does and repurposing it isn't an option.
so, dname works for searches below the dname but not "at" the dname.

2. cname alone:

a cname that points to an NS would be a nonterminal alias and doesn't
work for names beneath.  works fine for names "at", but not "beneath".

3. multiple NS's:

political minefield since it would be "two TLD's".  the policy people
would love us better if we didn't make them come up with a new counting
system for "how many TLD's does $registry have?"  but technically it
would fit pretty well, one merely expects that the below-the-delegation
servers would load the same content in two zones, or that implementors
would come up with an aliasing function that did not require wire changes.

4. dname and cname together:

if we relax the "cname and other data" restriction to allow for both a
cname and a dname at the same location so long as they have the same
target name, then searches "at" would use the cname and searches "beneath"
would use the dname.  no wire changes, and only the delegating zone needs
its servers upgraded to support the new interpretation.

5. new "ename" type:

if we define "ename" (alphabetically follows c and d, you know, e?) to
mean "at or beneath" then we could get the desired behaviour with only
upgrades to the delegating zone's servers, but with wire changes since
the synthesized cname would be accompanied by an ename not a dname.

---

of these, i prefer #4.  no wire changes, only requires upgrades to the
delegating zone's servers, and has no political/policy costs.

hope this helps.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 15 Dec 2009 17:34:15 +1100

> delegating zone's servers, and has no political/policy costs.

Relaxing CNAME and DNAME multiple use has issues.

What would be better is ENAME + EDNS option to say I understand
ENAME and the authoritative returns a ENAME or a CNAME (not both).

ENAME aware caches also return CNAMEs for non ENAME aware clients.

ENAME containing zones can only be signed with new algorithms which
are ENAME aware.  i.e. ENAME zone are treated as insecure by the
current algorithms.

Mark

---

From: Doug Barton <[email-masked]>
Date: Tue, 15 Dec 2009 00:39:52 -0800

>     is the protocol.  So let's focus on that issue.

Fair enough, but let's define precisely what it is that we're trying
to make work rather than using Rube-Goldbergian examples. Off the top
of my head it would be nice if a given string (whether IDN or
otherwise) can be made exactly equivalent to another given string
_without_ the need for multiple delegations whether we are at the
root, TLD, or domain-holder levels. Is that what we're discussing? Is
there any other intended use case?

To this issue Paul V. responded:
> if we relax the "cname and other data" restriction to allow for
> both a cname and a dname at the same location so long as they have
> the same target name, then searches "at" would use the cname and
> searches "beneath" would use the dname. no wire changes, and only
> the delegating zone needs its servers upgraded to support
> the new interpretation.

Ok, so I'm a parent, and I have NS and DS records for 'domain' and I
add 'variant1 CNAME domain'. I can see how the NS records would be
used in a direct query for 'variant1 NS' but I don't see (and once
again, this is probably my ignorance) how the DS records for 'domain'
would be useful. Aren't the DNSKEY records (and the corresponding
keys) domain-specific?

Also, continue to assume I'm ignorant for the purpose of making sure
we're all talking about exactly the same thing. What would an example
configuration of this proposal look like at the parent AND child levels?

OTOH, I don't really see how the CNAME+DNAME combination is "better"
from a _protocol_ standpoint than duplicate records at the parent
level. I understand that (as Paul pointed out) there are political
issues surrounding this, but as Andrew rightly pointed out, the
political issues are not our bailiwick.

Furthermore AFAICS the DNAME case is a non-starter for the political
AND protocol reasons that it makes the variant zone(s) "less than" the
"front end" zone as a result of the CNAME synthesis. You can't use
label.variant1.tld on the RHS of an NS or MX record because to the
resolver it will ultimately be a CNAME. (I would also argue that
adding CNAME synthesis to DNAME was a mistake in the first place, and
actually hindered rather than eased adoption, but that's a topic for
another email/thread/lifetime.)

So assuming that DNAME is not an issue at the parent, the child who
wants to do "The Right ThingTM" has two choices, DNAME + duplicate
apex records (A, DS, NS, etc.) or point the various zone definitions
at the same zone file. If DNAME is not actually a solution here we are
ultimately left with trusting the child to point the different zone
definitions at the same zone file.

>     examples, because they're plainly under different DNS trees.

I actually think that this is a really good example since as someone
who manages lots of zones in different name spaces that I would like
to easily configure to be the same I'd really like to have a better
solution for this problem, although I think that DNAME already solves
90% of it.

>     An

This use case I understand, thanks for clarifying. Unless I'm missing
something that leaves two possibilities using existing solutions at
the parent level DNAME (whether you include CNAME or not) and
duplicate delegations (again, whether that is via CNAME or not). As
above, DNAME is not a viable solution.

I'd also like to point out that any sort of solution that involves
changes in the resolvers is (also) a non-starter for both political
and protocol reasons. This problem needs to have been solved
yesterday, and the people who need the solution will not accept one
that relies on everyone in the world sitting behind an updated resolver.

So we're really left with trusting the child to do the right thing,
which means we're also back to "existing solutions are already
sufficient" in the parent, which means we can all go home.

>     something we don't like.

Too late. :)  But I digress ...

Doug

-- 

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

---

From: Jorge Amodio <[email-masked]>
Date: Tue, 15 Dec 2009 06:41:47 -0600

> solution for this problem, although I think that DNAME already solves

Yes, but I think Andrew's example about color vs colour is more representative.

When I read Edward 's question the first image that came to my mind
was IDN. For example without going to a more complex script
nandu.com, niandu.com, ñandu.com, nandú.com, niandú.com and ñandú.com
may represent the same name space in spanish.

I guess you can create multiple delegations with different
SOA/NS/DS/etc and include on each zone the same set of RRs, but that
will sort be a waste of resources on the server to handle
duplicate/n-plicate RRs on each zone and a potential for lack of
consistency between delegations.

Not really clear about how to handle DNSSEC, but my understanding is
that each delegation will require to have its own stuff, ie additional
admin load to handle the same set of RRs.

I don't see how you can easily handle this type of situations with
CNAME and DNAME.

Regards
Jorge

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 15 Dec 2009 08:13:55 -0500

On 12/15/09 12:18 AM, Paul Vixie wrote:
>> From: Andrew Sullivan<[email-masked]>
>>
...
> would come up with an aliasing function that did not require wire changes.

Paul,

There are a couple of use cases I'm aware of:

o a variant character pair in some TLD applications, such as "mumble" 
in Arabic and Farsi, where the final character "m" is, or isn't 
dotted, and the dot isn't displayed in the terminal form of the dotted 
character. Add to this the well-known SC/TC case.

o two visually distinguishable strings, such as "duck soup" and "鸭汤" 
(yā tāng), where some association, meaning, sound, color on Tuesday, 
has caused one applicant to apply for both strings, again, for a TLD.

o two arbitrary graphs, such as "polka-dots" and "polka-dots.stripes", 
where again, some association, has caused one operator to create a 
corresponding name space, which may be a sparse set of correspondences.

Some non-CJK examples that just dropped into my inbox:
"... from LDH/extended ASCII (.aero/.æro), or even a cyrillic/LDH 
example (.сом/.com) ..."

So, a plurality of labels, single operator, and a plurality of labels, 
cooperating operators, where some of the plurality is to create 
"beneficial sameness" (or prevent 3rd-party difference within some 
expectation of sameness, or simply the absence of some instance of the 
desired plurality), and some of the plurality is create "beneficial 
difference", within some expectation of difference, with the same 
3rd-party and absence non-goals.

My point is that the policy expectation you offer may not fit the use 
cases I'm aware of. The "political minefield" of "two TLDs" may not be 
a policy non-requirement. This is not a settled issue and is the 
subject of present negotiation.

My two beads worth,
Eric

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Dec 2009 14:59:25 +0000

i've switched my support to a different proposal, and also enumerated a
road not taken (or at least, a road i hope this WG chooses not to take.)

> From: Mark Andrews <[email-masked]>
> Date: Tue, 15 Dec 2009 17:34:15 +1100
> 

"has issues" is not a term of art here.  further explaination requested.

> are ENAME aware.  i.e. ENAME zone are treated as insecure by the

i now realize that there's a flaw in CNAME+DNAME which is shares with
DNAME, and that is: clients who do not understand DNAME or ENAME will have
to get all of their CNAMEs from the delegating zone (which will often be
the root).  this was not a problem in DNAME's original use case (bitstring
label PTR's) but it's a big problem for TLD aliasing (as for example in
IDN.)  (andrew, i don't see a way to keep the use case out of the design,
since as you can see, some proposals fit some use cases but not others.)

> would come up with an aliasing function that did not require wire changes.

...and policy be damned.  as a DNS implementor, i see no difficulty in
offering zone aliasing services below the delegation point.  in BIND this
would look something like

	zone "ibm.net" {
		type alias;
		other-zone "ibm.com";
	};

since the only servers who would need such configuration belong to the
zone being aliased -- that is, there are no other wire changes, no changes
in the delegating parent other than adding another NS, no changes to the
rest of the recursive world -- the only effect will be that on the primary
and secondaries for affected zones, some off-broadway hack like the above
will be necessary for any zone operator who doesn't want to "load a zone"
twice -- assuming that they load zones at all.  in powerdns i expect this
would be two DNS entry points into the same underlying database, rather
than some kind of zone-to-zone alias like i describe for BIND.

---

if we (this WG) decide that we really want wire protocol support for this
kind of aliasing, then we have to move the CNAME synthesis to be below the
delegation point.  in that case we'd define ENAME differently: as a CNAME
that functioned as an rrtype catchall for a single node in the tree.  so,
DNAME+ENAME at ibm.net's apex could collectively redirect names "beneath"
as well as types "at" the node in question.  ENAME would be like a wildcard
that only affected its owner name and only matched types not present.  it
would never be sent in normal responses, only in zone transfers, and direct
queries for the ENAME type itself, since it could only be processed on the
authority server.

i do not much like this solution, since it means CNAME synthesis for all
names in the alias zone, with no eventual rollout of ENAME-cognizant code
in recursive servers to lower the long term synthesis burden.  but if this
WG wants a wire protocol change, this is the one folks have thought of.

a similar problem exists for repurposing DNAME, which is that since it can
exist at an apex (and would have to continue to do so when repurposed, in
order to avoid putting the CNAME synthesis burden on the root servers), it
could only be processed by the authority servers, since no other server (*)
would be sure what rr types not to apply it to in the "at" case.  maybe
it's just SOA and NS, but maybe there's other stuff (DNSSEC metatypes, and
so on).  so even if we were willing to deprecate DNAME in its current form
and repurpose this codepoint, it would still have the same problem that a
DNAME+ENAME solution (as described above) would have.

(*) note that if we presume universal deployment of DNSSEC, then a signed
zone with reachable SEP's would allow full validators to prove the 
nonexistence of a type at an apex, without being authoritative for it, but
this would be screwball comedy, and i don't expect anybody to propose it.

---

From: Jim Reid <[email-masked]>
Date: Tue, 15 Dec 2009 15:38:54 +0000

On 15 Dec 2009, at 14:59, Paul Vixie wrote:

> as a DNS implementor, i see no difficulty in
> zone being aliased

How would this work when one of these two apexes is signed and the  
other isn't? BTW if both zones are signed they'd have discrete RRsigs  
and would also need different owner-names for their ZSKs and KSKs.  
That pretty much suggests a Q&D hack to clone zones will implode.

A zone is a zone: an independently managed part of the name space. A  
DNS protocol extension to "clone" zones -- if that's what we're  
talking about here -- is not the way to solve what looks to be a  
provisioning problem. Just generate N zone files (or equivalent) from  
the same data source and we're done. Hardware's cheap. DNS engineer  
time isn't.

IMO doing something clever with ENAMEs or on-the-fly CNAME synthesis  
is asking for trouble: extra ugliness with wildcards, more cacheing  
complexity, zone cut semantics for delegations under the cloned  
zone(s), new DNSSEC corner cases, etc.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Dec 2009 11:06:35 -0500

No hat.

On Tue, Dec 15, 2009 at 03:38:54PM +0000, Jim Reid wrote:
> A zone is a zone: an independently managed part of the name space. A DNS 
> protocol extension to "clone" zones -- if that's what we're talking about 
> here -- is not the way to solve what looks to be a provisioning problem. 
> Just generate N zone files (or equivalent) from the same data source and 
> we're done. Hardware's cheap. DNS engineer time isn't.

Now our problem is that we're not actually solving the use case.
We're saying, "You, zone person, solve this."

Suppose that I am the operator of example.org, and I have a local
policy that alternative spelling of "the same word" [1] must always be
delegated the same way.

If I delegate color.example.org and colour.example.org to the same
delegee, how can I be certain that color.example.org and
colour.example.org _really are_ the same?  

Ok, you say, but DNS is only loosely coherence.  Who cares?  Well,
the people who have not two such zones, but 10 "variants" that are all
"the same word" do in fact have a problem, because if they're
really different zones and not all aliases for one another, then the
looseness is exposed in a way that confuses users even more than they
are confused now.

We can, of course, just say, "No."  That's what we've done for many
years, to the extent anyone asked for this feature.

[1] Yes, yes, I know that Quine showed how preposterous an idea that
is.  The idea is nevertheless deeply entrenched in this discussion,
and we're never going to get away from it, so let's just take it as an
assumption for this example.  RFC 4290 tries to define variant
rigorously exactly to avoid having language come into it, but I think
the effect there is a useful formalism that hides the basic thing
people are trying to do.

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Dec 2009 12:00:46 -0500

>...and policy be damned.  as a DNS implementor, i see no difficulty in

...and operations be damned.  (The IETF wonders why operators drop out...)

The downside to this approach from the point of view of a zone 
operator is that having multiple copies means (at least) more memory 
( in general hardware resources) needed and/or more to weed through 
to get to the answer.  Caches have to hold more data, etc.

An operator would need to manage DNSSEC key policy for each zone, now 
instead of one DNSKEY set, there are multiple (one per copy).  Even 
if there was already one key for the copy, if there was indirection 
then that key is barely used.  If all the keys are fully used, think 
of the unneeded cryptographic over-workload.

And an operator would have to implement consistency checks to make 
sure cruft does not build up due to various hiccups over the years. 
In a large zone, cruft becomes harder to identify.

>offering zone aliasing services below the delegation point.

Which is a subset of the problem.  Two *domains* acting the same, not 
two zones.

>in BIND this

The world is not a BIND configuration file.  Yes, this would be 
simple to type into BIND, but this doesn't answer the question of 
"what is equivalence."

Equivalence...in a mathematical sense.

>kind of aliasing, then we have to move the CNAME synthesis to be below the

"Don't let the bus drivers determine the route."  This is not for the 
benefit of the WG.

As far as this from another message, Mark Andrews wrote:
#And we made a decision 10+ years ago that "ibm.net dname ibm.com" +
#adding some MX records etc. at ibm.net would be a reasonable way to
#do this as it didn't require the TLD to support DNAME.

Who is "we" and why does that decision merit weight?  The DNAME 
definition never progressed beyond Proposed Standard and is opened up 
for a revision currently before the WG.  The evidence would suggest 
that whomever "we" were 10+ years ago made an incomplete decision, 
one that has not stood the test of time.

>DNAME+ENAME solution (as described above) would have.

As we don't have an agreed upon "goal" stated, I think it is 
premature to declare any "solutions" and further "problem that a ... 
solution" has.

Thanks to Chair Andrew for driving the discussion back from policy to 
protocol and for raising the equivalence issue back up.  If 
namedroppers is to keep value as a communications channel for DNS 
protocol development, it cannot be an "anything goes" channel.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: John Levine <[email-masked]>
Date: 15 Dec 2009 17:25:04 -0000

>system for "how many TLD's does $registry have?"

My impression is that this is 80% a political problem and 20% a
technical problem.  If the goal is to serve the same zone under two
names, there's a variety of hacks as Paul just said.  (My preferred
one is to adjust the perl scripts that manage my DNS now, but tastes
vary.)

An approach that doesn't placate the TLD counters isn't going to be
adopted, righ?  So how do we figure out what they'll believe is "the
same"?

R's,
John

---

From: Jim Reid <[email-masked]>
Date: Tue, 15 Dec 2009 19:38:49 +0000

> We're saying, "You, zone person, solve this."

Yup: works for me.... :-) In this case, that is The Right Thing to do  
IMO.

It's not clear that the use case is compelling enough to be a real  
problem. And even if it is, it's still far away from justifying more  
complexity and protocol corner cases for authoritative servers and  
resolvers.

> colour.example.org _really are_ the same?

<Devil's Advocate Hat On>
Why should/could that be a problem for this WG? These are your zones  
managed according to your rules that nobody else needs to know or care  
about. [Not that I'm personalising this.] In other words, it's a local  
provisioning issue.

How someone organises their bit of the name space and the local  
policies for that are nobody else's business. That's what delegation  
means. :-) The scenario posed here is one of local policy or  
administrative convenience. That is not a sound basis to justify  
protocol changes, especially ones as far-reaching and complex as an  
ENAME RRtype could be. Besides, it's a Bad Idea (tm) to invent  
technical solutions to non-technical problems: NSEC3 anyone?

---

From: Doug Barton <[email-masked]>
Date: Tue, 15 Dec 2009 12:13:16 -0800

Eric Brunner-Williams wrote:
> cases I'm aware of. The "political minefield" of "two TLDs" may not be a
> policy non-requirement. This is not a settled issue and is the subject
> of present negotiation.

If you were trying to obfuscate your meaning here you could not have
done a better job, congratulations. :)

Doug

--

---

From: Doug Barton <[email-masked]>
Date: Tue, 15 Dec 2009 12:46:05 -0800

> We're saying, "You, zone person, solve this."

What *I* am saying is that there is no way to solve the "variant" use
case (whether that's at the TLD level or higher) without trusting the
delegee to Do The Right ThingTM.

Furthermore, I am saying that there is no way to truly make what you
and Ed seem to be describing (treat every variant as an exact,
functional duplicate of the "front end" domain in every way, for every
purpose, including DNSSEC) without changes to the resolvers, which is
problematic politically as well.

> colour.example.org _really are_ the same?  

You can't, and you never will be able to. I actually have an idea that
I'll add to the end of this message, but no matter what c!3VeR h4cKz
we come up with the end result is always going to be that we have to
trust the delegee.

So first of all, I repeat my request for a clearer definition of the
problem, political thorns and all. Those who have a distaste for
trying to craft technical solutions to solve policy disputes are free
not to participate.

Meanwhile, I knew I should have posted this last night because it's
related to the subject of your message and I don't want to sound
derivative, but my idea is a completely new RR called CLONE. In the
parent, you configure your zone thusly:

domain		NS	ns1.domain.tld.
...
domain		DS	blah

variant1	CLONE	domain
variant2	CLONE	domain
...

Since Paul already said he's feeling agreeable towards config file
support for this kind of idea, in a BIND server you might do something
like this for the variants (assuming "normal" configuration of
domain.tld):
zone "variant1.tld" { clone "domain.tld"; };
and you're done.

Now obviously the tricky part comes in the interaction with the
resolvers. This is all very rough of course, but a CLONE-aware
resolver would know what to do when it receives that response. My idea
of what it should do is to "internally transpose" the string
"variant1" with "domain" so that if an end user asks for
"www.variant1.tld" and the resolver receives a CLONE response that
says "variant1.tld == domain.tld" it can substitute "domain.tld" for
queries, DNSSEC validation, etc.; then return the answers to the end
user _with no mention of "domain.tld" whatsoever_. We would probably
want some sort of flag to indicate that it was a CLONE response, but
if we're actually going to make the two domains "the same" then there
cannot be any actual difference in the ANSWER, ADDITIONAL, or
AUTHORITY sections.

What to do with non-CLONE-aware resolvers is obviously the tricky bit.
My vote would be that if the resolver does not understand CLONE that
the authoritative server simply sends the requested information as if
the resolver had actually asked for "domain." Unless I'm missing
something obvious that would work for all purposes except for DNSSEC,
but with the root being signed with SHA-2 we've got some software revs
coming up to handle DNSSEC anyway. How a resolver signals that it does
or does not understand CLONE is left as an exercise for the reader.

I should also add that both child and parent should have useful
responses to a CLONE qtype, which could be used by interested parties
to (sort of) verify that both ends of the delegation are doing what
they are supposed to do, assuming once again that they can both be
trusted not to forge the responses.

Enjoy kicking this one around,

Doug

--

---

From: [email-masked]
Date: Tue, 15 Dec 2009 21:48:57 +0000

Ed used the term "equivalence" - and the various thread subject lines
seem to infer two distinct alternatives.

So may I ask a couple of questions here?

Is equivalence from a given POV?  a parent, a sibling, from a namespace, what POV is
used to evaluate equivalence?   in my mind, equivalence equates to multiple instances,
with none being "canonical".

wrt "cloning" this idea presupposes a canonical form of the zone - then clones are
"made"... right?

in one case; cloning, its fairly straightforward to have dispute resolution while
in the equivalence case, its not nearly so straightforward.

So which is it?

--bill

---

From: Douglas Otis <[email-masked]>
Date: Tue, 15 Dec 2009 14:08:42 -0800

On 12/14/09 6:28 PM, Paul Hoffman wrote:
>> ideograms to access same the same website.  They considered the
>> issue analogous to upper and lower case in ASCII.  IMHO, this type
>> of issue should be considered analogous to look-alike domains and
>> not upper/lower case.  To be safe, this might require defensive
>> domain registration. Rather than allowing the two ideograms to
>> select the same website, it would be safer to wildcard (deprecate)
>> one of the ideogram options and have it reference a page that
>> explains which ideogram is supported within the TLD.
>
> Please don't hijack the thread, and please don't tell others who
> have studied problems a lot longer than you what their problems are
> analogous to.
>
> FQDNs with a single owner who wants the two names to be synonyms.
> ibm.com and ibm.net is a reasonable example. It does not matter how
> the two names came into existence; in fact, that is a rathole that
> is not relevant to the question.

Paul,

Multiple NS records appear the best solution to handle semantically or
visually similar domain names. From your reaction, this does not meet
your expectation.  With DNSSEC, it would be difficult to have two
different ASCII representations of a domain declared canonically equal,
beyond allowing case-insensitivity.  Different domains require different
zones.  When done at the TLD, this requires multiple TLDs.

That does not mean there is nothing to be done.  The results of
any process that attempts to merge two names could be affirmed in a
manner similar to that proposed in the TPA-Label scheme.  Any domain
would be able to authorize alternate domain use within a single DNS
transaction. See:

http://tools.ietf.org/html/draft-otis-dkim-tpa-label

When done in a major way, this could use an "Alternate Name
Authorization Resource Record" (ANA-RR).  A CNAME at a special prefix
could establish desired aliases for use by other protocols.

Either introducing an ANA-RR or simply NXDOMAIN for non-preferred forms
of a name is currently supported by DNS.  For example, DNS will not
resolve "Jon's.vlog.com".  There is not an urgent demand for a mechanism
to make IBM.COM and IBM.NET equivalent domains.  Nevertheless, a
specialized label such as _alias.IBM.NET IN CNAME IBM.COM could then be
affirmed with an _U3WCVMQTCOY4AFHQJFX4LJFISSUIHZA5.IBM.COM IN ANA-RR 
which authorizes the IBM.NET references.

Alternatively, a TLD could create contracts requiring replicate zones
that automatically generate the entire set of desired domain aliases.

-Doug

---

From: "Health" <[email-masked]>
Date: Wed, 16 Dec 2009 09:16:35 +0800

from the discussions, there are two words for this issue: equivalence, visual similarity

case 1, under the same language environment, two words are equivalence(also visual similarity), for example color == colour in English
case 2, under the different language environment, two words are visual similarity, for example a cyrillic/LDH 
example (.сом/.com)

Everyone speaks something in the same language envirionment, so most internet users prefer to solve the case 1 and make the zone identical or equivalence.

for case 2, we may or may not use the solution used in case 1.

so case 1 and case 2 may require different solutions.

Yao Jiankang

----- Original Message ----- 
From: "Eric Brunner-Williams" <[email-masked]>
To: "Paul Vixie" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 15, 2009 9:13 PM
Subject: Re: [dnsext] making one zone/domain act like another

...

Paul,

My two beads worth,
Eric

---

From: Florian Weimer <[email-masked]>
Date: Wed, 16 Dec 2009 10:13:12 +0000

> delegating zone's servers, and has no political/policy costs.

Except that the names are not equivalent.  Any CNAME-based solution
currently has that problem because section 10.3 of RFC 2181 requires
that MX and NS targets are canonical.  There used to be SMTP
implementations which could be configured to refuse delivery to
non-canonical MX hosts.

So you'd need to avoid putting an alternative encoding of a domain
name in the RR data part.  (The RFC 1123/2181 requirement was also
picked up by the SRV RR, and probably others.)

I think it is a bit hard to explain that you can send mail to
<[email-masked]>, but you cannot put mx.xn-1234.example into
the zone file (assuming that xn-1234 is not the canonical encoding).
But maybe this is good enough.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Joe Abley <[email-masked]>
Date: Wed, 16 Dec 2009 12:00:51 +0000

> colour.example.org _really are_ the same?  

A clarifying question from an IDNA-ignorant thread-lurker. I am just trying to understand the problem statement.

Suppose I am a person that needs to use and see and understand "colour" rather than "color".

I send a query "MAGENTA.COLOUR.EXAMPLE.ORG IN MX?" and get the answer MAGENTA.COLOUR.EXAMPLE.ORG 3600 IN MX PALETTE.COLOUR.EXAMPLE.ORG".

Suppose instead I am a person of "color". I send the query "MAGENTA.COLOR.EXAMPLE.ORG IN MX?". (a) Which answer should I expect? (b) Which answers are valid?

  MAGENTA.COLOR.EXAMPLE.ORG 3600 IN MX PALETTE.COLOR.EXAMPLE.ORG
  MAGENTA.COLOR.EXAMPLE.ORG 3600 IN MX PALETTE.COLOUR.EXAMPLE.ORG
  MAGENTA.COLOUR.EXAMPLE.ORG 3600 IN MX PALETTE.COLOR.EXAMPLE.ORG
  MAGENTA.COLOUR.EXAMPLE.ORG 3600 IN MX PALETTE.COLOUR.EXAMPLE.ORG

In other words, are we just providing equivalence in the namespace for the purpose of queries, or are we also doing so for answers?

Joe

---

From: [email-masked]
Date: Wed, 16 Dec 2009 12:21:35 +0000

> In other words, are we just providing equivalence in the namespace for the purpose of queries, or are we also doing so for answers?

	if, as Ed suggests, we are looking at the mathmatical definition of equivalence,
	then I would suggest that we would need equivalence for queries and responses.

	imho of course.

--bill

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 16 Dec 2009 08:03:05 -0500

+1 on equivalence.

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 16 Dec 2009 14:08:30 +0000

Florian Weimer wrote,
> But maybe this is good enough.

	I expect that it would be.

	Besides, with only one zone to maintain, the (operational) rules
	for what is allowed on the RHS of any RR are easy to write.

	VBR,
	Niall O'Reilly

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 16 Dec 2009 14:46:40 +0000

On 15 Dec 2009 at 19:38, Jim Reid wrote:
> Yup: works for me.... :-) In this case, that is The Right Thing to do IMO.
> 
> problem. 

	That's not how I see it, Jim, but (what I see as) your
	underlying point is significant.

	It's pretty clear that a real problem is involved.
	What's not clear to me is whether this problem is better
	solved (for some definition of "better" 8-P ) by the
	"zone person" or in the protocol.  It's seems to me that,
	for clarification, the "cost" on either side of this
	provisioning-versus-protocol trade-off needs to be exposed.
	To this end, I have two questions, each apparently involving
	a wire-impact-free solution.

	To the zone persons:
	What makes parallel delegation not an acceptable solution
	for you?

	To the protocol persons:
	what breaks if paired CNAME and DNAME are allowed and
	systematically used for pseudo-delegation of any variant
	encoding(s) in parallel with normal delegation of the
	canonically encoded zone?

	ATB,
	Niall O'Reilly

---

From: Edward Lewis <[email-masked]>
Date: Wed, 16 Dec 2009 10:16:52 -0500

>>  In other words, are we just providing equivalence in the namespace for
>>  the purpose of queries, or are we also doing so for answers?

>	if, as Ed suggests, we are looking at the mathmatical definition
>	of equivalence, then I would suggest that we would need equivalence
>	for queries and responses.

When I was learning DNS and writing the early DNSSEC code, the 
following little sidebar set the standard for what is "correctness" 
in a response.

Let's say Joe is a system admin in a large organization.  He 
configures a new server to be at 192.0.2.213.  He walks down to 
Bill's office, the guy who runs the DNS servers and says the new host 
is on 192.0.2.218 - an obvious error.

When Bill enters this into the DNS and then signs it with DNSSEC, the 
result is that the 218 address is signed (source authenticity, 
integrity and all that).

What won't happen inside the DNS is a correction when connects fail 
to be made to 218.  Joe has to be alerted that the address is wrong, 
he will go to Bill and request the change.  (Even if Bill hears there 
is a problem first, he'd call Joe to get the correct address.)

The moral is that correctness of any response within the DNS is 
limited to the correctness of what is entered into the DNS.  DNSSEC 
(or any other checks) won't overcome this.

So, looking at the example (Andrew/Joe/Bill), the DNS itself knows of 
no special relationship between color and colour.  The special 
relationship is established external to the DNS.  The DNS is told to 
make the two "be equivalent."

Outside the DNS space, there is talk that I would interpret as "we 
want these two zones to be equivalent."  Inside the DNS space, we can 
craft a mechanism or technique to make two domains be equivalent.

Of course, first we need to the equivalence function.

For the outside of the DNS space, users of DNS want to make sure they 
get what they want.  If the equivalence function is not what they 
have in mind, then nothing will be successful (like opening a 
connection to 218 when the host is at 213).  For the inside of the 
DNS space discussions, the equivalence function will be what 
determines what technique or mechanism provides the desired outcome.

That is why I am calling for the definition of equivalence.

To the inside of DNS, it's not that important whether you want these 
examples to be equivalent or not:

(use case[0])
(audible)      our-eyes.tld. and hour-eyes.tld.
(writing)      <zhong1><guo2-Trad>. and <zhong1><guo2-Simp>.
(visual)       (the example of com in Cyrillic and ASCII)
(dialect)      color.us. and colour.co.uk.
(slang)        take-out-food.us. and take-away-food.sg.
(biz relation) moms-spring-water.org. & subsidiary34.major-beverage-corp.com.

[0] - I probably missed some reasons.

That choice is policy from the outside of the DNS.  The inside of DNS 
just has to figure out what the diff is between queries relating to 
the two domains that are supposed to be "equivalent."

(Outside - the non-technical components of the protocol; inside - the 
network traffic on port 53 plus the software algorithms in the 
servers and other elements.)

---

From: Edward Lewis <[email-masked]>
Date: Wed, 16 Dec 2009 10:25:15 -0500

>	What makes parallel delegation not an acceptable solution

This appears in a rant I wrote yesterday.

1) Extra resources to maintain full copies of zones on-line

    The marginal cost of answering a response increases if I need more
    machines, memory, license, power, etc. to handle the same query load.

2) Extra cryptographic work load to maintain DNSSEC

    Let's say 5 M signatures do a zone, and just 6 do the "pointer" to it.
    If I need to have two full copies, that means I go from 5,000,006 to
    10,000,000 signatures to manage.

3) Having to ensure no cruft builds up the separate copies

    In an age of large, high churn zones, deltas are used.  Once a
    wrong record gets in one place, it will stay there until discovered.

>	canonically encoded zone?

I will listen to other's responses to this, I have some in mind, but 
haven't been thinking as much about this.

---

From: Jim Reid <[email-masked]>
Date: Wed, 16 Dec 2009 16:00:30 +0000

>   machines, memory, license, power, etc. to handle the same query  

True. But is that marginal extra cost significant? And if so, does  
saving that extra cost justify more complexity and probably much  
greater costs for everyone else? It's all very well to consider the  
overheads on those publishing DNS data. But that should be traded off  
against the extra overheads for those reading (and validating?) that  
data, particularly for operating and troubleshooting resolvers.

>   10,000,000 signatures to manage.

Computers are good at repetitive tasks. :-)

Presumably the "just 6" signatures refers to some sort of signature  
over a DNAME for a TLD. But what would that actually mean in practice  
for validation? Suppose foo is a DNAME for the signed bar TLD. How  
will my resolver validate www.ed.foo when there's no ZSK/KSK for .foo  
and the chain of trust goes through .bar? Is that likely to create  
unwanted surprises for the resolver or application or end user? And  
what will be the impact on signing/validation for a synthesised CNAME?

>   wrong record gets in one place, it will stay there until discovered.

Cruft and entropy doesn't go away when there's just one zone. Besides,  
when there's cruft in the back-end registry database, it will find its  
way into the zone file. So when the zone is cloned, the same cruft  
gets cloned too.

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Thu, 17 Dec 2009 11:03:42 +0200

Dear Edward,

Speaking as an "outside of DNS" according to your description I have to say
my opinion on what equivalence is to me:

If I wish to visit cnn.com, I can type it as CNN.COM, www.cnn.com,
WWW.CNN.COM or any other combination without problem, it will almost always
resolve. Of course www.cnn.com=cnn.com is an equivalence that is not a DNS
function but for now please disregard this.

If I wish to send an email, I can send it to [email-masked] or [email-masked], it
will always arrive.

I have many times heard the argument that a domain name is just a tag for a
numeric address, I have used this argument many times myself. However, it
happens that in Latin this identifier is very flexible and serves correctly
the use of a language written in Latin characters.

If I do the same in a Greek domain name it will be different in small
letters than the domain in capital letters because of the accented tonos
letter that we use in almost all our words in small letters. If you use the
final sigma at the end of the word (every male name and lots of other words)
the domain will be different than the domain name in capital because in
capital we use the normal sigma.

For each domain with a final sigma and a tonos you will have to use four
different domain names to be sure that the user will type the word as a
normal user would and arrive at the web page or send an email that is
expected to reach a destination some day.

It is not the same with color and colour. We do not wish to equalize two
words that clearly are distinctive. We just wish to provide the user with
the option to use the language as normally as possible. For this we tried to
use DNAME - it is not good enough. We have to have a stronger, more robust
solution that takes care all of the above problems. 

I am following your discussion with great interest and I wish to express my
thanks to all who have put significant thought on the issues this proposal
faces. I would like to ask you not to be negative to this proposal. You do
not face the issue and it is normal to be skeptic about a solution to a
problem that does not exist for you, for us though it is a major issue. 

Kind Regards,

Vaggelis Segredakis
Administrator of the .GR Top Level Domain
Institute of Computer Science
Foundation for Research and Technology - Hellas
Tel. +30-281-0391450
Fax +30-281-0391451
Email [email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Edward Lewis
Sent: Wednesday, December 16, 2009 5:17 PM
To: [email-masked]
Cc: Joe Abley; Andrew Sullivan; [email-masked]
Subject: Re: [dnsext] cloning zones

(use case[0])
(audible)      our-eyes.tld. and hour-eyes.tld.
(writing)      <zhong1><guo2-Trad>. and <zhong1><guo2-Simp>.
(visual)       (the example of com in Cyrillic and ASCII)
(dialect)      color.us. and colour.co.uk.
(slang)        take-out-food.us. and take-away-food.sg.
(biz relation) moms-spring-water.org. &
subsidiary34.major-beverage-corp.com.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Dec 2009 12:00:37 -0500

No hat.

A couple things from your mail.

> function but for now please disregard this.

Well, _no_, we can't disregard it.  Just a few years ago, it was by no
means predictable that if you used your web browser and connected to
port 80 of whatever resolved to cnn.com, you would get exactly the
same page as you would get if you used your web browser and attached
to port 80 at whatever resolved to www.cnn.com.  They're different
names in the DNS, and at the time, since most of the web population
was relatively clueful about these things, nobody was surprised that
these were different.  

Over time, there evolved the practice that people would add an A
record for the domain (in this case, cnn.com) that was equivalent to
the original target host (in this case, www.cnn.com).  It's not,
however, even a reliable convention today.  Importantly, it has
_nothing at all_ to do with how the DNS works, and everything to do
with how the zone administrators run their zones.  

The case-insensitive matching is, I grant, a different problem.  But
that is not exactly an issue in IDNA2008, because under that proposal
the uppercase versions aren't legal anyway.  So nobody can reach
them.  (I'm aware that this is the wrong list for debating the details
of IDNA2008; I'm just trying to make clear the ways in which the
plain-DNS/IDNA2008 analogy breaks down.)

> If I wish to send an email, I can send it to [email-masked] or [email-masked], it

But note that there is no guarantee that [email-masked] and [email-masked]
are the same address, because the local-part rules are a local matter.
Just about nobody knows this, and servers for the most part do
something sane rather than what is strictly allowed by the protocol.
So from the same premise, we might be able to conclude that we should
leave well enough alone here, because zone operators already have
enough facilities to be able to put _in the DNS_ exactly what is
needed to support the use case, even though it will be awkward.  (If I
understand him correctly, for instance, this is what Jim Reid is
arguing.)

> words that clearly are distinctive.

Why are these clearly distinctive?  In Canadian English according to
at least one handy dictionary I have, those are the same word, period.
In British and American English, one of them is a misspelling, but not
in Canadian English.  The only convention is that you have to pick one
in a given document and stick with it.  (This ambiguity is exactly why
I picked them as an example.)

> solution that takes care all of the above problems. 

Chair hat back on.

My reading of the remarks in this thread is that "all the above
problems" and "takes care of" are still underdefined.  So a more
complete, painfully-outlined problem statement is, I think, still
needed.  Perhaps someone could write up an Internet Draft with a
complete outline of all the issues that we are trying to solve.

Best regards,

A

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Dec 2009 12:26:02 -0500

At 16:00 +0000 12/16/09, Jim Reid wrote:

>True. But is that marginal extra cost significant?

Yes.  Well, nothing in operations is absolute - the real answer is it 
could be, depending on where in the capacity step-curve the system is.

>And if so, does saving that extra cost justify more complexity and
>probably much greater costs for everyone else?

That wasn't part of the question.  Come to think of it, that question 
cuts both ways.

>It's all very well to consider the overheads on those publishing DNS data.
>But that should be traded off against the extra overheads for those reading
>(and validating?) that data, particularly for operating and troubleshooting
>resolvers.

Well, I would think considering that, then the costs on duplicate 
zones are even higher.

It's like this.  When I run into a bug involving a zone of 2M(illion) 
names, my first reaction is to build a zone of 50 names and see *how* 
I can replicate the issue.  I do this because, once I am successful 
in replicating the problem, the time it takes to "twiddle, load, run, 
test" is much shorter when you are loading 50 names and not 2M. 
Further, when it comes time to make the bug report, a zonefile of 50 
can be cut and pasted into email easier than 2M.

(BTW, I just did that again this week.)

>Computers are good at repetitive tasks. :-)

Computers don't write checks for support licenses, power bills, and 
rack space.  (In the case that a doubling means I need another rack 
or power circuit or...)

>Presumably the "just 6" signatures refers to some sort of signature over a
>DNAME for a TLD. But what would that actually mean in practice for validation?

"Just 6" refers the approximate number of signature records a tiny 
zone needs.  Like SOA RRSIG, NSEC RRSIG, NS RRSIG, DNSKEY RRSIG.  I 
probably got 6 from usually counting two DNSKEY RRs and/or NSEC3PARAM 
RRSIG.  (Those are all "large" records in a small zone, other records 
have negligible impact.)

>Suppose foo is a DNAME for the signed bar TLD. How will my resolver validate
>www.ed.foo when there's no ZSK/KSK for .foo and the chain of trust 
>goes through
>.bar? Is that likely to create unwanted surprises for the resolver or
>application or end user? And what will be the impact on signing/validation
>for a synthesised CNAME?

Someone really needs to write a textbook quality tome on DNSSEC 
someday.  This is basic DNSSEC stuff, independent of the thread's 
topics.

If you have X CNAME Y, Y CNAME Z, and Z CNAME W, with a trust anchor 
covering X and Z but not Y, then you can validate the first CNAME, 
the last CNAME, and if you have an anchor over W, the data at W.  But 
you can't verify Y CNAME Z.

What is the unwanted "surprise" here?  If you "traverse" through an 
unsigned zone the traversing is not DNSSEC protected.  But it's like 
going to a web page using DNSSEC for the HTML file but then accessing 
advertising links that don't use DNSSEC.

DNSSEC protects DNSSEC data, when you try to look at it from the 
point of view of an application, you'll get lost.

>Cruft and entropy doesn't go away when there's just one zone. Besides, when
>there's cruft in the back-end registry database, it will find its way into
>the zone file. So when the zone is cloned, the same cruft gets cloned too.

Yes, and that is my point.  Recently in an exercise on some old data 
I discovered that 1 in 10,000 NSEC3 records were in error.  It took 
me two weeks of reverse engineering the hashes (don't get excited 
NSEC3 fans - I ran all the names of the zone -which I had- through a 
tool to see the hashes, then matched up the hashes - I didn't crack 
the crypto) to identify the 200 names.  The names weren't otherwise 
distinguishable.

Imagine if I had to do that in two places (zones).  (Yes, if the bug 
was in the database, the names would be the same.  But if the bug was 
in the update/load process...)

The point is, the number replicated zones is a multiplier on the load 
of operations management.

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 17 Dec 2009 12:41:14 -0500

> something sane rather than what is strictly allowed by the protocol.
Just for the sake of completeness...

RFC 5321, Section 2.4:

However, exploiting the
   case sensitivity of mailbox local-parts impedes interoperability and
   is discouraged.  

							- Kevin

---

From: Jim Reid <[email-masked]>
Date: Thu, 17 Dec 2009 18:05:45 +0000

> understand him correctly, for instance, this is what Jim Reid is

Indeed.

A clearer problem statement would be very helpful. Though on the face  
of it, I think it's going to be hard enough to come up with a viable  
definition of zone equivalence let alone a way of inventing a protocol  
to support that.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 17 Dec 2009 19:51:29 +0000

> From: Jim Reid <[email-masked]>
> Date: Thu, 17 Dec 2009 18:05:45 +0000
> 
> A clearer problem statement would be very helpful. Though on the face of
> it, I think it's going to be hard enough to come up with a viable
> definition of zone equivalence let alone a way of inventing a protocol to
> support that.

at its highest level, a problem statement would have to acknowledge the
rolling nature of all dns upgrades, and that without client side awareness
for the first five to ten years, we're left pondering only statements of
problems which have no good solutions.  a problem statement that failed to
take account of the long tail of client upgrades would be useless to us,
and one that does take this into account will rule out many proposed
solutions that i've seen proposed or defended in this thread.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Dec 2009 15:22:09 -0500

>problematic politically as well.

To put the cart and the horse in the right order, I am not stating 
how this should work, I am repeating what I am hear from others in 
the effort to understand the problem to solve.

First - I have been asking "what does it mean to make two DOMAINS act 
the SAME."  Not "why" and I really don't care about the motivation.

>trying to craft technical solutions to solve policy disputes are free

Political thorns?  No, let's not do that here.  Remove the reasons 
for trying to make two domains act the same.  Stop thinking in terms 
of zones even.

Let's say we have X DNAME Y in the attempt to make all queries in the 
X domain be the same as asking the Y domain.  The query "X/IN/DNAME" 
will of course not be the same as "Y/IN/DNAME" - and if you define 
equivalence to exclude that difference you have succeeded (or are one 
step closer).

>Enjoy kicking this one around,

Maybe the problem is different.  Maybe it's not a matter of copying 
data space into another.  Maybe what we need to define is some sort 
of query redirection mechanism.  CNAME and DNAME are the first two 
steps there.  The problem with anything in the data space is that old 
servers don't know them.  If the new types have no special 
processing, then it's okay, we have that RFC on handling unknown 
types.

The problem is the special processing.  Maybe we should recognize 
that and keep the data space only as dirty as it already is.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 17 Dec 2009 13:53:33 -0800

> 1) Extra resources to maintain full copies of zones on-line

This is only an issue if you precompute DNSSEC signatures.  Otherwise,
a nameserver can easily be built that knows to respond to
colour.example.com queries by looking for color.example.com records,
and then rewriting the domain names before sending the response to the
client.

> 2) Extra cryptographic work load to maintain DNSSEC

This is again only an issue for precomputed DNSSEC signatures.  CPU
requirements for online authentication grow proportional to the number
of queries, not the number of unique qnames.

> 3) Having to ensure no cruft builds up the separate copies

Again not an issue if the authoritative servers handle rewriting the
domain names dynamically.

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Fri, 18 Dec 2009 11:00:27 +0200

Dear Andrew,

My use of English might has been misleading because I thought I have already
explained the problem. I will try to do it again with some examples:

The domain names (you can use our converter
https://grweb.ics.forth.gr/AceConverter?lang=en to view them in Greek)

xn--0xadhj4a.gr and
xn--0xaafjl.gr

are the two variants necessary today for a user to use the word tax (φόρος)
as a domain name. Why they are necessary? Because the first one is the word
with ό (small omicron with tonos) where the second is without the tonos. You
use the first version if you type the word using small letters but the
second one if you typed it in capital. You mentioned that the IDNA2008
eliminates upper case letters from the browser line. This is not exactly
what happens; the protocol eliminates capital letters mapping to lower
letters inside the protocol itself. The software of the browsers etc will
still be mapping the capital letters to small before PUNYCODE and sending
them to the DNS. This way the problem still exists because for the user who
inputs the domain in caps the first domain will be used where for the user
who inputs it in small letters the second domain will be used.

In the IDNA2008 the problem doubles. Each one of the domains described
becomes two variants: One with the small final sigma (a sigma used as the
last letter of a word) and one with a normal sigma (for the ones who type it
with a capital letter sigma which will be converted to a small sigma).

You can accept all the above as a sad fact of life and ask the user to set
up all four domain names; Web servers, mail servers, zone files, ftp servers
etc. Would you consider it normal this way? How fragile this becomes as a
setup and how complicated? What would be the cost of it?

A usual user does not know how a browser is operating beneath the surface;
He installs it, he runs it and voila! Web pages appear! He does not setup
ips anymore, someone came up with DHCP. Everything is created with the human
dimension built into it, taking in account the user experience. 

This is not the case if you wish to use variants. Without xNAME variants are
not fully operational, they cannot serve as a four-in-one bundle in our
example. You have to ask the user to adapt to the protocol or pay for
expensive and fragile services. We really wish this stops being the case. We
would like to be able to assist the user with a proper workaround since this
happens because of the IDNA protocols and it is not a user fault.

The specs for the xNAME?
Name1 xNAME name2 means that the whole tree (+ that level) are working as a
single name.
ftp name1 = ftp name2
http://name1 = http://name2
http://www.name1 = http://www.name2
email user1@name1 = email user1@name2

IETF proposed the bundles as a solution to variant registration (RFC4290),
some registries followed because there was no better alternative. Now that
we have worked for some years with these bundles, we need a real tool to
make them elegant and easy to use; xNAME is a necessity.

I would very much like to be more technically competent to draw in detail
and with precise specs our requirement but I pretty much know you all have a
picture of what we are asking for.

Best Regards,

Vaggelis Segredakis

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Thursday, December 17, 2009 7:01 PM
To: [email-masked]
Subject: We need a better problem statement (was: [dnsext] cloning zones)

No hat.

Chair hat back on.

Best regards,

A

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

---

From: Doug Barton <[email-masked]>
Date: Fri, 18 Dec 2009 01:56:19 -0800

Vaggelis,

Thank you for helping to make the requirements more clear. A few
comments below.

> https://grweb.ics.forth.gr/AceConverter?lang=en to view them in Greek)

You might suggest to your webmasters to do some testing of that page
in Firefox. It does not render well for me (although it may be a
FreeBSD-Firefox issue, I haven't tested it in Windows).

> xn--0xaafjl.gr

Both of these names are displayed in lower-case letters using the
punycode converter. Based on your discussion below about how IDNA 2008
mandates everything in lower case, that seems to be a feature,
although it's amazing to me that IDNA 2008 would mandate that.

I'm snipping your excellent discussion of with/without tonos and the
terminal sigma. I studied ancient greek in college so I actually
understand the terminal sigma issue pretty well. :)  I also agree with
the point that I think you're making which is that no matter what form
of the word that the user types each form should function the same
way. This idea of "same" should, from the standpoint of the end user,
function in exactly the same way that cnn.com/CNN.COM/cNn.Com/etc.
function in the DNS today. Would you agree that this is a correct
statement of the problem? What you write below seems to indicate that
my perception is correct, but it would be nice if you could confirm it.

> email user1@name1 = email user1@name2

Ok, given this understanding of the requirement, have you had a chance
to examine my proposal for the CLONE RR? You can find the description
at
http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg03106.html.
I believe that if we could implement that it would fulfill the
requirement of "the same" with a minimum of delay and/or disruption.

To be clear, that proposal would require the registry to make software
changes in their authoritative DNS servers (which is going to have to
happen no matter what technical solution we embrace), and the
registrant to set up the clone configuration for each of the variants.
The latter should be reduced to anywhere from one to a few lines of
configuration in their name server per variant. Registrars or
registries that provide name service for their customers could of
course automate this process, so to the "average" registrant it would
be fairly painless.

As Paul Vixie and I have both pointed out on this thread, there is no
solution that can give 100% "sameness" that does not involve changes
to the resolvers that Internet end users currently depend on. One
benefit of the CLONE idea is that except for DNSSEC the variants would
all look and act exactly as if the what the user typed in was the
"real" domain. In order for the CLONE idea to work for DNSSEC the
resolver would have to understand what to do with the CLONE RR.

If this sounds like a direction that would be worth pursuing from your
perspective it would be useful to know that. If there are deficiencies
in the idea it would be useful to know that too. :)  Of course if
anything in the CLONE idea is not clear, please let me know.

Regards,

Doug

--

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Fri, 18 Dec 2009 12:26:10 +0200

Hello Doug,

Thank you for your reply

>my perception is correct, but it would be nice if you could confirm it.

This appears to be a correct statement, especially if you succeed on this
for all service, email, ftp, http etc.

>requirement of "the same" with a minimum of delay and/or disruption.

I looked at your proposal again. I hope this proposal does not mean that
some registries will have std Bind and some have a modified one. This road
appears to be very slippery and the registries that will have to modify
things will soon find themselves with problems. Whatever is decided should
be a part of regular and steady releases of software, otherwise we could
even today hack things up and terminate this discussion. I might have
misunderstood something though so please clarify if I have.

Best Regards,

Vaggelis Segredakis

---

From: Doug Barton <[email-masked]>
Date: Fri, 18 Dec 2009 03:16:05 -0800

> misunderstood something though so please clarify if I have.

I think I understand your concern correctly, so let me try to restate
what I am proposing in a way that will address it. What I wrote in my
previous e-mail message is a "rough draft" of an idea that that I
would like to see turned into an Internet-Draft, and then an RFC that
could be implemented as a standard part of the DNS protocol by all
software authors.

That said, it's very important for everyone to be on the same page in
terms of what will be required on the technical end to solve this
problem. The DNS protocol (and by extension, the existing software)
does not currently include what is needed to solve the problem of
making variants act "the same" as other domains. Even the simplest
change to the current protocol (the CNAME+DNAME idea) would require
changes to the authoritative server software of the parent domain
(whether the parent is a TLD or not).

The benefit of the CLONE idea is that it can be implemented fairly
easily in the authoritative name servers of the parent and child zone
operators and this will give you "the same for every purpose except
DNSSEC" without depending on the resolvers being updated.

The one technical solution that does exist right now is the "multiple
delegation" idea, which requires that the parent to delegate each
variant separately, and the child to somehow duplicate the zone data
for each variant. This idea would also work for everything except
DNSSEC for the variants, however it creates a comparatively large
maintenance problem for the child zone operator. FWIW, I do believe
that there are technical solutions to the maintenance issues that
render them fairly painless, however the fact that the "multiple
delegation" idea does not handle DNSSEC for the variants means that it
is not a full solution to the problem of making the variants totally
"the same." The fact that the "multiple delegation" idea is also
politically problematic effectively makes it a non-starter.

I hope that this makes the landscape more clear.

Doug

--

---

From: Andrew Draper <[email-masked]>
Date: Fri, 18 Dec 2009 11:38:02 +0000

I thought I understood the clone idea but now I'm confused.

How does it differ from eNAME, which as I understand it is pretty much
equivalent to CNAME+DNAME?

If clone happens all on the server for tld then why does the child
server (for domain.tld) need to do anything different with zone loading
tricks?

As I understand it the problem needs to be solved for three classes of
resolver:
- Those that are new and understand the new protocol (whatever it is)
- Those that are not DNSSEC aware
- Those that are DNSSEC aware but don't understand the new protocol

Lets call these NEW, NON-DNSSEC and CURRENT respectively.

New resolvers clearly won't have any backwards compatibility concerns.

CNAME synthesis can be used for non-dnssec resolvers in both cases, but
puts the load on the parent server if there's a zone cut (as there
usually will be)

But I don't see a solution for current dnssec aware resolvers in either
CLONE or eNAME.

Andy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Doug Barton
Sent: 18 December 2009 11:16
To: Vaggelis Segredakis
Cc: 'Andrew Sullivan'; [email-masked]
Subject: [dnsext] Re: We need a better problem statement

Doug

--

To ensure compliance with requirements imposed by applicable law, we inform you of the following:

Name of Company                      Altera Europe Limited
Company Registration #             2647731
Place of Registration                  Cardiff, Wales (Companies House)
Registered Office Address          Holmers Farm Way, High Wycombe, Buckinghamshire. HP12 4XF

Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure.  If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution,  or copying  of this message, or any attachments, is strictly prohibited.  If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments.   Thank you.

---

From: Doug Barton <[email-masked]>
Date: Fri, 18 Dec 2009 04:15:08 -0800

> server (for domain.tld) need to do anything different with zone loading

Did you read the post where I described the idea? It's at
http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg03106.html.
Apparently I did a very poor job of describing my proposal, I'll try
to clarify it here.

I'm not proposing that CLONE happen only on the parent's authoritative
servers. My proposal has 2 (well, 2.5 really) components.
Authoritative for the parent, authoritative for the child, and resolvers.

For the parent, CLONE is an in-zone RR. Such as:
label		NS	ns1.label
		NS	ns2.label
		DS	<blah>

variant1	CLONE	label
variant2	CLONE	label
etc.

In the authoritative server for the child you could either create
"regular" zone definitions in the configuration file and "simple" zone
files that specify "only" a CLONE RR (for currently unspecified
definitions of "simple" and "only") or preferably a configuration file
option such as (for a BIND'ish example):
zone "variant1.tld" { clone "label.tld"; };

The CLONE-aware resolver would do <something> to signal such to the
authoritative servers, who would then return appropriate CLONE records
to the resolver. The resolver would then use these CLONE RRs to handle
its internal definitions of equivalent domains. A request for
www.variant1.tld would result in a CLONE RR that says "variant1.tld ==
label.tld" and the resolver would then internally change requests for
[foo.]variant1.tld to requests for [foo.]label.tld, get all the
information, validate as necessary, but then return the answer as if
it had been using variant1.tld all along. To the end user the domains
would function in exactly the same manner for every purpose. Only the
resolver would know that there was anything out of the ordinary happening.

If the authoritative server gets a request from a non-CLONE-aware
resolver it treats the request as if it had been for [foo.]label.tld.
So once again, for the end user the two domains are totally the same.
The only difference is that for the non-CLONE resolver DNSSEC
validation will fail.

> - Those that are new and understand the new protocol (whatever it is)

I think I've described this adequately above, if not please let me know.

> - Those that are not DNSSEC aware

For these resolvers no changes are necessary. Everything will work for
them as if variantN.tld actually is label.tld.

> - Those that are DNSSEC aware but don't understand the new protocol

These will fail to validate any answers for the variants.

> CNAME synthesis can be used for non-dnssec resolvers in both cases,

No no no no no no no. No CNAMEs. I am specifically NOT proposing a
solution that relies on CNAMEs at all. Please re-read what I'm
actually proposing. Any solution that relies on CNAMEs (or DNAMEs for
that matter) does not solve the actual problem of making 2 different
domains "the same." This is another reason why I'm suggesting an RR
with a totally different semantic (as much as I do think Paul's
suggestion of Ename was clever).

> but

This part is accurate, yes. For answers to non-CLONE-aware resolvers
it will be up to the authoritative name server to "synthesize" the
answer, but this is quite easily handled with some internal sleight of
hand. I don't see a load issue here, but if I'm missing something
please let me know.

> But I don't see a solution for current dnssec aware resolvers in either

There isn't one, nor can there be one (unless one of the DNSSEC
protocol gurus can pull a rabbit out of their hat, but I think even I
understand it well enough to be sure that's not going to happen). To
get DNSSEC + $SOLUTION the resolvers will have to be updated, full
stop. Now the good news is that ALL of the extant resolvers in
anything even closely resembling production today will have to be
upgraded to get DNSSEC + SHA-2 for the purposes of validating the root
some time next year anyway. So if we can actually agree on what the
solution will be in something resembling a timely manner it's not
impossible that we'll have the software to match in roughly the same
time frame, if not shortly thereafter.

Speaking realistically for a moment, as much as I am a strong
proponent of DNSSEC and am fully committed to finding a solution to
this problem that includes it; the authoritative-only part of CLONE
will solve 95% of the needs of the average end user as soon as it's
deployed. And unless I'm missing something really dramatic, actually
writing the code to do it should not be that difficult.

hth,

Doug

--

---

From: Chris Thompson <[email-masked]>
Date: 18 Dec 2009 12:10:18 +0000

>domain names dynamically.

"Precomputed DNSSEC signatures" are necessary unless all authoritative
servers for the zone have access to the (private halves of) the keys.
Any solution that requires that is going to have very restricted
applicability. (Would ICANN/Verisign want all root server operators
to be able to sign with the root ZSK? I doubt it ...)

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 18 Dec 2009 12:45:10 +0000

> terms of what will be required on the technical end to solve this

	Absolutely.

> The DNS protocol (and by extension, the existing software)

	I'm missing the motivation here.
	Surely CNAME+DNAME is simpler and less disruptive
	than introducing a new RRtype?  Changes to authoritative
	server code is needed in either case, and existing DNSSEC
	behaviour for CNAME and DNAME can remain unchanged.

	Of course, a single RR is more elegant than a pair, but I
	can't see mere elegance as a compelling consideration.

> maintenance problem for the child zone operator. 

	Surely, correct (if troublesome) provisioning of multiple zones
	would avoid the "except DNSSEC" pitfall simply by having
	corresponding DS records for each delegation in the parent zone?

	Apart from that, it seems to me that the maintenance problem for
	parallel delegation grows with tree depth as n**2, where n is
	the typical (or locally effective) bundle size.  Greek is too
	hard for me, so I'll just use n=2 and labels ending in "-o[u]r"
	for an example.

	For the domain name "flavour.colour.example.org" to be
	accessible independently of how the same word is represented
	at each of the third and fourth levels, four sets of RRs are
	needed:

		flavour.colour.example.com
		flavor.colour.example.com
		flavour.color.example.com
		flavor.color.example.com

	IIUC, Vaggelis mentioned that a bundle size of 4 is a typical
	requirement for supporting common usage in Greek.  The NIC.IR
	web site indicates that the Dot-Iran service routinely
	accommodates a bundle size of 6.  Ouch!

	Best regards,
	Niall O'Reilly

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Dec 2009 09:33:43 -0500

At 13:53 -0800 12/17/09, Matthew Dempsky wrote:

>... not an issue if the authoritative servers handle rewriting the

The consequence of switching to on-line, in-time generation of 
signatures by all authoritative servers means the following:

A much more complex key management policy.  For one, the private 
signing keys have to be sent to all servers (and securely, encrypted 
in transit).  For another, now a compromise at any server will 
release the private key into the wild.

A whole lot more cost.  If you say "let's rely on an HSM to protect 
the key" then imagine buying a device in the $25K (US) range for each 
and every server you have.  What about anycast - that really bumps up 
the count.  Imagine the headache of getting through customs in 
addition to the number of units needed and the specialized 
installation required.

A loss of independence.  Finally, many registries make use of name 
servers they don't operate.  If you switch to on-line in-time 
generation of signatures then you will be placing your private key 
into somebody else's machine and network.  With such a set up, it 
would be impossible for a registry to claim any sort of service level 
guarantees.

All of this was anticipated in the early days of the protocol design. 
Off-line signing has been an albatross [0], especially when 
considered in the extreme, but operationally it is better than the 
alternative.

[0] see http://en.wikipedia.org/wiki/Albatross_(metaphor) for an 
explanation of albatross.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Florian Weimer <[email-masked]>
Date: Fri, 18 Dec 2009 15:33:07 +0000

> 	for what is allowed on the RHS of any RR are easy to write.

What would that rule look like?

Those I can think of don't work if there are Punycode labels in the
zone.  Saying that all servers must have ASCII-only names probably dos
not meet the requirements.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Dec 2009 09:15:13 -0800

> equivalent to CNAME+DNAME?

CNAME+DNAME does not exist!

CNAME per RFC1134 section 3.6.2 (name alias)
,---
If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.  This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.
'---

DNAME per RFC2672  Section 3 (subdomain redirection)
,---
If a DNAME RR is present at a node N, there may be other data at N
(except a CNAME or another DNAME), but there MUST be no data at
any descendant of N.
... Together with the rules for DNS zone authority [DNSCLR] it implies 
that DNAME and NS records can only coexist at the top of a zone which 
has only one node.
'---

Rather than cloning zones, there would be less disruption using an 
interpreted redirection mechanism, in much the same way A-Labels are 
interpreted into unicode strings.  Clients would need to amend the 
routine looking for A-Labels to also include redirection 
interpretations.  It is not hard to see why Paul Hoffman and others 
don't want name restrictions and do not desire a redirection solution.

As you can see from the CNAME and DNAME rules, it is not possible to 
have CNAME+DNAME.  Just as A-label processing involves client side 
processing, a redirection convention can guide users to the "permitted" 
form of a name.

Since DNAME is not always supported, only affects subdomains with CNAME 
as a downgraded response for subdomain nodes, there is no easy way to 
combine the functions of DNAME and CNAME.

(IMHO, this is not likely, much like transforming DNS into adopting 
U-Labels.)

A redirection mechanism could use:

non-permitted-domain DNAME permitted-domain
_alias.non-permitted-domain CNAME permited-domain

It would be possible to define RR type PNAME to replace _alias label 
CNAME convention, but this would take time to adopt.

A redirection mechanism might look like:
non-permitted-domain DNAME permitted-domain
non-permitted-domain PNAME permitted-domain
_alias.non-permitted-domain CNAME permitted-domain (downgrade)

Once client software understands this convention, non-permitted name 
forms would be transparently converted, with needed records at the top 
of the zone replicated from the permitted-domain.

Those without upgraded clients will not fully benefit (status quo), but 
after upgrading their DNS consumer client, users will see permitted 
forms with reduced translational overhead, such as signatures and 
certificates.

IMHO, dyanmic signing DNSSEC can not be defended.  In addition, an 
authorization mechanism was previously added to guard against unexpected 
redirection and may need some consideration.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Dec 2009 10:03:44 -0800

Some clarification:

The following together is not possible:
_alias.non-permitted CNAME permitted-domain
non-permitted DNAME permitted-domain

Only when a new RR type of PNAME would PNAME+DNAME be possible such as:
non-permitted domain PNAME permitted-domain
non-permitted domain DNAME permitted-domain

As a downgrade to PNAME+DNAME, just CNAME could be used in conjunction 
with the _alias label, but this would require modified DNS servers.

-Doug

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 18 Dec 2009 18:49:08 +0000

> not meet the requirements.

	I may be overlooking something, but I meant that whatever rules
	apply today would still be appropriate.

	Without variants, Punycode labels can occur already in a zone,
	even at the apex.  This doesn't involve any special problems
	for RRtypes whose RDATA (RHS) is constrained.

	Adding variants in parallel by some yet-to-be-defined "full"
	aliasing method (for example, CLONE or CNAME+DNAME) doesn't
	introduce a need for new rules for RDATA-constrained RRtypes.
	The constraint is unchanged: reference to a redirected node is
	not allowed.

	If I'm lost in the land of wishful thinking, I'll be happy if
	someone will bring me back to reality.

	Best regards,

	Niall O'Reilly

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 18 Dec 2009 19:01:15 +0000

Niall O'Reilly wrote:
>     the typical (or locally effective) bundle size.

	I made a mistake; this was the wrong analysis.

	The maintenance problem for multiple parallel delegation must
	grow with the product over all the labels of the
	"variant-fanout" at each label.

	For uniform fanout (n) at each of (m) labels, the scaling
	factor for the most subordinate child zone is n**m.

	Best regards,

	Niall O'Reilly

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 18 Dec 2009 11:23:11 -0800

On Fri, Dec 18, 2009 at 6:33 AM, Edward Lewis <[email-masked]> wrote:
> A much more complex key management policy.  For one, the private signing
> keys have to be sent to all servers (and securely, encrypted in transit).
>  For another, now a compromise at any server will release the private key
> into the wild.

How do people handle SSL key management?  DNSSEC doesn't obviate the
need for security at the HTTP layer (or others).  Unless you propose
HTTP switches to an offline signature model too, sites are going to
need key management policies that can handle this anyway.

> A whole lot more cost.  If you say "let's rely on an HSM to protect the key"
> then imagine buying a device in the $25K (US) range for each and every
> server you have.  What about anycast - that really bumps up the count.
>  Imagine the headache of getting through customs in addition to the number
> of units needed and the specialized installation required.

It doesn't have to be that expensive.  A reasonable server can handle
upwards of 40,000 Diffie-Hellman computations per second (an AMD
Phenom II X4 955 at 3200 MHz has 4 cores and can compute a Curve25519
shared secret in under 300,000 cycles), and the results can be easily
cached to significantly increase capacity in the common case.  The
extra cost of encrypting and authenticating a ~512 byte packet is then
negligible.

> A loss of independence.  Finally, many registries make use of name servers
> they don't operate.  If you switch to on-line in-time generation of
> signatures then you will be placing your private key into somebody else's
> machine and network.  With such a set up, it would be impossible for a
> registry to claim any sort of service level guarantees.

A lot of sites use third party hosting services for running their web
servers, and don't seem to have issues with uploading their SSL
private keys for HTTPS.

Do you run all your own fiber when offering service level guarantees
to customers too?

> Off-line signing has been an albatross [0], especially when considered in
> the extreme, but operationally it is better than the alternative.

I'll believe this once Google and Akamai start using DNSSEC.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Dec 2009 14:50:32 -0500

At 11:23 -0800 12/18/09, Matthew Dempsky wrote:

>It doesn't have to be that expensive.  ...  The extra cost of encrypting
>and authenticating a ~512 byte packet is then negligible.

The issue isn't performance of the crypto.  If I need to generate 1 
signature an hour and I am implementing FIPS 140-2 level 4, I still 
need a (1) box.

>servers, and don't seem to have issues with uploading their SSL

The market for third party hosting services for HTTP and DNS are 
rather different.

>Do you run all your own fiber when offering service level guarantees

No.

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 18 Dec 2009 20:59:58 +0000

> CNAME+DNAME does not exist!

	I'm pretty sure no-one believes otherwise.

> used without checking with an authoritative server for other RR types.

	All well and good, but that doesn't actually preclude DNAME,
	which carries data not for the node itself, but only for the
	descendants of that node.

> (except a CNAME or another DNAME), but there MUST be no data at

	I believe that this specification (which I admit is the only
	one we have at present) is excessively conservative.  Exclusion
	of another DNAME is, of course, necessary in order to
	accommodate the intrinsic semantics of DNAME. Exclusion of CNAME
	appears to stem from overlooking the absence of any semantic
	conflict between CNAME and DNAME at the same node.

	My reading of sections 4.1 and 4.2 of RFC2672 leads me to
	believe that an authoritative or resolving server whose
	algorithm matches these sections will give the same results even
	if the prohibition of CNAME and DNAME at the same node is
	removed.

	It seems to me that only two things are needed to make
	CNAME+DNAME not only possible, but allowed.  These are:
	appropriate text in the forthcoming successor to RFC2672, and
	adjustment of the zone-integrity checking performed by
	authoritative server codes.

	As ever, I may have missed something.

	Best regards,
	Niall O'Reilly

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Dec 2009 16:39:20 -0800

> 	descendants of that node.

DNAME was defined after CNAME.  DNAME precludes concurrence with CNAME. 

> 	conflict between CNAME and DNAME at the same node.

Currently, no record unrelated to checking validity appears at a node publishing a CNAME alias.  Changing this will impact caching operations, and muddle record sources.  When the DNAME is at the top of the zone, the zone will only contain one node, which could be handled by using the same NS and A records for both zones.  Even if a resolver overlooks a non-compliant CNAME containing other resource records, CNAME semantics indicate resources at this node are obtained from the alias target, which is pointing to the wrong place when attempting to discover the DNAME. So there are semantic conflicts, where depending upon how caching is handled, a good chance things will get muddled even when by some off chance things appear to be working.

> 	if the prohibition of CNAME and DNAME at the same node is

You have failed to describe a method for transitioning to this new paradigm.  Changing text within an RFC will not cause all names servers to be instantly upgraded, nor should it be assumed both caching and authoritative servers will be upgraded simultaneously.

> 	authoritative server codes.

Adding redirection semantics to routines translating A-labels would allow DNAME and an _alias label within the alias zone to support full zone redirection.  Access to this label could be optimized by defining the equivalent of _alias IN CNAME target as a new PNAME target (P for preferred name).  The authoritative server could be tweaked to generate the _alias label target response without following the DNAME path using the PNAME information as a method to improve performance when both zones are signed by the same entity.  By moving redirection semantics to the client, redirection can start occurring at any time, letting people type what they want.  Waiting for all DNS servers to be upgraded will take decades.  The _alias & PNAME technique could be ready in months. :^)

This might mean more work for those maintaining A-label translation routines, so be nice to Paul Hoffman.   :^)

-Doug

---

From: Niall O'Reilly <[email-masked]>
Date: Sat, 19 Dec 2009 13:16:32 +0000

> DNAME was defined after CNAME.  DNAME precludes concurrence with CNAME. 

	We seem to agree on this.
	It follows that RFC1134 is not pertinent to a discussion of
	concurrent CNAME and DNAME.

> Currently, no record unrelated to checking validity appears at a node publishing 
> a CNAME alias.  Changing this will impact caching operations, and muddle record
> sources.  When the DNAME is at the top of the zone, the zone will only contain
> one node, which could be handled by using the same NS and A records for both
> zones.  Even if a resolver overlooks a non-compliant CNAME containing other
> resource records, CNAME semantics indicate resources at this node are obtained
> from the alias target, which is pointing to the wrong place when attempting to
> discover the DNAME.

	I believe that this interpretation conflicts with how the
	algorithm is specified in RFC2672.

> So there are semantic conflicts, where depending upon how
> caching is handled, a good chance things will get muddled even when by some off
> chance things appear to be working.
> 
> You have failed to describe a method for transitioning to this new paradigm. 

	I don't see a "new paradigm" here.

	As I see it, if existing codes implement the algorithm specified
	in RFC2672 _as it stands_, CNAME+DNAME is not only
	"wire-impact-free" (as Paul Vixie pointed out) but also
	"algorithm-impact-free".  What is new is not the paradigm, but
	our understanding thereof.  This would hardly be the first
	occasion of such a shift in collective understanding in
	regard to some aspect of the DNS.

	Otherwise (specifically, if there is divergence between what
	is actually implemented in code and _my reading_ of how the
	algorithm is specified in RFC2672), we face an operational
	question rather than one of protocol or of algorithm.  If so,
	the material discussion regarding transition belongs on another
	list.

	The questions for this list are whether such a development in
	our collective understanding of RFC2672 is actually reasonable
	and useful, and (if so) how best this development should be
	documented. The 2672bis draft comes to mind.

> Changing text within an RFC will not cause all names servers to be instantly
> upgraded, nor should it be assumed both caching and authoritative servers
> will be upgraded simultaneously.

	I believe that this is covered by my last few paragraphs.
	In summary: either this is not an issue, or else there is a
	latent fault in how existing codes implement RFC2672.

	Best regards,

	Niall O'Reilly

---

From: Doug Barton <[email-masked]>
Date: Sat, 19 Dec 2009 12:22:17 -0800

Douglas Otis wrote:
> Adding redirection semantics to routines translating A-labels would
> allow DNAME and an _alias label within the alias zone to support
> full zone redirection. 

Perhaps I was in error in proposing the CLONE idea before there was
any kind of consensus on the problem statement, and thereby driving
the desire to reach a solution before understanding the problem. If
so, I apologize.

Meanwhile, my reading of the problem is that any solutions that make
use of CNAMEs or DNAMEs are totally out of scope because they do not
meet the desired goal of making the zones "the same." I'm pretty sure
I understood Vaggelis well enough to believe that he at least is in
agreement, it would be nice if we could hear from others who are
knowledgeable about the problems as well.

I would add that there seems to be a very deep-seated feeling among
protocol people that CNAMEs are the answer to a lot of problems. The
fact that more than one person has inserted their own idea of using
CNAMEs into the CLONE description (which purposefully leaves them out)
I think is evidence of this. Please try hard to get past the CNAME
stuff. :)  There are things you can do with a "real" zone that you
cannot do with a DNAME'ed one today because of the CNAME synthesis. By
definition this prevents the two zones from being considered "the same."

Doug

--

---

From: Doug Barton <[email-masked]>
Date: Sat, 19 Dec 2009 12:34:55 -0800

Edward Lewis wrote:
> To put the cart and the horse in the right order, I am not stating how
> this should work, I am repeating what I am hear from others in the
> effort to understand the problem to solve.

Ok, I'll take this at face value. However if you have ideas of your
own it would be nice if you stated them explicitly. :)

> the SAME."  Not "why" and I really don't care about the motivation.

In some cases (and I think that the IDN-related aspects of this
problem are one) understanding the "why" helps to inform the technical
solutions, even if all it does is help to bound the problem.

For instance, I believe that you cannot really understand the "what"
here without understanding the "why" because a significant number of
the people involved in driving the _concept_ of IDNs forward (whether
that is at the TLD level or lower) are not technical people (which is
fine, don't get me wrong) and are not able to articulate "how" they
want things to work in a way that DNS protocol nerds can grok.

> Let's say we have X DNAME Y in the attempt to make all queries in the X
> domain be the same as asking the Y domain.  The query "X/IN/DNAME" will
> of course not be the same as "Y/IN/DNAME" - and if you define

In concept, I agree with you, and if you s/DNAME/CLONE/ then I think
you and I are basically in agreement on what the solution looks like.

> Maybe the problem is different.  Maybe it's not a matter of copying data
> space into another.  Maybe what we need to define is some sort of query
> redirection mechanism.  CNAME and DNAME are the first two steps there. 
> The problem with anything in the data space is that old servers don't
> know them.  If the new types have no special processing, then it's okay,
> we have that RFC on handling unknown types.
> 
> The problem is the special processing.  Maybe we should recognize that
> and keep the data space only as dirty as it already is.

There are way too many "maybe's" in those two paragraphs for me to do
anything useful with. :)

I have proposed a definition of the problem space (which all modesty
aside I think I actually understand pretty well) and a solution that I
think fits it. I'm happy to discuss either of those proposals further,
or to work with you on a better definition of the problem. What I
don't want to do is travel down a primrose path.

Doug

--

---

From: Doug Barton <[email-masked]>
Date: Sat, 19 Dec 2009 20:38:16 -0800

Niall O'Reilly wrote:
>     than introducing a new RRtype? 

I've made the assertion, which I am pretty confident is backed up by
facts, that any solution for the problem of making two zones "the
same" that involves [CD]NAMEs is a non-starter because it does not
actually make them "the same," it makes them "ultimately give the same
final answer most of the time if you follow the chain all the way to
the end."

Let me further demonstrate my claim by using an example that is not
intended in any way to cast aspersions on anyone. I have hesitated to
use this example previously because I don't want my incompetence in
Chinese to detract from the argument, but here goes.

Let's say that ICANN completes the IDN ccTLD process and now every
user who registers domain.cn is also given "the same name" (whatever
that means per registry policy) in <chinese character that represents
"China">. We'll call that .<CN> for short. Now let's add some more fun
to the mix, and assume that in addition to the .<CN> variants the user
is also "given" (or chooses to register, whatever) IDN versions of a
name. So now we have the following:

name.cn
name.<CN>
<chinese character that means "name">.cn
<chinese character that means "name">.<CN>
<chinese character variant for "name">.cn
<chinese character variant for "name">.<CN>

and all of those things should be "the same" from the standpoint of
the sysadmin that just wants to set up an MX record. In other words,

label MX 10 <character for mail>.<variant for "name">.<CN>

MUST work, and unless I'm missing something that will not work with a
CNAME/DNAME solution.

In my mind THAT is the motivation for a solution other than CNAME/DNAME.

hth,

Doug

--

---

From: Alex Bligh <[email-masked]>
Date: Sun, 20 Dec 2009 09:13:04 +0000

> MUST work, and unless I'm missing something that will not work with a

a) why won't it work for DNAME? Or more accurately, why isn't it
   compliant? I am assuming
	<CN>.				DNAME	CN.
	<variant for "name">.CN.	DNAME	name.CN.
   and there are 2 'A' records for mail, <variant of mail> because
   it's the MX specification that prevents you from pointing at
   something else, not the CNAME/DNAME spec, so inventing a 'CLONE'
   isn't going to help you there.

b) actually, in 99.99% of cases, label MX 10 [cname] does work, even though
   it is not technically compliant. Far easier, I think, to remove an
   very ancient restriction which is derived from the days when some
   resolvers could not follow CNAME chains, than introduce another
   aliasing technique. I would bet none of said resolvers run on systems
   which support IDN at anyway.

-- 
Alex Bligh

---

From: Tony Finch <[email-masked]>
Date: Sun, 20 Dec 2009 15:40:47 +0000

>   which support IDN at anyway.

What about label NS cname?

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: Mark Andrews <[email-masked]>
Date: Mon, 21 Dec 2009 10:25:06 +1100

In message <[email-masked]>, Tony F
> What about label NS cname?

It doesn't work.  Think about glue and additional section processing
rules.  You don't follow CNAMEs when looking up records to put in
the additional section.  For CNAME to work one would have support
returning CNAME's for glue *and* the addresses they ultimately refer
to.

Mark

---

From: Niall O'Reilly <[email-masked]>
Date: Mon, 21 Dec 2009 09:36:26 +0000

> final answer most of the time if you follow the chain all the way to

	I appreciate the trouble you're taking to make the distinction
	clear.  I'm not convinced that "sameness" (rather than the
	weaker level of equivalence achievable with redirection) is the
	right target to be aiming for.  This is really a question to be
	answered by for Vaggelis and those in other registries with
	similar requirements.

	I can see that a new RRtype which would cover node and
	descendants alike has the advantage of avoiding collisions with
	both documented and received semantics of existing RRtypes.
	The corresponding disadvantages are the need for new special
	processing and DNSSEC handling.

> In my mind THAT is the motivation for a solution other than CNAME/DNAME.

	It does.  Thanks.

	Best regards,

	Niall O'Reilly

---

From: Doug Barton <[email-masked]>
Date: Mon, 21 Dec 2009 15:08:54 -0800

Niall O'Reilly wrote:
>     clear. 

I am pleased that my efforts have been successful. :)

>     I'm not convinced that "sameness" (rather than the

I agree that more feedback from the people who would be directly
affected by this issue is needed, and valuable.

Doug

--