Subject: [dnsext] Some thoughts on the updated aliasing draft

From: Ted Hardie <[email-masked]>
Date: Sat, 26 Mar 2011 10:51:51 -0700

The draft under discussion  was updated just before the meeting, and it has
some useful updates.  I think, however, it is anxious to scope the problem
in ways that leave out what I believe is a well-recognized aspect of the
basic desire of those who brought the work forward.  The draft says:

  To some extent, the desired behavior can be described: "identical DNS
  resolution" means that the process of resolving two domain names will
  end with the same result, in most cases the same IP address.  In the
  history of DNS protocol development, there have been two attempts to
  specify such "identical resolution" behavior:CNAME[RFC1034] which
  maps or redirects itself, and DNAME[RFC2672] which maps or redirects
  its descendants.  In the case of bundles or groups of names, however,
  some operators have asserted they need identical DNS resolution at
  all levels' domain names, including the domain name itself and its
  descendants.

But the reality is that the operators actually want the applications to
treat two domain names as the same.  That's a lot harder than simply having
the same IP returned when looking up an A record at each one.  Especially in
the case of secured zones, it involves issuing multiple certificates or
certs that cover both, and otherwise ensuring that whatever services are
present at that IP can effectively handle either name.  It's moderately
obvious that this is a tougher job than putting in a CNAME or DNAME.

It is possible to store additional data in the DNS that asserts X=Y for some
values of X, Y, and equals, and we could, theoretically, mint records that
had appropriately scoped forward knowledge about other equivalent domains.
Where apparent administrative domains are crossed, it may take additional
work to check that all parties concur.  It gets ugly fast, but it may be
better than the alternate of brute-force registration.

The real trouble, though, is getting applications to check for the existence
of such records.  The DNS is a known-item lookup protocol, and it basically
has to return the information that corresponds to the question that was
asked.  It can return additional data, but if it does so, there is a fairly
serious risk that only the answer to the question asked will be stored and
forwarded to the consuming application.

The only way around that that I can see at the moment is to either declare
one record to be canonical (forcing applications to "correct" any names they
are currently using to the canonical name) or use an additional layer of
indirection so that all of the records that are the same point to some
meta-target.  That might work--it's the same basic use of pointers that's
already present in CNAME, but it requires a pointer from all the "same"
domain names to some target that's not in the set.  The structure of that
record might be the same as the normal targets, using something like prefix
addressing to signal its use; it might also have a different structure.

But the problem remains daunting.  Even if DNSEXT creates the perfect record
for sameness, we still have to get apps to check it--and that suggests to me
designing the system for that goal should be a primary consideration in the
design space.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "John Levine" <[email-masked]>
Date: 26 Mar 2011 20:33:36 -0000

>But the reality is that the operators actually want the applications
>to treat two domain names as the same.  That's a lot harder than
>simply having the same IP returned when looking up an A record at
>each one.

This seems blindingly obvious to me, but I get the impression that
there is still a faction that thinks that if they can arrange for
matching A records, they're done.

>The only way around that that I can see at the moment is to either
>declare one record to be canonical (forcing applications to "correct"
>any names they are currently using to the canonical name) or use an
>additional layer of indirection so that all of the records that are
>the same point to some meta-target.

Agreed.  One point that I think is not well understood is that the
structure in the DNS and what the users see need not be perfectly
matched.  In particular, it's quite possible for the DNS to have one
canonical record with everything else pointing to it, but at the
application level all the names look the same.  If I were hacking on
my web or mail servers to handle this stuff, a simple way to do the
configuration would be to configure in the canonical name, and then
set a flag saying also to handle all of the aliases.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Sun, 27 Mar 2011 05:29:52 +0000

> Date: 26 Mar 2011 20:33:36 -0000
> From: "John Levine" <[email-masked]>
> 
> ...  In particular, it's quite possible for the DNS to have one

if we're allowed by the people asking for this to require dns client
libraries and applications to have to be changed to handle a new kind
of canonicalization before they'll be able to handle the new definition
of "sameness" then this is a practical approach.

'dns client libraries and applications' means the whole internet, so i
naturally assumed that this approach was out of scope.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 27 Mar 2011 09:14:00 +0000

> > set a flag saying also to handle all of the aliases.

In terms of where we are with the problem statement: I think we've
determined that we can assume a canonical or base name, with others
pointing to it, is not only OK but the only practical approach, since
a more complete isomorphism is hard to describe and may be impossible
in the current DNS.

Where we still have some thinking to do (IMHO, but as doc editor) is
in chracterizing the need, if any, for some property of "sameness" or
"aliases-of" amongst a group of names such that the application
doesn't just get what it would have gotten if the alias was the
canonical name in the first place. 

>From the registry provisioning side, what seems to be wanted is "the
applicaton can get an identical result but for less work on the part
of the provisioning registry/registries (and maybe more work on the
part of the API/resolver) to simply provisioning all of the names in
parallel."

This may also be what applications want, but it doesn't include
visibility to the application of other associated names, or the fact
that there are any. Creating such a property and giving the applicaton
access to it is a different requirement, and at the moment is hard to
see clearly as an application issue, an API/interface issue, or a DNS
protocol issue (in any combination).

> naturally assumed that this approach was out of scope.

It would be useful to document where we think this line is. Send text.

thx,
Suzanne

---

From: Ted Hardie <[email-masked]>
Date: Sun, 27 Mar 2011 11:35:59 +0200

> canonical name in the first place.
I thought I was with you until this.  Presumably what it gets at the alias
is a pointer to the canonical name, rather than what it would have gotten if
the alias *was* the canonical name.  The advantage of this synthesized
CNAME-style approach is that the client libraries learn that what they
originally handed the DNS was a pointer.  In the ideal case, they can use
that information to update their handling as well (within limits, of course)

> part of the API/resolver) to simply provisioning all of the names in
To put this another way, you don't have to provision everything to provide a
complete set of pointers, as the first pointer tells the client how to
synthesize them.

> protocol issue (in any combination).
So, just to restate this for my own jet-lagged benefit:  the client hands a
name to the DNS and gets back the information that it's a pointer to a
canonical name, along with the data required to synthesize other names ("You
asked for "blue.color.example.co.uk.  All names under and including
color.example.co.uk are cannonically at or under colour.example.co.uk").  So
the application could get back "Here's the data for
blue.colour.example.co.uk; the requested you handed me returned a pointer to
here".  If it doesn't understand that , it gets the data at the record
stored at blue.colour.example.co.uk.

Does this match what you're thinking?

Ted

---

From: "John Levine" <[email-masked]>
Date: 27 Mar 2011 19:25:12 -0000

>of canonicalization before they'll be able to handle the new
>definition of "sameness" then this is a practical approach.

It seems to me that we can divide applications into two groups.  In one
group, the client uses the name to find a server, but the name never
appears in the data stream or only appears as a comment.  This includes
FTP, SSH, POP, and IMAP.  Something like BNAME would be adequate to make
names look the same to users.  I'd say these applications don't know
what their names are.

In the other group, the domain name appears in the data stream, and
the server does something with it beyond resolving it to an A or AAAA
record.  The standard examples are SMTP and HTTP.  These apps do know
what their names are, and the only alternatives I see are a great deal
of manual provisioning, or else they learn how to check the DNS to see
whether a hitherto unknown name in the data stream is an alias of a
canonical name that it does know.  So, yeah, the applications will
eventually have to change.

>From the point of view of DNS design, I'd want something that returns
an appropriate A or AAAA for the first group, and offers a
straightforward way for the second group to see what's an alias of
what.

For a transition, it's still possible to configure the second group
manually, but it'd be a lot easier if they got smarter so people
didn't have to do so.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Sun, 27 Mar 2011 21:37:06 +0000

> Date: 27 Mar 2011 19:25:12 -0000

these would be, in the parlance used when this topic was first introduced,
"second class names".  they can't be used as the target of MX or NS RRs,
and they won't work for services whose servers have not been upgraded.

if we're allowed to produce second class names as our answer to the problem
then this is news to me but it massively simplifies the work.  and we will
have the burden of explaining to all of the IDN people that these "second
class names" will have precisely zero value for the first few years and
very little value for the first few decades.  and, making them believe us.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 27 Mar 2011 22:13:19 +0000

> Does this match what you're thinking?

I think so, but I may well not be quite this smart :-)

The two cases are "I understand the pointer and can do my own
synthesis, give me all you got" and "I can't understand the pointer"
and the server does the synthesis. In the first case, the application
sees that the name it asked for was a pointer, and gets the rest of
the set of associated names; in the second, it doesn't know and
presumably doesn't care, but has no access to the rest of the names or
the knowledge that they're associated together.

The question I think I was asking was whether the application might
sometimes prefer the simple answer, and not see the pointer or the
other names. 

I'd like an answer along the lines of "Nope, it's always OK and
sometimes preferred to expose the full complexity and let the
application sort it out." But, you tell me.

Suzanne

---

From: "John Levine" <[email-masked]>
Date: 27 Mar 2011 22:31:14 -0000

>these would be, in the parlance used when this topic was first
>introduced, "second class names".  they can't be used as the target
>of MX or NS RRs, and they won't work for services whose servers have
>not been upgraded.

Seems to me we can do some process of elimination here.

What people would like is a magic DNS hack so that you can tell your DNS
server that a bunch of names are equivalent, and all the other software
on the net treats those names just the same.  Sorry, no pony.  You can't
have that.

If it's an absolute requirement that no software outside the DNS can
change, then our answer is clear: manual name bundling, with manual
configuration of applications, we're done, so long.  I don't hear much
support for that.

So what can we offer?  If it's something like CLONE or BNAME, we offer
an upgrade path.  You're no worse off than you'd be with manual
bundling and manual application configuration, and to the extent you
upgrade your applications to know about the new DNS stuff, your
configuration job gets easier.

That's not as cool as the mythical magic hack.  Will people find it
useful?  Having done my share of SMTP server hackery, I would.  If
it's as important to handle variant names as people say it is, they'll
upgrade.  If not, well, that's OK too.

R's,
John

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 27 Mar 2011 22:47:49 +0000

> very little value for the first few decades.  and, making them believe us.

Well....I hope they will speak for themselves, but I think at this
point that what "the IDN people" want from the DNS people is some real
sense of what's possible, with roughly what tradeoffs. I think they
want any news we can give them, even if it's bad (and I'm not even
sure this is bad news).

We can go into this a little more (briefly) in the session Monday
afternoon-- Andrew and anyone else who was in the ICANN IDN meetings
in San Francisco can probably shed some light.

Suzanne

---

From: Mark Andrews <[email-masked]>
Date: Mon, 28 Mar 2011 12:47:17 +1100

> eventually have to change.

And SMTP had it correct for the second group.  If the SMTP client
sees the CNAME it re-writes the names in the SMTP exchange to use
the cannonical host name.  The SMTP server never see the alias.

HTTP administrators often miss use CNAME.

"www.example.net CNAME example.net" where the same content is
returned regardless of the the presense of www in the HTTP
stream is correct usage of CNAME.

If you use CNAME and you get different content then you are miss
using CNAME.  It's not being using to find the cannonical name for
the host.

Whether it is a virtual host or a name virtual host, the target of
the CNAME record is not the cannonical host name of the (named)
virtual host.  It is the hosting server for that site and that is
a very different thing.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 28 Mar 2011 11:45:18 +0900

> the cannonical host name.  The SMTP server never see the alias.

It does not forbid RFC822 headers contain aliases.

E-mail recipients may change their behavior based on the domain
names of senders in RFC822 headers.

> using CNAME.  It's not being using to find the cannonical name for

Not at all.

						Masataka Ohta

---

From: "John R. Levine" <[email-masked]>
Date: 27 Mar 2011 22:50:10 -0400

> the cannonical host name.  The SMTP server never see the alias.

Yes and no.  That works OK if you expect the CNAME to be a nickname for 
the real name, and the user is happy to see his message headers rewriten 
to use the canonical name.  It fails in the situation where the names are 
all equivalent, and you don't want the messages rewritten.

It also doesn't address the security issue, if you want the owner of the 
canoninical name to have control over what can be aliased to it.

> HTTP administrators often misuse CNAME.

True, but the horse is dead, and the carcass was long ago sold for 
dogfood, so I don't see the point of dredging it up again.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Cary Karp <[email-masked]>
Date: Mon, 28 Mar 2011 08:10:43 +0200

Quoting Suzanne

> in San Francisco can probably shed some light.

The impression I got from the ICANN IDN meetings in San Francisco was
that the people who frequent such events have a strong qualitative sense
of there being a problem but haven't yet managed to articulate it
clearly, much less solve it. What might constitute a solution from their
perspective is similarly elusive, but in ICANN terms would mean
something that can serve as a basis for "consensus policies" (the
sidestepping of which caused the present headache, in the first place).

The expectation on the ICANN side has always been that the technical
community, by virtue of its superior understanding of the quantifiable
intricacies of the DNS, would be able to extrapolate whatever it needs
to know about "the problem" from the discussion as it is being conducted
in the ICANN venue. There is no basis for assuming that the potential
insufficiency of that belief can be successfully communicated, so the
best we're going to be able to do here is second guess something that
might actually help. If that were an unequivocal statement of bad news,
I have no idea how it would be received, but suspect that it's unsafe to
make any assumptions about its potential for bringing the discussion to
an end.

/Cary

---

From: Xiaodong Lee <[email-masked]>
Date: Mon, 28 Mar 2011 14:50:06 +0800

From my impression in ICANN meeting in SF, people with IDN variant 
issues want IETF give a perfect solution or give a answer if having 
solution or not, but actually even IETF give solution, it's impossible 
to solve issues that ICANN people concerns, to develop the standard and 
deploy the software is a very long term solution.

For this draft, we try to define the problem statement, but how to 
solve, and if we should solve it with adding new RR, is to be discussed.

Regards,

--
Xiaodong Lee, CNNIC

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Mar 2011 06:51:22 +0000

> Date: 27 Mar 2011 22:31:14 -0000
> ...

let's get consensus around these as our only alternatives and if so
publish the finding and ask for instructions.  right now the fact that
all we can offer is second class names is private dnsext-only opinion
and needs to be upgraded to public knowledge so as to inform a decision.

> upgrade.  If not, well, that's OK too.

i believe have unsligned (assymetric in fact) incentives here.  the folks
who would have to upgrade are those providing services (internet wide).
the folks who want this upgrade to happen are the name producers/sellers.
we did the same thing in EDNS0 and that's why i predict a very long tail.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Alex Bligh <[email-masked]>
Date: Mon, 28 Mar 2011 09:52:04 +0000

> and they won't work for services whose servers have not been upgraded.

NS records perhaps, but I'm not sure MX is as big a deal as all that.
Assume the worst happens, and a CNAME is synthesized. This works in
(say) 99% of cases already, and a draft modifying the appropriate
SMTP RFC would legitimise it. I suspect most of the usage for such
names would be IDN related, and that you'd get more breakage from
old SMTP speakers with config files that don't like IDN / new TLDs
than CNAME MXes (I seem to remember my sendmail/uucp config in
93 had all the TLDs hardwired in - it would not be a tragedy if
this ceased to work).

-- 
Alex Bligh

---

From: Tony Finch <[email-masked]>
Date: Mon, 28 Mar 2011 13:40:29 +0100

> the cannonical host name.  The SMTP server never see the alias.

That has not been true for over ten years.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Tyne, Dogger: Variable, mainly south or southwest 3 or 4, occasionally 5.
Slight or moderate. Fair. Good, occasionally poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Mon, 28 Mar 2011 13:52:02 +0100

> upgrade.  If not, well, that's OK too.

Yes.

I think it's worth splitting the feature into forward and reverse parts.

The forward direction is alias -> canonical, as in CNAME and DNAME. We can
use CNAME synthesis to support old clients, and perhaps a DNSSEC algorithm
bump to avoid validator problems. Old servers can work with the new BNAME
(or whatever) aliases using their existing support for aliases, which
typically means explicit per-alias configuration.

The reverse direction is canonical name -> alias list, which is for the
server to automatically configure its aliases from a trusted part of the
DNS. (Does the client have any use for this information?) Servers that
understand this feature are easier to configure. This feature is also
useful if the aliases no not use BNAME, e.g. if they are CNAMEs or A or
AAAA records.

Both the new forward and reverse features will be useful independently of
each other.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Westerly or southwesterly, becoming cyclonic at times, 4 or 5,
occasionally 6 in Biscay and Fitzroy. Moderate or rough. Rain or showers, fog
patches in north Biscay. Good to poor, occasionally very poor in north Biscay.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "John Levine" <[email-masked]>
Date: 28 Mar 2011 12:51:48 -0000

>we did the same thing in EDNS0 and that's why i predict a very long tail.

You may be right.  I don't have any insight to what extent the actual
users who speak Greek, Chinese, et al. care about making multiple
spellings work the same in their mail and web applications.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Mar 2011 18:19:02 -0700

On 3/26/11 10:51 AM, Ted Hardie wrote:
> The draft under discussion  was updated just before the meeting, and 
> it has some useful updates.  I think, however, it is anxious to scope 
> the problem in ways that leave out what I believe is a well-recognized 
> aspect of the basic desire of those who brought the work forward.  The 
> draft says:
>
>
> simply having the same IP returned when looking up an A record at each 
> one.  Especially in the case of secured zones, it involves issuing 
> multiple certificates or certs that cover both, and otherwise ensuring 
> that whatever services are present at that IP can effectively handle 
> either name. It's moderately obvious that this is a tougher job than 
> putting in a CNAME or DNAME.
DNAME does not offer a practical solution when implemented at the roots, 
since it lacks the meta information that would be needed to synchronize 
different zones.  It seems possible to use this scheme to construct the 
resources to convey which domains are replicated, such as as placing 
this under some label, like "xn--lba" or "._®--".

Any alias scheme will cause unwanted delays.  With two different 
encoding for A-labels, 2003 or 2008, dropping A-labels and using 
U-labels  reduces the number of domains to be replicated. See
http://tools.ietf.org/html/rfc6055

While it is clear A-labels are needed by e-mail applications, the 
wording about what is legal is less clear when aliased resources are 
employed.  Are A-labels really needed and would
http://tools.ietf.org/id/draft-vixie-dnsext-dnsshadow-00.txt
provide a means to register domain name-sets?

-Doug

---

From: Florian Weimer <[email-masked]>
Date: Tue, 29 Mar 2011 09:55:14 +0000

> designing the system for that goal should be a primary consideration in the

The problem is worse: applications routinely do not have access to the
public DNS when the proposed sameness or normalization step would have
to be performed.  For example, I'm writing this message on an
IDNA-capable mail client (it will use Punycode for the domain part
during submission if necessary), but the system it runs on lacks
access to the public DNS.  While our network is probably not
representative at all, I'm sure that the phenomenon (lack of DNS
access) is common on corporate networks.

There is something that borders on willful ignorance of this fact.
But it is pretty clear to me that you cannot use DNS for protocol
version signalling (this is what the IDNA folks really need, it just
got perverted to aliasing because an IDNA-specific kludge was not
received favorably) when you haven't got access to the DNS at the
point where you need the information.

-- 
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
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 Mar 2011 13:04:45 +0100

Florian Weimer <[email-masked]> wrote:
> to be performed.

I think we should be clear whether we are talking about a server
being provisioned or a client making a request.

I find it hard to believe a client has no access to the DNS when making a
request, though it might be indirectly, and possibly via an interface that
only provides access to a limited set of RR types. But any solution we
come up with has to work with existing clients or it will never be
deployable.

A server does not have to get its list of aliases from the DNS. Being able
to do so is a convenience but it is likely to be undesirable in some
situations or impossible if the server software doesn't support it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Wight, Portland, Plymouth: Southeast 3 or 4 veering southwest 4 or 5,
occasionally 6 in Plymouth later. Slight in Wight, otherwise slight or
moderate. Showers, fog patches. Moderate, occasionally very poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Doug Barton <[email-masked]>
Date: Wed, 30 Mar 2011 16:32:29 -0700

If I may do so without seeming immodest, I believe that the CLONE draft 
adequately addresses all of the concerns raised in this thread so far. I 
haven't had any feedback on the -01 version yet, so hopefully this is an 
opportune time for a gentle prod (because I know that those of you in 
Prague don't have enough to do already). :)

Doug

http://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit-01

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/