Subject: [dnsext] we've been assuming that only one label matters

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Dec 2009 09:11:11 -0500

Catching up on the various proposals, it seems that we are thinking 
in terms of making X.tld. and Y.tld. equivalent but not thinking of 
X1.X0.tld. and Y1.Y0.tld. as needing to be equivalent.

DNAME and CNAME rewrites won't handle this, nor CLONE.  Multiple 
delegations could but that would result in an explosion of zones.

Is there an approach which involved the stubs learning to 
"normalize?" the query before sending it on - or building this into 
the first name server to see the query?  (Even if equivalence is 
restricted to names, not types.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Florian Weimer <[email-masked]>
Date: Mon, 21 Dec 2009 15:27:53 +0000

* Edward Lewis:

> Catching up on the various proposals, it seems that we are thinking in
> terms of making X.tld. and Y.tld. equivalent but not thinking of

Do you mean differently-encoded labels in the same name?

I was under the impression that the variant duplication within a
single zone was acceptable.  With any sort of redirection, the effort
is not n*m, but n + m.

> Is there an approach which involved the stubs learning to "normalize?"

This does not work for email submission, which is a disconnected
operation in general, and has to use a Punycode name.  If we ignore
email submission, some sort of signalling/application logic clearly is
the way to go.

-- 
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: Edward Lewis <[email-masked]>
Date: Mon, 21 Dec 2009 10:53:10 -0500

>Do you mean differently-encoded labels in the same name?

Not just that.  Even the same encoding.

E.g., WwW.MyDoMain.SLD.tld. and wWw.Mydomain.SlD.TLD. need to be the 
same.  Imagine the upper case is traditional Han, lower case is 
simplified Han.  As a short example.  (And what if I mix upper case 
and lower case Greek labels - realize I am not likely to give a good 
description of the Greek case.)

>single zone was acceptable.  With any sort of redirection, the effort

This is, once again, not just a problem for zones, it's a problem for domains.

(Is there general confusion between what a zone is and a domain is?)

>email submission, some sort of signalling/application logic clearly is

Email can deal with upper/lower case presentation, can we extend this 
to other issues.

What I am positing is that this may be a Prensentation Layer issue 
and not a Data Space issue.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Florian Weimer <[email-masked]>
Date: Mon, 21 Dec 2009 16:14:02 +0000

> This is, once again, not just a problem for zones, it's a problem

Yes, but it seems possible to address this just with redirection
alone, with a moderate amount of bloat at the zone level.

> What I am positing is that this may be a Prensentation Layer issue and
> not a Data Space issue.

I'm not sure if those ISO terms are useful here.

Clearly, email needs to submit raw data (which means UTF-8 or an
injective encoding of that), or the client needs to access to the
applicable mapping table.  Otherwise, you end up with problems at the
MTA because when the user agent has submitted a name which has been
over-normalized (according to the prefered encoding format for the
name).

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Dec 2009 17:09:14 +0000

> Date: Mon, 21 Dec 2009 09:11:11 -0500
> From: Edward Lewis <[email-masked]>
> 
> the query before sending it on - or building this into the first name
> server to see the query?  (Even if equivalence is restricted to names,
> not types.)

i think we've ruled out any approach that requires the stubs to be
upgraded before the clones are visible.  at least, i am constraining
my own work along those lines.

an "explosion of zones" may be the cost of adding this functionality,
but as long as the explosion is only felt by silicon and not by human
operators, i consider the cost reasonable.

---

From: John Levine <[email-masked]>
Date: 21 Dec 2009 18:57:00 -0000

>my own work along those lines.

That seems reasonable.  On the other hand, mail and web servers are
going to need to be upgraded or at least reconfigured to know what
variant domains they're supposed to handle, so perhaps it's not a
big leap to expect at least the server side DNS to be upgraded
to know how to respond.

R's,
John

---

From: Edward Lewis <[email-masked]>
Date: Mon, 21 Dec 2009 14:05:58 -0500

>my own work along those lines.

(Who is "we"?  And why have "we" ruled out approaches before having a 
agreed upon problem statement?)

Why rule out upgrading stubs?  Wouldn't it make sense that stubs 
would be upgraded as the ends want support for newer domain names? 
Time was, we would upgrade BIND because we wanted the latest types, 
dynamic update, DNSSEC, etc. - the latest features.  Things that have 
relied upon central system upgrades (DNSSEC) take the longest.

>operators, i consider the cost reasonable.

"Felt only by silicon" forgets that currency pays for silicon 
(capital expense and operational expense) and that currency comes 
from humans.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Dec 2009 20:48:59 +0000

> Date: 21 Dec 2009 18:57:00 -0000
> From: John Levine <[email-masked]>
> 
> That seems reasonable.  On the other hand, mail and web servers are going
> to need to be upgraded or at least reconfigured to know what variant
> domains they're supposed to handle, so perhaps it's not a big leap to
> expect at least the server side DNS to be upgraded to know how to
> respond.

something's got to be upgraded or there will be no change in behaviour.
simplistic classification of the things that could be upgraded are:

1. some delegating (parent) nameservers but maybe not all
2. all delegating (parent) nameservers
3. some authority (base + clone apex) nameservers but maybe not all
4. all authority (base + clone apex) nameservers
5. recursive servers all over the internet (inevitably never all of them)
6. recursive forwarders all over the internet (inevitably never all of them)
7. stubs all over the internet (inevitably never all of them)
8. client side applications (mail, web, etc) over the internet (inevitably
   never all of them)
9. server side applications (mail, web, etc) over the internet (inevitably
   never all of them)

of these, i am personally ruling out the ones that number in the millions,
hundreds of thousands, tens of thousands, and thousands.  if we have that
much work to do before these names are visible, then it'll be ten years or
longer before there's any economic incentive to deploy them server-side,
and the world will find some other way to meet their need for domain cloning.
for the moment, i'm concentrating on a solution that uses only #4 above,
because it puts the workload (upgrading name servers) where the incentive
will be (wanting the clone names to work.)  (that's "engineering economics".)

of course, if a mail or web server is currently known by a single name and
is about to receive connections from clients who know it by another name,
then it will have to be upgraded or reconfigured.  reconfiguration is the
most likely, since these servers universally understand "aliasing" today
and so there are configuration hooks available for that.  upgrading, though,
is an attractive option since it would allow a server to gather a list of
clone names it's also known by, via RRTYPE=CLONE queries, and to thereafter
treat all of those names as real, none as aliases.  this would affect server
generated messages and transactions which usually come from a server's "real
name".  however, upgrading of server side applications should not be required
and simple configuration aliasing using existing software should just work.

---

> Date: Mon, 21 Dec 2009 14:05:58 -0500

i'm working from the problem statement andrew sullivan sent out originally,
which asks us for names which are "the same as" other names.  "we" is maybe
the wrong word-- some people may still be hunting down a problem statement
or may still be considering names which are "almost but not quite the same
as", along the lines of CNAME+DNAME, or ENAME.  (don't let me stop you.)

> Why rule out upgrading stubs?  Wouldn't it make sense that stubs would be
> upgraded as the ends want support for newer domain names? Time was, we
> would upgrade BIND because we wanted the latest types, dynamic update,
> DNSSEC, etc. - the latest features.  Things that have relied upon central
> system upgrades (DNSSEC) take the longest.

stubs number in the hundreds of millions and most of those are in ROM.  a
gethostbyname() library function in an embedded system is part of what i
mean by "stub".  see above in my reply to john levine -- if we come up with
names which are "the same as" other names only to stubs who are upgraded,
then the world will move on without us and find some other way to clone
their names, because the world will recognize the ten year 50% point.

> "Felt only by silicon" forgets that currency pays for silicon (capital
> expense and operational expense) and that currency comes from humans.

obviously if we can find a solution that has even less cost then we should
prefer it.  but silicon has gotten cheaper and more powerful every year of
my life, and i'm not willing to adopt the pessimistic view that that will
or could ever stop happening.  humans on the other hand have gotten slower
and more expensive every year of my life, and i'm not willing to adopt the
optimistic view that that will ever stop happening.  so, looking at this
from engineering economics, a cost borne only in silicon is preferrable in
the design of a global and permanent system, than a cost also borne by
humans.

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Tue, 22 Dec 2009 13:19:06 +0200

Dear Florian,

Our request is to make

Name1.gr
Name2.gr
Name3.gr
Name4.gr 

working one like the other, using name1.gr as master name.

So

Name1.gr IN NS ns1.name1.gr

Name2 xNAME Name1
Name3 xNAME Name1
Name4 xNAME Name1

This way, with a little tweaking

[email-masked]|
[email-masked]|-> [email-masked]
[email-masked]|

http://name2.gr=http://name3.gr=http://name4.gr = http://name1.gr

The same goes for ftp etc.

However, since we will all pretty soon have the opportunity to register .GreekIDN, this service will have to extend to the level

[Name1.gr. xNAME Name2.GreekIDN.] or even [gr. xNAME GreekIDN.]

Best Regards,

Vaggelis Segredakis

---

From: "YAO Jiankang" <[email-masked]>
Date: Wed, 23 Dec 2009 09:55:20 +0800

this draft may help solve the problem.

http://www.ietf.org/internet-drafts/draft-yao-dnsext-bname-00.txt

----- Original Message ----- 
From: "Vaggelis Segredakis" <[email-masked]>
To: "'Florian Weimer'" <[email-masked]>; "'Edward Lewis'" <[email-masked]>; <[email-masked]>
Cc: "'Sotiris Panaretou'" <[email-masked]>; "'Γιώργος Κολυβάς'" <[email-masked]>
Sent: Tuesday, December 22, 2009 7:19 PM
Subject: RE: [dnsext] we've been assuming that only one label matters

Dear Florian,

Our request is to make

Name1.gr
Name2.gr
Name3.gr
Name4.gr 

So

Name2 xNAME Name1
Name3 xNAME Name1
Name4 xNAME Name1

[email-masked]|

However, since we will all pretty soon have the opportunity to register GreekIDN, this service will have to extend to the level

Best Regards,

Vaggelis Segredakis

---

From: Danny Mayer <[email-masked]>
Date: Fri, 25 Dec 2009 14:14:15 -0500

> X1.X0.tld. and Y1.Y0.tld. as needing to be equivalent.

Actuslly you really mean X.tld. and Y.tle. since these are likely to be
cross-TLD issues. Then you would have X1.X0.tld. and Y1.Y0.tle. I
suspect that the latter is really just another case of the former.

> server to see the query?  (Even if equivalence is restricted to names,

Danny

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 25 Dec 2009 19:55:00 +0000

> > X1.X0.tld. and Y1.Y0.tld. as needing to be equivalent.

i'm thinking of both cases.

> suspect that the latter is really just another case of the former.

agreed, they are equivilent.

> > delegations could but that would result in an explosion of zones.

in my thinking about zone clones, there is such an explosion, but it's only
felt by electrons and photons, not by humans.  and it does handle the cases
of (X1.X0.tld = Y1.Y0.tle) and (X1.X0.tld = Y1.Y0.tld).

> > server to see the query?  (Even if equivalence is restricted to names,

if someone proposes such a mechanism i predict that it would succeed in the
sense that IETF would agree to standardize it, but when we get to the point
where we "let the market decide" between BNAME, zone clones, and stub-aware,
the market will not choose stub-aware for at least the first decade or so.

---

From: Danny Mayer <[email-masked]>
Date: Fri, 25 Dec 2009 22:35:38 -0500

> working one like the other, using name1.gr as master name.

On a non-DNSSEC BIND9 server the master can be defined very simply with
relative names in the zone for all labels (including the SOA). Slaves
still need separate zone files. I am sure that other implementations can
do similar things. This all changes of course when you add DNSSEC
records to the mix.

> Name1.gr IN NS ns1.name1.gr

See above. Without DNSSEC this can easily done today.

> [email-masked]|-> [email-masked]

That's a matter for the mail server. We don't need to deal with that here.

> http://name2.gr=http://name3.gr=http://name4.gr = http://name1.gr

This is a matter for the HTTP server. We don't need to deal with that here.

> The same goes for ftp etc.

Ditto.

> [Name1.gr. xNAME Name2.GreekIDN.] or even [gr. xNAME GreekIDN.]

This does not change what I said above.

So far everything I've read indicates that this is a DNS management
problem rather than a protocol problem. The only servers that need to
know anything about the fact they they are really the "same" zone is the
master and the slaves, ie the authorative servers. Nothing else needs to
worry about it. So the problem comes down to managing this. The main
part of the zone, ie all of the A, AAAA, NS, MX, etc. records are the
same and can be include either by a file or a database configuration of
some kind. The main issue then is managing the DNSSEC specific records
for each domain since that's specific to the name of the domain.

So what we seem to need here are better management tools.

I've never operated a major domain so I don't know if I have
misunderstood the problem or do not see the major headaches that such an
operator or registrar needs to deal with.

Danny

---

From: Alex Bligh <[email-masked]>
Date: Sat, 26 Dec 2009 09:32:55 +0000

--On 25 December 2009 19:55:00 +0000 Paul Vixie <[email-masked]> wrote:

> in my thinking about zone clones, there is such an explosion, but it's
> only felt by electrons and photons, not by humans.  and it does handle
> the cases of (X1.X0.tld = Y1.Y0.tle) and (X1.X0.tld = Y1.Y0.tld).

+/- effects on caching.

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Sat, 26 Dec 2009 17:26:35 +0000

> Date: Sat, 26 Dec 2009 09:32:55 +0000
> From: Alex Bligh <[email-masked]>
> 

yes.  only a wire change involving stub awareness could avoid effects on
caching.  and as i've said, if someone proposes such a wire change, i
predict that it would be accepted as a WG item and eventually standardized.
however, because of the long tail on DNS systemwide upgrades, if
alternatives such as BNAME and/or "clone zones" are also standardized, i
also predict that the market would choose among those alternatives, caching
be damned, it's instant functionality.

there are some value judgements to be made if the WG decides it wants a
better problem statement before deciding whether to accept proposals.  for
example perhaps we don't want to standardize more than one approach to this,
or perhaps we don't want to standardize an approach which is expensive in
terms of cache, or which is explosive in the number of (virtual) zones.  in
those cases we might not be able to answer the original problem statement
("names which are the same as other names") and we would go back to the rest
of the internet and say "because of DNS limitations we can only offer you
names which are almost the same as other names").

---

From: Alex Bligh <[email-masked]>
Date: Sun, 27 Dec 2009 08:28:39 +0000

--On 26 December 2009 17:26:35 +0000 Paul Vixie <[email-masked]> wrote:

> caching.

What I was thinking was that an approach where any equivalent label
is equal to any other has a possible O(a^n) effect on cache, whereas
an approach where at each level there is a given label (which might
be chosen by the operator, or chosen arbitrarily, such as 'alphabetically
first') which is the canonical one has an O(n) effect on cache. It
might be possible to push this information on the wire to the resolver
in addition to coping with non-compliant resolvers.

So, in the above example (using an alphabetic rule, or assuming
the operator chose labels x1, x0, tld in preference to the alternatives)
when looking up tle would get cached by a compliant as a ?NAME for tld,
y0 as a ?NAME for x0 and y1 as a ?NAME for x1. There would never be
any need to store the 8 combinations.

A bit like DNAME synthesis.

-- 
Alex Bligh

---

From: Michael Graff <[email-masked]>
Date: Sun, 27 Dec 2009 05:43:52 -0600

I've been sitting out of this discussion so far, but can't help but
chime in just before driving for a day.  Give people plenty of time to
flame me. :)

If what is wanted is a way to logically clone a zone, and there is a
need for it today, people will use whatever tricks available to them
today.  This will include not using DNSSEC.

Topics like caching are to me a side discussion.  Caching is important,
but not strictly required for a client to work properly.  Big ISPs will
want to use big caches, but those big caches can cope with additional
data.  Perhaps they'll throw out some little-used data as a side effect
and keep some other little-used data in its place.  In a very large
cache, I suspect the histogram of times used drops off fairly quickly.

I therefore think any concern about how method A affects the cache, if
all it does it cause more data to go into it, is not important.  If it
causes data to not be cachable at all, well, that's another issue, but
no one has proposed that.

I personally think it's a tool issue, and no protocol changes need to
happen.  I don't see why the IETF needs to solve a problem using
protocol when it's fairly clear to me that any real solution involving
protocol changes is more or less a non-starter.

The purpose of publishing zone data is that people will use it.  If no
one today can use this new proposed protocol, no publisher will use it
either.  Even when 80% of the clients out there support it, 20% don't,
so no one will risk their domain going dark.

What is needed here, if a protocol solution IS the answer, is a way to
do what people do today -- just sign the same data N times -- and a
protocol to make it more efficient for clients which support this new
protocol in the future.  This encourages the end-users to upgrade, and
the publishers to use this new protocol in addition to older methods.
However, since the risk of upgrading either end-point is very low, it
also encourages people to use it.

Good luck.  :)

- --Michael

---

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

> protocol changes is more or less a non-starter.

Well said!

Although the problem statement hasn't been written yet, it appears the  
underlying issue is one of provisioning and/or administrative  
convenience. If that's the case then it's not something that needs  
fixing in the DNS protocol. Or should be fixed there IMO. The  
complications of a protocol solution look very ugly: backwards  
compatibility with the installed base; impact on DNSSEC deployment;  
potentially icky corner cases like wildcards, zone cuts and Additional  
Section processing; impact on caches and resolvers; operational  
considerations when managing name servers or debugging/troubleshooting  
"live" problems; etc, etc.

More clarity about the nature of the actual problem is needed. Once  
that is forthcoming, I hope this WG can reach a consensus around an  
*engineering* decision on whether the cure is worse than the disease.

I think it would also be helpful if this problem statement could  
explain why DNAME'ing the cloned zones won't work. Or (in BIND terms)  
why multiple zone{} statements for the clones won't work either or are  
"too expensive". For some definition of expensive.

I also wonder if it's feasible to come up with a meaningful way of  
saying zoneA/labelA is the same as zoneB/labelB, particularly in the  
context of IDN. There are bound to be problems here where a label in  
one script or language cannot be mapped into another or would be  
meaningless/inappropriate if it was. These problems could be  
intractable because they intrude into issues that are out of scope for  
the IETF: questions of TLD registry policy or of cultural, social and  
political identity for example. As a for instance, I would be more  
than displeased at a DNS construct which said "Scottish zone/label A  
is the same as British zone/label B or (worse) English zone/label C".  
Another less hypothetical example is Katakana which is mostly used in  
Japan for transcribing words imported from other languages IIUC. So it  
may be unacceptable for an IDN label for Kanji or Hiragana string to  
have a Katakana clone and vice versa.

> protocol in the future.

A protocol solution is likely to have a non-trivial impact on Secure  
DNS. Any takers for DNSSEC-quad? :-)

---

From: Alex Bligh <[email-masked]>
Date: Wed, 30 Dec 2009 18:06:30 +0000

--On 30 December 2009 14:00:12 +0000 Jim Reid <[email-masked]> wrote:

> More clarity about the nature of the actual problem is needed. Once that
> is forthcoming, I hope this WG can reach a consensus around an
> I think it would also be helpful if this problem statement could explain
> why DNAME'ing the cloned zones won't work. Or (in BIND terms) why
> multiple zone{} statements for the clones won't work either or are "too
> expensive". For some definition of expensive.

I may well be missing something, and perhaps haven't fully understood
the problem statement, but I'd tend to agree with Jim here.

I appreciate there is a maintainability problem in that one needs
to determine whether one must write
	foo	IN	NS 	colour.example.tld
or
	foo	IN	NS	color.example.tld
(assuming colour and color are the two equivalents), but one would
have thought a BCP containing an algorithm that chooses one of
the above, possibly arbitrarily but always consistently, would
be sufficient.

That said, to the extent there is a problem needing solving, there
does not appear to be any point in inventing another ?NAME unless it
solves everything Paul's problem statement set out to solve.

-- 
Alex Bligh

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Dec 2009 18:05:54 +0000

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

that's been explained.  grep florian weimer and edward lewis in the
archives.  i agree that a problem statement would nec'ily include their
observations, but i'm less sure that anybody here should claim ignorance
of those observations.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Dec 2009 19:13:59 +0000

> Date: Wed, 30 Dec 2009 18:06:30 +0000

for IDN this might be possible.  but andrew asked us to consider the
problem "how to make one name exactly like another" and asked us not
to constrain our thinking to the IDN use case.

> solves everything Paul's problem statement set out to solve.

(it's andrew's problem statement, which i'm the one who keeps repeating here.)

at a minimum, DNAME does not redirect its owner name since there might be
other RRs there (SOA and NS, if it's a zone apex), and CNAME does not
permit other RRs to share its owner name, so our alternatives for alias
names (which are not "exactly like" other names but they're pretty close
for most purposes) were:

	1. relax the CNAME-and-other-data constraint to allow CNAME+DNAME.
	2. change the semantics of DNAME so that it covers its owner name.
	3. define a new xNAME that does what CNAME+DNAME would be like.

of the three, #1 and #2 require that the installed base be upgraded, whereas
#3 does not.  therefore BNAME has been proposed.

however, these are alias names, which are not exactly like other names, and
so i'm still thinking about "zone clones" (or "clone zones", depending on
how you look at it.)  the reason i don't think of this as a trivial problem
subject to out-of-band operational practices, is because of interactions
between primary and secondary servers, which might be implemented by
different parties, and operated by different parties.  "zone clone" is my
way to ensure that a zone can be served even across architectural
boundaries and administrative boundaries.  in that sense it's like SOA's
timers, which could just as easily have been made into an operational
problem, but then we would lack a standard that allowed secondary and
primary name servers to cooperate in zone management unless they were all
implemented and/or operated by a single party.  that would never have scaled,
and DNS has to scale.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 Dec 2009 15:18:54 -0500

> to constrain our thinking to the IDN use case.

Yes, I did.  Let me explain a little my thinking.

I know that it's often a dangerous practice to try to solve problems
you don't know about yet.  At the same time, it seems to me that there
are already two inventions (CNAME and DNAME) that _kind of_ solve the
problem of making two names "just like another", and they're both
being abused in nasty ways in an effort to get the behaviour people
really want.  Neither of them actually works the way users want.

In the end, I am of course willing to accept an answer tailor-made for
the IDN problem: we have a real use case before us that has a
compelling need, and I think we'd be fools to refuse to solve that for
the long term (even if whatever we do can't be used tomorrow).  But I
think we have enough big brains around here that it is worth trying to
solve the more general problem first, to see whether we can come up
with something that solves more than one problem at once and that
provides a facility that many DNS-naive people think already exists.
(I have heard, more than once, "What do you mean there's no real
aliasing in the DNS?"  People who don't run nameservers really do
think this is just an obvious thing that ought to just work, and
saying that it's hard does not elict a friendly smile.)

I am painfully aware that some people dislike these sorts of
discussions that lead us off into speculation-land; but if we, the DNS
protocol extension community, won't try to tackle the general case, I
am not sure who will ever do it.  Instead, we'll get a long series of
special-case handlers.  My personal, no-hat opinion is that a large
number of special cases is usually less desirable than one general
handler.  Not everything can be solved this way, though, and I'm
totally open minded about the present case.

All of that said, I expect that pretty soon (probably mid-January)
Olafur and I will try to provide a shortish summary of what we
understood from the WG's discussions.  We'll be soliciting specific
direction from WG participants at that point.  In the meantime, if you
have a proposal or idea you want to work out, please either outline it
here, put it together as a specific proposal in an I-D, or both.

Thanks very much to everyone who continues to participate in this
discussion.  It's very helpful to me, and I think it is also helpful
to our user community (who have, after all, a problem they're feeling
-- even if it's one you might think isn't as hard as they believe it
to be).  The only reason we have to continue our work as a WG is that
we are addressing needs felt on the Internet, and I think this is a
genuine case.

Best regards,

A

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 31 Dec 2009 08:30:16 +1100

> solves everything Paul's problem statement set out to solve.

Why?

There are some that would be happy with (requested) a DNAME + CNAME
equivalent.  There are differnet cost/benefit tradeoffs here.  We might
actually want to provide multiple solutions.

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

---

From: Alex Bligh <[email-masked]>
Date: Wed, 30 Dec 2009 22:13:20 +0000

> really want.  Neither of them actually works the way users want.

I suppose what I don't understand (quite possibly due to my own
ignorance) is why the IDN problem can't be solved at the tool
level, and what the non-IDN problem is at all, beyond the normal
"DNS is not a panacea" observation.

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Wed, 30 Dec 2009 22:22:05 +0000

> actually want to provide multiple solutions.

My rationale was that every protocol change has a cost for implementors
and deployers, each of which have some large % outside those asking for
change. If there is to be a change of that requires some standards
action, then between two possible changes that affect the same set
of software, one might as well pick the one that (a) solves the
problems "properly" (which of course requires understanding what the
problem(s) are) and (b) solves multiple problems simultaneously.
Paul's proposal was (broadly speaking) constrained to authoritative
servers, and it's difficult to think of a practical smaller subset
of affected software that isn't just a "tool change". Hence, if we
aren't just going to change the tools but make a protocol change,
we might as well go for what Paul suggests.

When you say "DNAME + CNAME equivalent" what does that mean that is
different from DNAME + synthesis?

-- 
Alex Bligh

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 Dec 2009 17:41:30 -0500

> "DNS is not a panacea" observation.

I think the argument in favour of doing something has been made more
than once in this thread, as well as in some different recent threads
on this list.  Ed Lewis presented, I think, the most recent kick to
such threads, in the form that I find most compelling.  If you really
need references, please send me mail off-list, and I'll track down the
particular versions of the arguments in the last month or so of
archives.

If what you're saying in "don't understand" is instead, "I don't find
this argument compelling," that's fine with me, but I'd prefer to hear
it in a more direct way.

A

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

---

From: Alex Bligh <[email-masked]>
Date: Wed, 30 Dec 2009 23:16:52 +0000

> this argument compelling," that's fine with me, but I'd prefer to hear

I got the "something needs doing" argument. I didn't get the "something
needs doing that can't be solved with tools" argument. I admit to
being a bit distracted with other stuff when the mail was coming through,
so shall go and reread.

-- 
Alex Bligh

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 31 Dec 2009 10:55:27 +0000

> different from DNAME + synthesis?

	The latter only covers descendants.

	What's sought (archives: Vaggelis Segredakis) is something
	to cover at one blow self and descendants.

	/Niall

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Jan 2010 09:41:05 +1100

> 	to cover at one blow self and descendants.

By "DNAME + CNAME equivalent" I ment a record that does both at once.

BNAME doesn't (yet) do the right thing.

* Firstly BNAME needs hop-by-hop BNAME understanding signalling from
  day one.

* Secondly you return a BNAME or a synthesised CNAME depending upon the
  BNAME understanding signalling.  You never return both for the same
  QNAME in a response.  If synthesised CNAME won't fit you return
  NXDOMAIN for the non-BNAME aware client, YXDOMAIN for a BNAME aware
  client.

* Thirdly a zone containing a BNAME, MUST NOT be signed with any
  of the currently assigned algorithms.  I would suggest that we have
  aliases for RSASHA256 and RSASHA512 which indicate BNAME support
  in addition to NSEC3 support (e.g. RSASHA256B, RSASHA512B).
  DSA, GOST maybe.  Do not privide aliases for RSASHA1, RSAMD5 and
  NSEC3RSASHA1.  Future algorithm assignment will imply NSEC3 and
  BNAME compliance.

This will allow DNSSEC to work and not require keys to be kept
online.  Forwarders of a BNAME aware server need to also be BNAME
aware.  This is similar to NSEC3 where forwarders need to be NSEC3
aware for NSEC3 zones to work, or even plain DNSSEC.

In this way a BNAME unaware validator will treat the zone as insecure.

With DNAME we tried to do to much (always sending DNAME) and not
enough (we didn't make DNAME DNSSEC compatible).  We know how to
do it better now.

Happy New Year

Mark