Subject: (bname)Re: [dnsext] shadow zones

From: "Jiankang YAO" <[email-masked]>
Date: Mon, 17 May 2010 09:22:20 +0800

I hope that the wg take up bname as a work item, too.

Bname and zone clone are different solutions.
Some customers will select bname, some will select zone clone according to their own needs.

Thanks a lot.

Jiankang Yao

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 02, 2010 8:14 AM
Subject: Re: [dnsext] shadow zones 

> one more thing: i request that the wg take up shadow zones as a work item.
>

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Tue, 18 May 2010 14:00:33 +0300

I have to second Yao on this. I am not certain if the "zone clone" proposal
is covering all the "DNAME is not enough" issues, where BNAME as a basis for
discussion seems close to what we expect as a registry of this new function.

Kind Regards,

Vaggelis Segredakis

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jiankang YAO
Sent: Monday, May 17, 2010 4:22 AM
To: Paul Vixie; [email-masked]
Subject: (bname)Re: [dnsext] shadow zones 

Bname and zone clone are different solutions.
Some customers will select bname, some will select zone clone according to
their own needs.

Thanks a lot.

Jiankang Yao

---

From: Paul Vixie <[email-masked]>
Date: Tue, 18 May 2010 11:55:39 +0000

> From: "Vaggelis Segredakis" <[email-masked]>
> Date: Tue, 18 May 2010 14:00:33 +0300
> 

as the author of one draft and co-author of the other, i'm +1 on this.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 May 2010 11:24:19 -0400

Dear colleagues,

> as the author of one draft and co-author of the other, i'm +1 on this.

I'm picking on Paul's message because it's handy, not because I want
to pick on him.  As usual in these discussions, I really haven't made
up my mind about anything.  But in this message, I shall argue the
case for _not_ adopting this work, at least not right now.

My personal-but-hat-on impression of what we determined at our last
meeting was that we needed to do two things before we'd decide whether
we'd go ahead with any of this work.  In some sense, we need to work
from both ends.

One end is to try to figure out what problems people are trying to
solve.  We had a volunteer (Suzanne) who was planning to write (I'm
sure she'll correct me with "edit") a draft that provides such an
outline.  We don't have that draft yet, but I think we probably need
it in order to understand what we're doing.

The other end was to outline what we actually can do (I recall Ted
Hardie making this argument at the mic, for instance).  This bit of
work is to explain what each approach can (and can not) do.
Similarly, I think we need to understand what the deployment
requirements of the particular technologies are in order to make them
useful.  I don't think either of the existing drafts do either of
these things in sufficient detail that someone who isn't already
intimate with how DNS works will be able to understand the
implications.  (I'd be satisfied with an answer that such detail
doesn't belong in these drafts, in which case I'd still like to see
such an analysis in some draft.)

There are non-trivial costs associated with doing this work.
Moreover, as I've previously argued, that ICANN is doing something
using only provisioning and legal agreements is _prima facie_ evidence
that at least some class of problems can be solved just by improved
provisioning tools.  If that's right, it might move one or both drafts
from "needed for certain goals" to "nice to have".  If a feature is
just nice to have, then we have to have a serious talk about whether
the benefit it brings to the people who want it is worth the
additional complexity in the protocol.

On the "additional complexity" front, I am particularly concerned
about the BNAME proposal.  CNAME synthesis is one of the most
controversial aspects of DNAME -- it's actually been used as part of
an argument that DNAME can't be used in some cases -- but without
CNAME synthesis (or some other synthesis) BNAME simply can't deliver
what is needed to non-BNAME aware resolvers.  But of course, if that
were true, BNAME wouldn't be a live option at all.  The draft
currently uses a CNAME record, but in a way that violates the original
restrictions on CNAME (and which is therefore possibly backward
incompatible with deployed software).

So, in my opinion, we still have some distance to go before I think we
should commit to doing this work.

A

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

---

From: Alex Bligh <[email-masked]>
Date: Tue, 18 May 2010 17:03:20 +0100

> should commit to doing this work.

+1

-- 
Alex Bligh

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 May 2010 11:41:42 -0700

>it in order to understand what we're doing.

Definitely. Look at the range of responses on this list during the last round: it was widespread even among people who normally agree with each other.

>such an analysis in some draft.)

Such detail *is mandatory* in the draft: otherwise, it will just get posted on the list and be lost in the exaflood of responses on a probably-misnamed thread.

>provisioning tools.

Indeed. If it's good enough for ICANN, why is it not good enough for us?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 19 May 2010 09:49:22 +0800

----- Original Message ----- 
From: "Paul Hoffman" <[email-masked]>
To: "Andrew Sullivan" <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 19, 2010 2:41 AM
Subject: Re: On adoption of two drafts (was: (bname)Re: [dnsext] shadow zones)

> Indeed. If it's good enough for ICANN, why is it not good enough for us?

ICANN evalutes the current DNS technology including DNAME, but not sure which dns technology can be used.
So icann has to use the provisioning and legal agreements due to lack of the DNS technology to solve it.
ICANN is still looking for and evaluting some dns technology or some potenial dns technology including bname and zone clone. 
In case of icann finding it, ICANN will use it.
So icann also said that if there is a DNS technology to solve the problem, icann will push all the TLDs to move to that dns technology.

Jiankang Yao

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Wed, 19 May 2010 13:07:35 +0300

Dear Andrew, dear All,

With the fear that this should be done at a more initial phase, I am sending
to the list a small, compact, description of our issues with the IDNs,
hoping this will set some grounds and requirements for our following
discussion on the adoption of the two drafts.

------------------------------------------
Issue: The creation of xNAME

Description of the problem: 

In the .gr ccTLD we have presented in 2005 the option of registering IDN
domain names in Greek. The Greek language requires for all multi syllabus
words to have an accent sign called "tonos" over one of the letters. In
capital letters the word is not accented. However, in UTF the accented Greek
letters are different that the non-accented. This leads in a pair of domain
names necessary to describe each word, one with a tonos and one without.

The .gr registry has given the registrants the option to DNAME these two
domain names. This way if a user types the word in capital or small letters,
the outcome should be the same, like in every Latin domain name.

With the proposal of IDNA2008 protocol, the problem becomes even more
complicated because the final sigma letter is no more mapped to the sigma
letter. This way, for each domain that ends with a final sigma
(approximately 1/3 of the domain names, all male names and more) has now
four variants. If a domain name has two words in it then we have 16 variants
and so-on.

To make things worse, the DNAME is not a solution. Because of the way it was
proposed it acts one level below of the DNAMEing. This makes impossible to
use DNAME for emails on the domain itself: [email-masked] will never be
redirected to [email-masked] by just using "Domain1.gr DNAME Domain2.gr".
The same is true for http://domain1.gr and http://domain2.gr.

One could suggest CNAME for the first level. The use of CNAME and DNAME
together is prohibited though.

The only workable solution would be the creation of xNAME. xNAME would act
like CNAME and DNAME together, from the first level. If you declare
"Domain1.gr xNAME Domain2.gr" this means [email-masked] will be the "same"
as [email-masked] and http://Domain1.gr will be the same as typing
http://Domain2.gr.

Let me give you an example using my name...

If someone would like to register
Βαγγέλης.gr (xn--ixahcfaz1a9d.gr - This one has the "tonos" mark) I have to
register as well ΒΑΓΓΕΛΗΣ.gr (xn--mxabeakm1a9d.gr - This one without the
tonos). This is used for the representation in capital letters and maybe for
people who type without tonos, e.g. from mobile phones.

At present (IDNA2003) we would dname these two domain names or the
registrant would have to create two, distinct zones.

In IDNA 2008 the first one will become two domains: βαγγέλησ.gr and
βαγγέλης.gr (normal sigma and tonos, final sigma and tonos)

The second one will again be two different domain names, Βαγγελησ.gr and
Βαγγελης.gr (normal sigma, without tonos and final sigma without tonos).

We now have to dname four (4) different domain names but no matter what we
as a registry do their operation will be limited, without proper support of
email. The problem becomes much more complicated if you have domain names
consisting of two, three, four words ending with final sigmas.

------------------------------------------

This case is not the same with the case ICANN presented. I am afraid that
zone cloning will not be the "one solution fits all". This is why we are
asking for the BNAME or any type of xNAME solution to be studied thoroughly.

Please accept my apology if someone already has a clear picture of our
issues and this lengthy email comes as a repetition.

Kind Regards,

Vaggelis Segredakis

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Tuesday, May 18, 2010 6:24 PM
To: [email-masked]
Subject: On adoption of two drafts (was: (bname)Re: [dnsext] shadow zones)

Dear colleagues,

A

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

---

From: Alex Bligh <[email-masked]>
Date: Wed, 19 May 2010 03:30:18 -0700

--On 19 May 2010 13:07:35 +0300 Vaggelis Segredakis <[email-masked]> 
wrote:

> like CNAME and DNAME together, from the first level

Were the prohibition on having CNAME+DNAME together lifted, together with
appropriate signalling (which can be no harder than the signalling to
support xNAME), would this resolve the problem you describe any less
well than xNAME? If it's no worse, it seems to me it would be
substantially easier.

Clearly it may not give other functionality that the various xNAME proposals
seek to offer.

-- 
Alex Bligh

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Wed, 19 May 2010 13:49:36 +0300

I am afraid that just changing the restriction of CNAME+DNAME will create
havoc. You would not be able to determine if a domain name is resolved as it
should be, it would depend on the version of the resolver but without any
warning. 

Other than this, the CNAME+DNAME is actually pretty much the xNAME we ask
for.

Best,

Vaggelis

-----Original Message-----
From: Alex Bligh [mailto:[email-masked]] 
Sent: Wednesday, May 19, 2010 1:30 PM
To: Vaggelis Segredakis; 'Andrew Sullivan'; [email-masked]
Cc: 'Sotiris Panaretou'; Alex Bligh
Subject: RE: On adoption of two drafts (was: (bname)Re: [dnsext] shadow
zones)

-- 
Alex Bligh

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 May 2010 23:54:41 +1000

In message <[email-masked]>, Alex Bligh writ
> well than xNAME? If it's no worse, it seems to me it would be

I don't believe that there is appropriate signaling for CNAME + DNAME.
If you have a method please post the details.

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

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 19 May 2010 15:53:55 +0200

> should be, it would depend on the version of the resolver but without any

Could you elaborate on that?  I still didn't have a time to do thorough 
testing, but initial tests showed no impact on resolvers.  I promise to 
do more testing soon.

> Other than this, the CNAME+DNAME is actually pretty much the xNAME we ask

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

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Wed, 19 May 2010 17:05:56 +0300

It is not technical but rather an "adoption-phase" problem: If there will
not be a distinct DNS command with specific characteristics but instead a
differentiation of the protocol from a version and beyond, we will have for
years people asking "Why it is not working on my machine but it is ok on
yours?". If this is not considered a prohibiting factor, I cannot raise any
other objections now, I haven't thought it through yet.

We tried to test CNAME+DNAME but the Bind does not accept the zone as valid.
If you manage to get it to work, please share your results.

Vaggelis

-----Original Message-----
From: Ondřej Surý [mailto:[email-masked]] 
Sent: Wednesday, May 19, 2010 4:54 PM
To: Vaggelis Segredakis
Cc: 'Alex Bligh'; [email-masked]
Subject: Re: On adoption of two drafts

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 19 May 2010 16:15:38 +0200

On 19.5.2010 15:54, Mark Andrews wrote:
> In message<[email-masked]>, Alex Bligh writ
> es:
>> --On 19 May 2010 13:07:35 +0300 Vaggelis Segredakis<[email-masked]>
>> wrote:
>>

Why do you need signaling?  If it fits into all existing scenarios and 
there is existing support in all resolvers.  If it doesn't that 
CNAME+DNAME is no-go.

Ondrej

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 May 2010 14:39:54 +0000

> Date: Wed, 19 May 2010 16:15:38 +0200
> From: Ondřej Surý <[email-masked]>
> 

most if not all existing recursive servers, forwarders, stubs, and apps
assume that a name either is an alias or is not one. the presence of a
cname will in some cases trigger alias-following behaviour, silently
ignoring the non-dname data. the presence of a non-cname will in some
cases trigger resolution behaviour, silently ignoring the alias.

the fact that a given authority server can be patched to allow this data
pattern and that a given set of recursives, stubs, and apps can be tested
to show no problems, doesn't mean this isn't a grave protocol violation
with far reaching consequences. it is avoidable, and such avoidance is
extremely worthwhile.

bname, by comparison, is relatively safe. note though, anything involving
aliases will create 'second class domains'. interior name references by
NS and MX for example cannot refer to an alias since the specification
does not require alias-following behaviour.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 19 May 2010 10:50:14 -0400

<no-hat>

The main question in my mind when comparing xNAME vs C+DNAME is
where is the cost ?
In xNAME we need to change all DNS protocol implementations (eventually).
In C+DNAME the cost falls on the authoritative side as only signers
and authoritative servers need to be changed.
Resolvers will not get confused as "exact match" queries get CNAME 
answer and "partial match" get DNAME answer.

The only failure mode for C+D that I see:
	is the possible lack of DNAME support in resolvers
	recursive validators rejecting NSEC/NSEC3 records with both
		DNAME and CNAME bits set.

	Olafur

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 19 May 2010 10:53:08 -0400

No hat

> aliases will create 'second class domains'. 

The current BNAME proposal includes a synthetic CNAME every time it
sends a BNAME.  It appears, then, that it runs into the same issue you
outline above, for it may trigger alias-following behaviour when it
ought not or conversely.  No?

A

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

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 19 May 2010 17:08:19 +0200

Paul,

are you saying that we have behaviour:

A) if cname exist then do_more_work else do_standard_work

or

B) if any^cname exist then do_standard_work else do_more_work

?

(Sent from my iPhone in afternoon traffic jam)

Ondrej Sury

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 19 May 2010 11:14:38 -0400

> At 11:24 AM -0400 5/18/10, Andrew Sullivan wrote:
...
> Indeed. If it's good enough for ICANN, why is it not good enough for us?

Because ICANN is focused on the top of the tree, they can afford to adopt
solutions that are fine for one or two levels with the problem and, at least
temporarily, wash their hands of any exponential explosion resulting from
applying such solutions to the general N level problem.

--Paul Hoffman, Director
> --VPN Consortium

Donald

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 19 May 2010 17:23:34 +0200

Just more thoughts.

Ondrej Sury

> A) if cname exist then do_more_work else do_standard_work

AFAIK this case is already covered by existing CNAME and DNAME  
(+synthetized CNAME) handling.

> B) if any^cname exist then do_standard_work else do_more_work

This case would be broken by BNAME as well (follow-up on Andrew's  
message) and also by NSEC+RRSIG (which we already have).

Or there is a third option:

C) if cname exists then do_some_work elif non-cname exists then  
do_another_work else not_specified

And we don't know if cname rule will hit first or not?

I don't believe this is the case. After all resolver will happily  
return CNAME+A record in one DNS message to a DNS client.

Ondrej

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 May 2010 15:27:39 +0000

> Date: Wed, 19 May 2010 10:53:08 -0400
> From: Andrew Sullivan <[email-masked]>
> 
> [No hat.] The current BNAME proposal includes a synthetic CNAME every
> time it sends a BNAME.  It appears, then, that it runs into the same
> issue you outline above, for it may trigger alias-following behaviour
> when it ought not or conversely.  No?

no. as for dname's synthesis of cnames, for those who do not understand
bname, they will see only the cname. this property is conveyed through
caches, who themselves either do or don't understand [db]name, and either
never hear anything but the cname, or who hear the [bd]name and who know
what it means. this is the only safe way to use signalling to introduce
new features. it's theoretically possible to enable cname+dname using 
only an "understand cname+dname" bit, but this is not simpler to deploy
(or debug) than a new code point (bname) with an "understand bname" bit.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 May 2010 15:32:03 +0000

> Date: Wed, 19 May 2010 10:50:14 -0400
> From: Olafur Gudmundsson <[email-masked]>
> 
> <no-hat> The main question in my mind when comparing xNAME vs C+DNAME is
> where is the cost ?  In xNAME we need to change all DNS protocol
> implementations (eventually).  In C+DNAME the cost falls on the
> authoritative side as only signers and authoritative servers need to be
> changed. ...

no. see Message-ID: <[email-masked]> for more information.

the only safe way to implement c+d is with an "understand c+d" bit, and
i would find this harder to deploy and debug than a new code point and
an "understand new code point" bit. thus my support for the bname proposal.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 May 2010 15:40:07 +0000

> Date: Wed, 19 May 2010 17:08:19 +0200
> 
> Paul, are you saying that we have behaviour:
> 

i am aware of at least one implementation of each of those things, but
that's not the point. the point is, such implementations would be correct.
so, we can't alter the specification in a way that they become incorrect.
so, new signalling must be used to introduce the desired new behaviour.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 May 2010 09:32:36 -0700

At 11:14 AM -0400 5/19/10, Donald Eastlake wrote:
>On Tue, May 18, 2010 at 2:41 PM, Paul Hoffman <<mailto:[email-masked]>[email-masked]> wrote:
>Because ICANN is focused on the top of the tree, they can afford to adopt solutions that are fine for one or two levels with the problem and, at least temporarily, wash their hands of any exponential explosion resulting from applying such solutions to the general N level problem.

If ICANN adopts such a dorky solution, the DNS world still needs to deploy it in order to make the top level work. If ICANN picks a solution that prevents co-existence with other, more robust solutions, then we're all screwed. I believe ICANN knows this. Thus, they should only pick such a dorky solution if (a) they didn't care about the rest of the DNS or (b) they didn't understand the technical problem.

So, again, if it's good enough for ICANN, why is it not good enough for us?

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 19 May 2010 12:49:09 -0400

No hat.

On Wed, May 19, 2010 at 03:27:39PM +0000, Paul Vixie wrote:

> what it means. 

Well, I think what this means is that (1) we're going to be
synthesizing CNAMEs only again, for people who don't understand BNAME
and (2) sometimes caches will have a CNAME when they could have had a
BNAME, because the cache wasn't signalled with the BNAME-aware bit so
asked with it turned off.  Both of these, it seems to me, are the
locus of complaints about how DNAME works.  

> (or debug) than a new code point (bname) with an "understand bname" bit.

I have a lot of sympathy for that argument.

A

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

---

From: David Conrad <[email-masked]>
Date: Wed, 19 May 2010 10:03:05 -0700

Paul,

On May 19, 2010, at 9:32 AM, Paul Hoffman wrote:
> If ICANN adopts such a dorky solution, the DNS world still needs to deploy it in order to make the top level work.

My understanding (not being directly involved in any of this) is that ICANN adopted such a "dorky" solution because no real solution existed with the implicit assumption (or maybe even explicit) that when the IETF comes up with a real solution, the "dorky" solution would be deprecated as quickly as possible.

> If ICANN picks a solution that prevents co-existence with other, more robust solutions, then we're all screwed. I believe ICANN knows this. Thus, they should only pick such a dorky solution if (a) they didn't care about the rest of the DNS or (b) they didn't understand the technical problem.

or (c), ICANN's community told ICANN that the existing solutions were insufficient but ICANN had to do something until a real solution existed.  Being stuck being a rock and a hard place (which is the normal state for ICANN), ICANN tried to come up with a hack that would allow things to move forward.

> So, again, if it's good enough for ICANN, why is it not good enough for us?

Not entirely sure what you're arguing here.

Do you think synch'd domains will scale past the root/TLDs?

Regards,
-drc

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 May 2010 10:53:04 -0700

>My understanding (not being directly involved in any of this) is that ICANN adopted such a "dorky" solution because no real solution existed with the implicit assumption (or maybe even explicit) tha…

That was not my understanding at all from having read the same announcements. My understanding is that ICANN is saying "provisioning is good enough for what we specify", and they specified that duplication will be made all the way down the parallel trees.

>or (c), ICANN's community told ICANN that the existing solutions were insufficient but ICANN had to do something until a real solution existed.  Being stuck being a rock and a hard place (which is t…

Yes, that is cetainly another possibility.

>Do you think synch'd domains will scale past the root/TLDs?

I do not run trees of any significant depth or width, so I am the wrong person to ask. ICANN presumably asked its constituents and came up with the current policy, and will presumably ask its constituents before coming up with policy changes. Those folks are in a much better position to answer the question than I.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 May 2010 18:02:06 +0000

> Date: Wed, 19 May 2010 12:49:09 -0400
> No hat ... (1) we're going to be synthesizing CNAMEs only again, for
> people who don't understand BNAME and (2) sometimes caches will have a
> CNAME when they could have had a BNAME, because the cache wasn't
> signalled with the BNAME-aware bit so asked with it turned off.  Both of
> these, it seems to me, are the locus of complaints about how DNAME works.

yes but the complaints are about performance not correctness and so i've
been lamenting alongside but not treating this as a design constraint.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 May 2010 14:23:13 -0400

At 3:30 -0700 5/19/10, Alex Bligh wrote:

>Were the prohibition on having CNAME+DNAME together lifted,

The protocol could not withstand this.  Think of the issue with 
caches (and imagine the ANY query).  If a cache has the CNAME but not 
the DNAME or vice versa it would have to fetch the other.

If you tried to require a cache having the CNAME to try to test for 
DNAME (or vice versa) you would invite a never ending of fetching 
these two from the authoritative servers.  What if the TTL for CNAME 
was 3600 and the DNAME 3000?  After 300o seconds you'd drop the 
DNAME.  Having a CNAME with TTL of 600, the cache would refresh and 
get DNAME with TTL of 3000 and CNAME of 600.  600 seconds later, we 
would wind up with CNAME 3600 and DNAME now at 2400.  And on and on. 
Note my numbers aren't that realistic, there'd be a few seconds here 
and there skewing - but making the likelihood the two records would 
TTL out at the same time rare.  All that fetching for nothing.

If you wanted to relax the combination, you'd have to signal the 
caches that there was a CNAME and DNAME at a name in case you needed 
to know that.  You'd need another way to signal this per domain...so 
you might as well just use a new RR type.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Discussing IPv4 address policy is like deciding what to eat on the Titanic.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 19 May 2010 11:51:17 -0700

On Wed, May 19, 2010 at 11:23 AM, Edward Lewis <[email-masked]> wrote:
> The protocol could not withstand this.  Think of the issue with caches (and
> imagine the ANY query).  If a cache has the CNAME but not the DNAME or vice
> versa it would have to fetch the other.

I don't know any caches that exhibit this behavior.  Every cache I've
tested only issues upstream queries for a QNAME if it has *no* records
in cache for that name, not just because it might only have some of
them.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 May 2010 16:15:05 -0300

> in cache for that name, not just because it might only have some of
I think you are making Ed's point for him. :-)

What he's saying is, allowing both means caches would need to return both
(iff both exist).

And what you say, means that current behavior would be incorrect, and caches
would all need to be upgraded.

(This is because, if the authority server had CNAME+DNAME, but the cache had
one but not the other,
and returned just that one in response to an ANY, the result would be
semantically wrong.)

I think we're seeing the rathole for what it is, i.e. that something new
(xNAME) is needed if anything is needed,
and that CNAME+DNAME might work in a lab, but is not real-world friendly.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 May 2010 15:15:58 -0400

>in cache for that name, not just because it might only have some of

That's right.  And that illustrates why, in RFC 1034, section 4.3.2, 
step 3 (and it's updates) there is no place for a rule that says "if 
the name owns a CNAME and a DNAME then perform the following 
processing..."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 19 May 2010 21:46:51 +0200

Ed,

how does NSEC and RRSIG fit into your schema of arguments?

Ondrej Sury

On 19.5.2010, at 21:15, Edward Lewis <[email-masked]> wrote:

>>> caches (and

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 May 2010 16:03:45 -0400

>how does NSEC and RRSIG fit into your schema of arguments?

There's no conditional processing based on the 
presence of NSEC and/or RRSIG with any other 
records.  Yes, there is special processing when 
you assemble the answer, but not during the 
lookup process.

What would happen if a cache has "dropped" the 
RRSIG for a set?  The cache would just return the 
set as if the RRSIG wasn't there.  (This is how 
backwards compatibility is accommodated.)  The 
"omission" would then be up to the validator to 
recover.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 19 May 2010 13:56:17 -0700

> I think you are making Ed's point for him. :-)

No.  Ed's claim is tantamount to saying that a recursive resolver must
always return all records for a qname in response to an ANY query.

However, it's standard practice for caches to only return records that
are already in the cache (unless there are none, then an upstream
query is in order).  E.g.,

$ dig -t any isc.org @4.2.2.5

; <<>> DiG 9.4.3-P3 <<>> -t any isc.org @4.2.2.5
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50900
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;isc.org.			IN	ANY

;; ANSWER SECTION:
isc.org.		43198	IN	RRSIG	A 5 2 43200 20100617191610 20100518191610
18516 isc.org. KgmCmfsvCEPmbcA17XPm09qu5CAjItNEC7ka+E/wWjImwUAM6x8dlOje
yaXhnKzO+N+5SX9xF27bxepoxrgDZQfNsbFlFXDosZyiv53Z+9ASl2rI
LNHLTrfx7t7xne9tobkeDgswBZsw+F0k2s6FihmyVGRLlMR56Ab6Dsbr +W8=
isc.org.		43198	IN	A	149.20.64.42
isc.org.		43198	IN	RRSIG	NS 5 2 43200 20100617191610 20100518191610
18516 isc.org. ZUC9p0AvE+ePBYs6Red5nEx8hUW1IvN3gbSsBn4Ah47bNBpydyqR5mGl
+wKAbLP8OPdpVgmLL6TQFiZ+toNInB5IRghS2EXhQXuYnqhYoSAH9rbL
HOzxGKjSO3zmWPiH8gJM37fm88IF6UAYcdIVK/xMTNvr1kDTSoDbNMxs Nzg=
isc.org.		27722	IN	NS	ams.sns-pb.isc.org.
isc.org.		27722	IN	NS	sfba.sns-pb.isc.org.
isc.org.		27722	IN	NS	ord.sns-pb.isc.org.
isc.org.		27722	IN	NS	ns.isc.afilias-nst.info.

;; Query time: 27 msec
;; SERVER: 4.2.2.5#53(4.2.2.5)
;; WHEN: Wed May 19 13:51:07 2010
;; MSG SIZE  rcvd: 474

However, if you check with one of isc.org's authoritative name
servers, you'll notice isc.org also has SOA, MX, TXT, AAAA, SPF,
DNSKEY, NSEC, NAPTR, SPF, and a few more RRSIG records.

Certainly if isc.org had a DNAME record, it would be handled the same
way, so what's the issue with omitting it if isc.org had a CNAME
record?

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 May 2010 17:57:15 -0400

>always return all records for a qname in response to an ANY query.

No, no.  My mail was (evidently poorly) trying to "prove by 
contradiction" that a cache cannot be programmed to make a decision 
based on the presence of multiple RRsets at a name.  What I was 
trying to illustrate was that if a cache had a CNAME for a name, it 
would be a pain to maintain the DNAME because of a vicious cycle of 
having to retrieve the other to know that there were both.

>query is in order).  E.g.,

And that is correct and a reason why an approach that depends on 
relaxing the CNAME restrictions won't work.  Caches don't try to 
maintain all of the sets at a name, just all of the records at a set. 
ANY clearly shows this.  And there is no ALL qtype.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 19 May 2010 15:12:27 -0700

On Wed, May 19, 2010 at 2:57 PM, Edward Lewis <[email-masked]> wrote:
> No, no.  My mail was (evidently poorly) trying to "prove by contradiction"
> that a cache cannot be programmed to make a decision based on the presence
> of multiple RRsets at a name.  What I was trying to illustrate was that if a
> cache had a CNAME for a name, it would be a pain to maintain the DNAME
> because of a vicious cycle of having to retrieve the other to know that
> there were both.

CNAME+DNAME-aware caches could better handle the situation, and legacy
caches would still work, if suboptimally.  I don't see an issue.

> And that is correct and a reason why an approach that depends on relaxing
> the CNAME restrictions won't work.

Please elaborate.  I fail to see how this would be a problem for CNAME+DNAME.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 May 2010 08:37:23 +1000

> and authoritative servers need to be changed.

Not true.  I'm aware of changes that need to be made to the resolver
side of BIND for C+DNAME.  I posted the minimum changes to get the
authoritative side of BIND working for C+DNAME.  When doing that I
noted that similar changes need to be made for cache lookups.  They
are small changes but changes never the less.  Whether one can live
with the side effects of not making that change remains to be seen.

> 		DNAME and CNAME bits set.

One needs to do lots of experimentation and testing.

> > From: Ondøej Surý [mailto:[email-masked]]

---

From: Alex Bligh <[email-masked]>
Date: Wed, 19 May 2010 17:18:51 -0700

> If you have a method please post the details.

There clearly isn't now. I was wondering whether developing one would
be easier than xNAME proposals, but there would be no point wasting
brain cycles on the idea if it didn't do the job, hence the question.

-- 
Alex Bligh

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 May 2010 10:43:12 +1000

> brain cycles on the idea if it didn't do the job, hence the question.

Define the job?  Bundled names or being able to redirect a name and
it decendents independently.  We keep thinking "is this a solution
to the idn tld problem" when we should be thinking is this a good
tool to have in the tool chest.

cname+dname is a useful tool (with known issues) bname is a different
tool (with known issues)

Which one is better depends on what you want to do.

If you want to bundle namespaces bname is a better tool as you can
say bname or ns as you don't provide the opportunity to redirect
the differently.

If you are not trying to bundle namespaces then c+dname may be a
better tool for you as it provides more freedom.

The chairs are too focused on what is good for "idn tlds" rather
than being focused on "are these good tools in their own right".

shadow also needs to be looked at in the "is this a good tool"
light.  I'm undecided on that.

soa+ns+cname is another potential tool to have in the tool chest.
This has similar issues to cname+dname.

For both cname+dname and soa+ns+cname we need to ask, is the possible
pain worth the benefit that comes from relaxing the cname and other
data rules for these types.  We answered "yes" with DNSSEC to this
question for nsec/nxt/key.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 19 May 2010 22:58:02 -0400

Speaking only for myself.

> than being focused on "are these good tools in their own right".

I'm a little dismayed (and actually, if I didn't trust Mark's
earnestness as I do, I'd be a little insulted) that the above is the
impression I've given.  So let me try to be clearer: we are not going
to solve any general issue with IDN TLDs, and I'm not trying to.

Neither, however, am I willing to ask only whether BNAME or shadow
zones are good tools in their own right.  I've no doubt they are.
That's not all of what engineering questions are about.

The questions I see before us come down to these:

    1.  Is there a problem?

    2.  Is it one that can't be solved already?

    3.  Is it something we are in a position to solve?  (How completely?)

    4.  What are the consequences of solving it?

I think we agreed in our interim back in February that the answer to
(1) was "yes".  I thought we had reason to believe that the answer to
(2) was "yes", also, except that some registries (ICANN among but not
alone among them) seem to have worked around this.  The answer to
question (3) is still open, in my view, because we still haven't a
strong and clear statement of what problem(s) we are trying to solve.
And finally, question (4) is wide open.  It's what I've been talking
about most in this recent thread.

Owing to its inherent flexibility, the DNS can probably be altered
enough to solve just about any issue that arises.  That does not mean
that it ought to be: just because we can does not mean that we should.

Owing to its age and consequent ossification, the DNS resists
additions and modifications.  We've seen this repeatedly.  As a
salient example, the DNAME-bis draft has been kicking around for some
time, and we still don't have clear agreement because there are
details about which there are some disagreements.  DNAME is not some
novelty, and yet there are significant though narrow issues that
haven't been resolved completely.  And anyway, people still claim that
DNAME is bad not just on performance grounds, but because there are
systems that look like they support it but don't.  (It makes no
difference if there are actually such systems, because if people
believe there are, it's as great an impediment to deployment.)

Moreover, _one_ of the consequences of taking on new work is that we
actually take it on.  This WG does not have a stellar record of work
progression.  Ed Lewis will perhaps send me another observation that
the work progress record is due to lack of leadership, and I
cheerfully accept his judgement.  But regardless, we don't seem to
come to quick agreement even on narrow and focussed issues, and I
worry that something as dramatic as the BNAME and shadow zone
proposals just won't get the extensive review they desperately need.
Such an outcome would serve nobody.

This WG is nominally asleep, and we took the decision to enter that
state because we thought the protocol was effectively done.  I am not
asking whether these proposed tools solve a special problem: I've
gone out of my way to ensure we framed the question differently than
that.  But I'm also not asking whether these tools are good on their
own.  The question is whether on the whole they are good for the DNS.
I am having a hard time coming to a conclusion about that.

A

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 May 2010 13:34:44 +1000

In message <[email-masked]>, Andrew Sullivan writes:
> details about which there are some disagreements.

None of which impacts actual deployment.  The only real change in the
draft is the relaxation of the TTL of the synthesised CNAME.

> DNAME is not some

Yep, there is lots of FUD floating around about DNAME.
 
> I am having a hard time coming to a conclusion about that.

Which just makes you undecided.  It shouldn't stop them proceeding
if there is consenus that they are useful and should be worked on.

Mark

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 May 2010 00:15:38 -0400

>that it ought to be: just because we can does not mean that we should.

I don't think that flexibility is one of the inherent traits of the 
DNS.  Scaleability, quick response are.  The DNS has fundamentally 
been inflexible due to at least two of it's founding aspects - poor 
ordering of the fields (specifically the class coming after the name 
in the envelop) and the use of fixed size fields (necessary for the 
old processing budgets but rather constraining today).  The latter 
was helped by EDNS, the former is a lost cause.

>additions and modifications.  We've seen this repeatedly.

In my opinion, the reason it is hard to modify the DNS is not age and 
ossification, it's the fact that underlies much of the rest of the 
Internet architecture.  If you are in a boat and someone is rocking 
it at the center you will feel it much more than if the rocking is at 
the edge.

If you built a system like DNS today (new and improved!) and then had 
all of the other Internet apps use it, you'd still have troubles 
extending it.  Except that you could use the class to create IDNs and 
life would be good.

>As a

The problem is that DNAME was poorly specified to begin with (it was 
only PS) and still became widely deployed.  There's nothing wrong 
with DNAME on paper that can't be fixed with a few keystrokes but the 
impact in deployed code is said to be great.

>Such an outcome would serve nobody.

Dang, this is why I don't usually read this far into messages, 
because I hate to see folks mention me.  Yes, I think that the WG 
could benefit from firmer guidance through the workload but there are 
other dilemmas.  We have a lot of Proposed Standard documents that 
haven't progressed to Draft Standard because they need fixes - but 
frequently fixes are shot down based on there being some existing 
code base.  DNAME is one example of that.  Just about any "-clarify" 
has faced that problem.

>I am having a hard time coming to a conclusion about that.

It's true that the discussion to date has co-mingled solving for a 
particular and ill-defined "business case" (IDN) and solutions 
offered so far.  There are other reasons to make "two zones work the 
same" but we just haven't talked about them.

The DNS is a simple protocol and that is its genius.  That's not to 
say that we can't improve it, but mission creep has a negative 
connotation.  Such as adding night vision to a weapon system 
resulting in adding weight and thus lessening mobility.  DNS benefits 
so many in so many ways, small changes can have large consequences, 
so lots of old codgers like to say "are you really sure you want 
that?" before accepting new work.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 May 2010 00:18:43 -0400

>Please elaborate.  I fail to see how this would be a problem for CNAME+DNAME.

Tomorrow I can expound more - but the answer lies in "why was the 
CNAME restriction was put in place to start with?"  E.g, what is the 
response to "<owner>/class/DNAME> directed to an owner name with a 
CNAME+DNAME at the authority and the cache only has the CNAME?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: David Conrad <[email-masked]>
Date: Wed, 19 May 2010 21:47:14 -0700

Andrew,

On May 19, 2010, at 7:58 PM, Andrew Sullivan wrote:
> impression I've given.

To be honest, I've gotten the same impression as Mark and it has been a bit frustrating.  I'm glad to hear that impression is mistaken.

> alone among them) seem to have worked around this.  

Err, it is a work around because a problem exists. It would be unfortunate that the work around be used as an excuse not to solve the problem in a more appropriate way.  Or do you believe administratively synchronized domains is a scalable, general, long-term solution?

> The answer to

I'll admit some confusion here.  I thought I saw at least two people provide a fairly clear statement of the problems they'd like to see solved and since you agree (1) is "yes", it would seem to imply that at least one problem was positively identified.  Are you saying (3) is open because there is more than one problem to solve?

> And finally, question (4) is wide open. It's what I've been talking about most in this recent thread.

Confused here too.  The discussions regarding consequences is a direct result of analysis of proposed solutions to perceived problems, which would appear to suggest (1) through (3) have answered positively (after all, you wouldn't discuss consequences if you weren't discussing potential solutions to problems).

> progression.  

Well, yes, but that is hardly unique to DNSEXT.  It seems quite easy for the IETF to get trapped in design-by-committee spinning, attempts to create ivory tower perfect solutions, and non-productive navel gazing, but this isn't the right venue for that discussion.

> I worry that something as dramatic as the BNAME and shadow zone

A valid concern.  However, it is worth noting that there appear to be folks with active interest in addressing the problem(s) that have been identified as their businesses depend on it. As such, a solution will be created. Failure to standardize on a particular solution would likely mean we'd either have a de facto standard defined by one or two vendors or interoperability failures or both.  This is also a non-optimal outcome.

> The question is whether on the whole they are good for the DNS.

I don't understand the question.  What does it mean to be "good for the DNS"?

To me, the questions we need to answer are quite simple:

0) is the base protocol defined by the IETF?
1) is there a problem?
2) do multiple independent parties need a standardized solution to that problem?
3) are there folks who will work on a solution within the context of an IETF working group?

If the answer to these are yes, then the work should be undertaken by the IETF.  Value judgements of "good for X" seem to me to be a breeding ground for Ratholes Of Unusual Size.

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 May 2010 04:55:35 +0000

> Date: Thu, 20 May 2010 00:15:38 -0400
> From: Edward Lewis <[email-masked]>
> 
> ... poor ordering of the fields (specifically the class coming after the
> name in the envelop) and the use of fixed size fields (necessary for the
> old processing budgets but rather constraining today).  The latter was
> helped by EDNS, the former is a lost cause.

is this a new drinking game? deal me in. there should never have been an
RRCLASS field, since all records in a message must have the same class as
QCLASS. (as all records in a zone must have the zone's class.) and worse,
rrsets should have been slabbed on the wire. finally, for now anyway, we
should have had a character encoding for on-the-wire, specifying USASCII
case insensitivity as one option, and specifying binary names otherwise.

if anybody tops those i'll have to chug a beer or something, after which
i will start in on dns's "presentation layer".

---

From: "Jiankang YAO" <[email-masked]>
Date: Thu, 20 May 2010 17:02:07 +0800

----- Original Message ----- 
From: "David Conrad" <[email-masked]>
To: "Andrew Sullivan" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 20, 2010 12:47 PM
Subject: Re: [dnsext] One chair's focus (was: On adoption of two drafts)

>3) are there folks who will work on a solution within the context of an IETF working group?

Your questions are quite clear to me.

I like your question styles above. It seems that your questions are the normal questions many other WGs do like ask when they encounter the similar situations.

Jiankang Yao

>If the answer to these are yes, then the work should be undertaken by the IETF.  Value judgements of "good for X" seem to me to be a breeding ground for >Ratholes Of Unusual Size.
>
>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 May 2010 13:13:21 +0000

> From: "Jiankang YAO" <[email-masked]>
> Date: Thu, 20 May 2010 17:02:07 +0800
> 
> I like your question styles above. It seems that your questions are the
> normal questions many other WGs do like ask when they encounter the
> similar situations.

+1.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 May 2010 10:28:50 -0400

>i will start in on dns's "presentation layer".

Well, the point was, I wouldn't say that flexibility was one of DNS's 
strengths.  There are a lot of things we could do better on in the 
second design but are constrained because of the installed base, that 
is, DNS isn't all that flexible.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 20 May 2010 15:14:26 +0000

On Thu, May 20, 2010 at 10:43:12AM +1000, Mark Andrews wrote:
> We keep thinking "is this a solution

Mark, I think I agree with you in principle, but it would be helpful
if you (or anyone) could provide an example of a case where one or
another of the tools we've been discussing is "a good tool to have in
the tool chest" outside of the IDN context.

> better tool for you as it provides more freedom.

What does "bundle namespaces" mean, besides "what bname does"? I've
only heard references to "bundling names" or "bundling namespaces" in
the IDN context, so again it would clarify things to have an
additional case.

> than being focused on "are these good tools in their own right".

I suspect it looks this way because the use cases we're presented with
have been wrapped in IDN (not just TLD) considerations. If that's the
defining use case for whatever we're actually doing here, we should
admit it. If not, let's see some others.

Suzanne

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 May 2010 10:11:06 +1000

> the tool chest" outside of the IDN context.

BNAME in for classless in-addr.arpa delegations.  It permits you
to redirect the name and the namespace under the name.

DNAME doesn't work for classless in-addr.arpa in the /25-/32 range.

> the IDN context, so again it would clarify things to have an

See classless in-addr.arpa delegations for other examples.

---

From: "Damick, Jeffrey" <[email-masked]>
Date: Fri, 21 May 2010 16:31:41 -0400

We (UltraDNS) have also developed a feature that is very similar to the BNAME proposal.  So I will just throw our particular use case into the mix..

Customers want to create an alias for an existing (primary) domain such that they can modify a (primary) domain and all changes will be reflected in the results from any alias domains.  The results are then sent back as if they belong to the alias domain.

Based on feedback it appears that this is desirable feature, so  I'm sure a standard solution like BNAME would be useful, particularly for exchanging these aliases.

On 5/20/10 5:02 AM, "YAO Jiankang" <[email-masked]> wrote:

----- Original Message -----
From: "David Conrad" <[email-masked]>
To: "Andrew Sullivan" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 20, 2010 12:47 PM
Subject: Re: [dnsext] One chair's focus (was: On adoption of two drafts)

Jiankang Yao

---

From: Florian Weimer <[email-masked]>
Date: Sat, 22 May 2010 16:06:59 +0000

> the tool chest" outside of the IDN context.

Somewhere (the dns-operations list) the idea of unsigned zone copies
recently came up, to provide some means for end-user-controlled
fallback in case of DNSSEC failures.

I would also like to know how some form of aliasing helps to address
the lack of signalling in IDNA.  From what I've read, there are some
difficulties transitioning to a new IDNA encoding scheme if you don't
want per-TLD rules in clients.  (I thought of IDNA as some sort of
hashing scheme, it was only recently that I learned that the ability
to go back from the hash to the pretty name was part of the spec.
>From that perspective, the Greek sigma and German ess-zett issues are
indeed problematic.)  It seems to me that we still need TLD-specific
behavior, and this leads me to the question why we need a DNS-level
solution at all.

-- 
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: Ondřej Surý <[email-masked]>
Date: Mon, 24 May 2010 11:14:27 +0200

> the tool chest" outside of the IDN context.

I think it's buried somewhere deep in the list archive, but I have 
listed few examples:

1) For anybody with more than 1 domain name with same name (f.e. 
sury.name, sury.org, sury.cz) or (hp.cz, hp.com, hp.co.uk, hp.<anytld>).

2) Mass webhosting:
    webhoster creates base name: template1.webhosting.tld
    and aliases all it's customers using CNAME+DNAME or BNAME

    Imagine how simple would be to setup f.e. Google Apps with this,
    instead of creating all kind of weird records in your zone file.
    You would just create CNAME+DNAME at registrar level pointing to
    a.google.com.

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 24 May 2010 12:20:13 +0200

On 24.5.2010 11:48, Florian Weimer wrote:
> * Ondřej Surý:
> Does this really work in practice because usually, you want mail to
> work, too?  RFC 1123 requires that CNAMEs are expanded by the sender,
> so you can't be certain that your mail server gets the original name.

I have never seen a MTA which did canonicalization (but that doesn't 
mean there isn't any).

You can try it yourself, I have created:

deneb.dname.cz.	IN	CNAME	deneb.enyo.de.
deneb.dname.cz.	IN	DNAME	deneb.enyo.de.

enyo.dname.cz.	IN	CNAME	enyo.de.
enyo.dname.cz.	IN	DNAME	enyo.de.

in my CNAME+DNAME test zone.

So Postfix doesn't do anything to those names:

<[email-masked]>: host ka.mail.enyo.de[87.106.162.201] said: 550
     relaying denied (in reply to RCPT TO command)

<[email-masked]>: host ka.mail.enyo.de[87.106.162.201] said: 550
     relaying denied (in reply to RCPT TO command)

Same with Gmail:

Delivery to the following recipient failed permanently:

     [email-masked]

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the 
recipient domain. We recommend contacting the other email provider for 
further information about the cause of this error. The error that the 
other server returned was: 550 550 relaying denied (state 14).

Delivery to the following recipient failed permanently:

     [email-masked]

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the 
recipient domain. We recommend contacting the other email provider for 
further information about the cause of this error. The error that the 
other server returned was: 550 550 relaying denied (state 14).

Ondrej

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 24 May 2010 14:40:22 +0200

On 24.5.2010 12:36, Florian Weimer wrote:
> Sendmail does it by default.

Yep, you're right.  I have just tested that.  Hence my example with mass 
hosting is not usable.  That's great to have not only different 
protocols handling CNAME differently, but also different MTAs handling 
CNAME differently.

BTW this applies to IDN usage of BNAME as well, since there is CNAME 
expansion for non-complying clients.  And if you alias two trees there 
will be some matches for sure.

Ondrej

---

From: Tony Finch <[email-masked]>
Date: Mon, 24 May 2010 14:32:29 +0100

On Fri, 21 May 2010, Damick, Jeffrey wrote:

> We (UltraDNS) have also developed a feature that is very similar to the
> BNAME proposal.  So I will just throw our particular use case into the
> mix..
>
> Customers want to create an alias for an existing (primary) domain such
> that they can modify a (primary) domain and all changes will be
> reflected in the results from any alias domains.  The results are then
> sent back as if they belong to the alias domain.

Isn't that more like the zone clone proposal, not the BNAME proposal?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL MALIN: MAINLY NORTHEASTERLY 4 OR 5, OCCASIONALLY 6 EXCEPT IN NORTHWEST
ROCKALL. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 May 2010 14:17:09 -0700

> Isn't that more like the zone clone proposal, not the BNAME proposal?
The Amber/Shadow zone does not represent aliased names of an Amber zone, 
unlike the BNAME proposal.
see:
http://tools.ietf.org/html/draft-vixie-dnsext-dnsshadow-00

The BNAME proposal defines an RR type that offers an alias for itself 
and all lower nodes.
see:
http://tools.ietf.org/html/draft-yao-dnsext-bname-01

The BNAME proposal may require more language to better define how 
synthesized CNAMEs are to be swallowed by BNAME RRs.  The table at 4.2 c 
is amended by a subsequent sentence relating to when a CNAME is to be 
expunged.  It also seems extended queries may find non-uniform results, 
which might also lead to caching conflicts.

-Doug

---

From: Florian Weimer <[email-masked]>
Date: Mon, 24 May 2010 14:50:36 +0200

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

* Ondřej Surý:

> Yep, you're right.  I have just tested that.  Hence my example with
> mass hosting is not usable.  That's great to have not only different

The *NAMEd names are second-class citizens in a second aspect: Several
protocols explicitly require canonical names in some places (on the
right-hand side of NS and MX records, for instance), and you have to
be careful not to use *NAMEd names there.  Again, this restriction is
not enforced by all clients.

I guess it's an interesting task to write zone editing software which
allows the user to enter cleartext (non-punycode) names.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 24 May 2010 12:36:57 +0200

---

From: Florian Weimer <[email-masked]>
Date: Mon, 24 May 2010 11:48:58 +0200