Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

From: Alex Bligh <[email-masked]>
Date: Tue, 01 Mar 2011 09:28:31 +0000

--On 1 March 2011 00:37:39 +0000 Niall O'Reilly <[email-masked]> 
wrote:

> 	SMTP has MX; others have SRV; HTTP is an outlier in that it
> 	avoids this kind of assistance from the DNS.  It's a significant
> 	and pathological outlier because of the way HTTPS works.

I'd look at it another way:
* SMTP has email forwarding (rewrite envelope TO)
* HTTP has 301 Permanent redirect.
* SIP has 3xx REFER (from memory)

All these make traffic to one place go to another. However in each
case in the 'S' variant of the protocol, you need to provide a separate
certificate for the alias to the canonical name, which means you
can't automatically configure / synthesise the alias config in
the same way you can for the non-'S' variant. What MX / SRV
are allowing you to do for services that support them is hide
this with another level of indirection.

For that indirection to be applied to http (e.g. use SRV records) you'd
need a change at the client end (to use SRV records or whatever) but also
at the server end, so if a.example.com = b.example.com, and both have SRV
records to c.example.com, then server c must use the cert for a or b as
appropriate. In https that's hard as the cert is chosen before the GET line
comes through. As solving this latter problem is enough to solve the entire
issue for https, I am not sure the SRV record thing helps if it works like
a normal SRV record.

I *think* what you need is a REDIR record or similar, which achieves
the effect of a redirect/rewrite/refer of the DN part. It's only visible
to the application. It doesn't need to specify ports as it
could clone whole DNs. For https you could (say) only redirect if the
record was signed. I suppose you could make it redirect wildcards.

-- 
Alex Bligh
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 1 Mar 2011 10:49:20 +0100

On Mon, Feb 28, 2011 at 12:40:55PM -0500,
 Dan Schlitt <[email-masked]> wrote 
 a message of 38 lines which said:

> Weren't we told that we weren't dealing with "words" even though
> some things might look like words. This means that we don't have to
> deal with things like the difference between american english and
> british english.

In that case, it has to be said explicitely in the I-D (with
explanations of why english/american is less important than
simplified/traditional chinese).

But I understand the current draft as saying "We will not decide if
the difference between color.example and colour.example is significant
or not. We will just provide a neutral mechanism to make them 'the
same', should someone - typically the registry - decides they are the
same."  Am I correct in this reading of the I-D?

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 1 Mar 2011 10:25:45 +0000

On 1 Mar 2011, at 09:28, Alex Bligh wrote:

> appropriate.

	I'm thinking of a different way, which appears to avoid this problem.

	SRV maps a domain name (OK, a service,transport,name triple) to
	a (set of) host name(s).  If this mapping is provably legitimate
	(DNSSEC), then the browser need only verify that the cert matches
	the final host name.  Matching what I've chosen to call the
	'domain-part' of the http URL is no longer useful.  Used in this way,
	SRV gives us aggregation of certificates: one per target host rather
	than one per secure hosted web site.

	I may be missing something, but I think this needs only client-side
	code changes.  Service-side, certificate administration becomes
	different, but not code.

	ATB
	Niall

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 1 Mar 2011 10:27:42 +0000

> 	code changes.  Service-side, certificate administration becomes

	Doh! s/Service/Server/
	N

---

From: Alex Bligh <[email-masked]>
Date: Tue, 01 Mar 2011 11:28:00 +0000

> 	code changes.  Service-side, certificate administration becomes

So if a.example.com = b.example.com, and both have a SRV record to
c.example.com, then the client does an SRV lookup on (say) b.example.com,
receives the SRV record, then does an HTTP GET request to c.example.com
and (crucially) the GET line is
  GET http://c.example.com/
not
  GET http://b.example.com/
I believe that needs to be the case because the server needs to always
send back the same HTTP cert (as the decision in what cert to use is
prior to the GET line).

I'm a bit confused as to what you propose appears in the URL bar. IE
does the user know he's been redirected? Do local links on the
page appear as links from b.example.com or a.example.com?

That's fine, except

1. it appears to be less backwards compatible than what I suggested
   (where the canonical URL will always work), though perhaps you
   could use (e.g.) a.example.com as the target of the SRV record
   and somehow loop detect.

2. It would be a useful property of a solution that it could redirect
   entire subsections of the tree. Else we are back to manually
   provisioning.

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 1 Mar 2011 12:36:27 +0000

I'm inclined to tease this out off-list, and spare the others
	the blow-by-blow.

On 1 Mar 2011, at 11:28, Alex Bligh wrote:

> and (crucially) the GET line is [...]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 1 Mar 2011 11:08:38 -0500

2011/2/27 Patrik Fältström <[email-masked]>:

> 2. Support of more application layer aliases
>
> 2.1. In HTTP and a few other protocols, we have the ability to do a redirect inside the application layer protocol itself. We do not have that in all protocols. In other we have things like the MX records. Do we with IDN etc need more of these, and do we need a mechanism in DNS that "help" such redirect in a "lower" layer in the resolution algorithm?
>
> 2.2. When using HTTP HOST header, and SSL where the DN of the cert is matched with the domain name used, it is kind of problematic to match the application layer with what originally was entered by the user. Is there some need for DNS layer aliases that changes what later is matched in the application layer comparisons?

I would say not.

The legacy HTTP protocol requires that the name presented in the Host
header be the name that is present in the URL. There is no provision
for rewriting as far as I am aware.

Let us imagine we want a mapping a.com = b.com and the name a.com is
presented. There are two design choices:

1) The client performs the rewrite.

The best way to achieve this in my view would be to present a Host
header for b.com and add in a new header to tell the server that the
original origin was a.com

This is compatible with legacy servers but not legacy clients.

2) The Server performs the rewrite.

This is really hard to achieve as it requires the server to know that
the mapping even exists.

Typically a server is responding to hundreds of domains. Even large
production servers do this. If a server receives a request for a.com
it has no means of knowing that it 'should' map that to b.com unless
the DNS configuration is somehow mapped to the Web administration.

This is quite straightforward to handle administratively when the
mapping is www.b.com to b.com because the source and target are in the
same administrative zone. But this is not going to work if the mapping
is being controlled by a TLD.

3) Don't support the aliasing requirement.

'nuff said.

Note that in both cases the administrative model is only practical if
there is a mapping of one name to another. It is futile to attempt to
make the names 'the same' without nominating a canonical form.

The legacy of Web servers is far more complex and difficult to change
than legacy user applications. Web services are a different matter.

Writing a Web browser is rather complex and there is a pretty high
bar. There is very little demand for Web browsers that are not as good
as Firefox or Chrome or IE or Safari or Opera (that is not an
exhaustive list but most other browsers out there have a lot of common
code with the above) There is a huge demand for Web servers that are
smaller and lighter than Apache.

To give you an idea of just how embedded these web servers are, you
can get an ethernet socket that looks just like a regular socket but
interfaces to an RS232/422 port and has a Web server and TCP/IP stack
built into the plug. It is a cheap way to add ethernet connectivity to
SCADA equipment. There are more brands of that type of connector than
major web browser.

There are a lot of cruddy Web browsers on phones but I don't think
they get used more than a few times and they function so poorly that
breaking them worse does not really matter much. The good mobile
browsers all come from companies that are actively developing them.

Web services are trickier. At one level they are quite easy because
people who write mashups are already using pretty unfriendly URLs to
identify service endpoints. But I think that has to be a temporary
condition. We should be using SRV and other advanced discovery to make
these connections.

So with this in mind, I think that there is a brief window of
opportunity in which we could make this change for Web Services
applications. Over the past few weeks I have been discussing my ESRV
scheme with principles in the Web Services platform space at major
vendors who control and drive the relevant platforms.

Since any Web Services support infrastructure would have to be buried
deep in the scripting libraries used for making mashups, it would not
be difficult to add in an aliasing requirement. But we have to be very
quick if that is going to happen. The window is going to close very
soon.

> 4. How do we ensure skilled apps people manage to work with skilled DNS people so that the end result is optimal? (something IETF is not always very good at...)

Skill in HTTP will probably only provide a better understanding of the
range of constraints.

There is 18 years of legacy here and a lot more complexity than in DNS.

-- 
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Mar 2011 11:18:33 +0000

On Tue, 1 Mar 2011, Alex Bligh wrote:
>
> However in each case in the 'S' variant of the protocol, you need to
> provide a separate certificate for the alias to the canonical name,
> which means you can't automatically configure / synthesise the alias
> config in the same way you can for the non-'S' variant. What MX / SRV
> are allowing you to do for services that support them is hide this with
> another level of indirection.

The situation with TLS and SMTP is a mess. Inter-domain SMTP with TLS does
not work with certificate validation. There is no specification for how to
validate the TLS certificate for an MX server, and it is not obvious what
such a specification should say. In practice the vast majority of deployed
MX TLS certificates cannot be validated, neither against the MX owner name
nor against the MX target.

http://www.imc.org/ietf-smtp/mail-archive/msg05366.html

Message submission (RFC 4409) doesn't use MX records and works well with
certificate validation, just like POP and IMAP. Note that these three
protocols use the DNS in the same way as HTTP (and FTP, and telnet, and
ssh, etc.) so I don't think HTTP is an outlier as Niall said - it's just
old school.

> In https that's hard as the cert is chosen before the GET line comes
> through.

This is what TLS server name indication is for.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Plymouth, Biscay, FitzRoy: Northeast 5 to 7. Moderate or rough. Showers. Good.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Mar 2011 22:41:48 +1100

In message <[email-masked]>, Tony F
> nor against the MX target.

If you read RFC 821 the HELO response should be used to check that
you are talking to the machine you are expecting to.

   3.5.  OPENING AND CLOSING

      At the time the transmission channel is opened there is an
      exchange to ensure that the hosts are communicating with the hosts
      they think they are.

      The following two commands are used in transmission channel
      opening and closing:

         HELO <SP> <domain> <CRLF>

         QUIT <CRLF>

      In the HELO command the host sending the command identifies
      itself; the command may be interpreted as saying "Hello, I am
      <domain>".

The MX owner name never make sense.  The MX target is *suposed*
to be the (singular) cannonical name of the machine.  The fact that
people abuse this doesn't mean that the MX target shouldn't be used.

-- 
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: Tony Finch <[email-masked]>
Date: Thu, 3 Mar 2011 11:44:54 +0000

> is being controlled by a TLD.

On the contrary, this is trivial for the server to do by dynamically
looking up a.com and seeing if it is a BNAME pointing at b.com.

However the server administrator probably does not want the server to
accept requests for arbitrary domains just because they have a BNAME
pointer.

So there has to be a list of valid aliases somewhere accessible to the
server, either in the DNS for b.com (used like "paranoid" reverse DNS
checking) or in the server's configuration.

Given the existence of HTTP redirects, I'm not entirely sure that it is
reasonable to forbid DNS aliasing. But server administrators are free to
choose between loose dynamic configurations and tight explicit
configurations without affecting clients.

The question for this group is if we specify something like BNAME if we
should also specify how to put the corresponding back-references in the
canonical domain.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Malin: South, veering northwest later, 3 or 4. Moderate or rough. Occasional
rain. Moderate or good, occasionally poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Mar 2011 12:24:37 +0000

On Thu, 3 Mar 2011, Mark Andrews wrote:
> Tony Finch writes:

RFC 821 is thorougly obsolete. In particular the canonicalization
requirements that existed in the 1980s were relaxed in the 1990s and no
longer apply.

In any case, the server's host name indicators are useless for secure
server authentication, which is the whole point of TLS.

If I am sending mail to an address at dotat.at, I need to securely verify
that the server I am talking to is supposed to receive mail for dotat.at.
So the TLS certificate must authenticate the MX owner name, dotat.at, not
the MX target mx.cam.ac.uk, nor the virtual service instance name
ppsw-mx-e.csi.cam.ac.uk nor the physical service machine name
ppsw-51.csi.cam.ac.uk. If you authenticate the MX target name or the
server's claimed canonical host name, you are open to attack.

Note that SMTP is able to use one transaction to send a message with
multiple recipients at different domains hosted on the same server. So the
server needs to be able to present a certificate authenticating all of the
mail domains it hosts. The server can't use TLS SNI to select a
certificate dynamically because SNI only allows one name of each type
which is incompatible with SMTP's multi-domain transaction support. In
fact, if the client uses persistent connections it probably does not know
at the time it negotiates TLS which mail domains it might encounter that
deliver to the server.

Now perhaps this mess - both the protocol mess and the deployment mess -
can be fixed by using the firmer foundations that DNSSEC provides, but
that requires protocol development.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: Westerly or northwesterly 3 or 4, occasionally 5, increasing 6 later
in north. Mainly moderate, occasionally rough later. Fog patches for a time.
Moderate or good, occasionally very poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Mar 2011 00:35:41 +1100

In message <[email-masked]>, Tony F
> server authentication, which is the whole point of TLS.

But they show what *should* be checked.   The MX record also needs 
to be checked.
 
> server's claimed canonical host name, you are open to attack.

No.  SMTP is store and forward.  The MX records (cryptographically
verifiable with DNSSEC) say that you should be talking to mx.cam.ac.uk
and if you don't get a TLS connection that says you are talking to
that machine you should drop the SMTP connection.
 
> at the time it negotiates TLS which mail domains it might encounter that

No.

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Mar 2011 13:56:39 +0000

On Fri, 4 Mar 2011, Mark Andrews wrote:
>
> No.  SMTP is store and forward.

That makes no difference.

Most store-and-forward hops in SMTP are within an organization, and in
that situation mail routing is not based on the MX records of the
recipients' mail domains. (cf. message submission) The organization can
secure its mail transmission using its knowledge of its own setup.

The important and difficult case is inter-domain SMTP which does rely on
MX records and cannot rely on prior arrangements for authentication.

> The MX records (cryptographically verifiable with DNSSEC) say that you
> should be talking to mx.cam.ac.uk and if you don't get a TLS connection
> that says you are talking to that machine you should drop the SMTP
> connection.

TLS predates DNSSEC. It security model assumes DNSSEC does not exist.
Therefore TLS must authenticate the domain seen by the end user. It makes
no sense to authenticate the MX target hostname because that makes you
vulnerable to spoofing.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Irish Sea: Variable 3 or 4. Slight. Fog patches. Moderate, occasionally very
poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Mar 2011 01:45:59 +1100

In message <[email-masked]>, Tony F
> That makes no difference.

It makes all the difference in the world.  MX records DO NOT AND NEVER
HAVE DEFINED FINAL DELIVER they have only ever defined the NEXT HOP.
 
> MX records and cannot rely on prior arrangements for authentication.

And that is done by publishing MX records (secure with DNSSEC) or in their
absence (secure with DNSSEC) constructing a MX record from the A/AAAA records
(secure with DNSSEC).
 
> TLS predates DNSSEC.

Yes and it did not work securely because there was no way to validate
the DNS responses.

> It security model assumes DNSSEC does not exist.

The security model assumed the DNS responses were good.  We can now
prove they are good.

> no sense to authenticate the MX target hostname because that makes you

Nope.  Flawed logic here.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Mar 2011 09:47:39 -0500

OK, I am not yet convinced that this is acceptably secure, but I withdraw my
earlier objection, see below.

> looking up a.com and seeing if it is a BNAME pointing at b.com.

That would not meet my definition of 'straightforward'. From a security
point of view, having my server mappings controlled by BNAMES in the TLD...

> accept requests for arbitrary domains just because they have a BNAME

So it is straightforward but stupid, OK we seem to agree here.

> configurations without affecting clients.

There is a big difference between a redirect issued by the administrator of
the target and a redirect issued by a third party.

> should also specify how to put the corresponding back-references in the

That could help the situation. It could be quite efficiently encoded as a
circular list. Each alias would have a link to the canonical name and the
next alias in the list.

This would also act to prevent an alias being effected without the consent
of the target domain since they would have to recognize the list.

Consider the following.

let canonical.tld be the target and alias.tld and alias.atld be the aliases.
An appropriate configuration would be:

! Records maintained by admin for tld and atld

canonical.tld       NS   <blah>
canonical.tld       xlnk   alias.tld
alias.tld           xname  canonical.tld
alias.tld           xlnk   alias.atld
alias.atld          xname  canonical.tld
alias.atld          xlnk   canonical.tld

! Records maintained locally
canonical.tld       A      10.0.0.1
canonical.tld       AAAA   1:00:1
canonical.tld       clnk   www.canonical.tld
canonical.tld       xx
www.canonical.tld   cname  canonical.tld
www.canonical.tld   clnk   canonical.tld

I can see a fairly strong separation of control there.

This mechanism could in principle be used by either clients or servers. It
could also be used by resolvers synthesizing up a dynamic HTTP response.
That would give us a chance of getting a deployment to actually happen.

So an aware resolver needs to be able to know if the server is capable of
accepting the request or not. If the server accepts this type of alias it
can simply return the records and get out of the way. Otherwise an HTTP
redirect is going to be required.

The resolver could do this by pinging the Web server, but it is better to
have that information in the zone. Hence the need for the xx record which is
basically a way to say 'this zone handles this extension'.

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Mar 2011 19:39:26 +0000

> HAVE DEFINED FINAL DELIVER they have only ever defined the NEXT HOP.

MX record define the inter-domain hop, which is where the mail crosses a
trust boundary, and where authentication is required.

The other store-and-forward hops (from submission to outgoing border
relay; and from incoming border MX to final delivery or to alias
redirector) are within trust boundaries and so they are easier to
authenticate.

> Yes and it did not work securely because there was no way to validate

TLS doesn't try to validate the DNS responses, it verifies that you have
successfully connected to a server that can act for the domain you wanted
to reach. If TLS validation succeeds the DNS lookup must necessarily have
given you the right result.

It isn't possible to use DNSSEC to secure a TCP connection to a server
because it doesn't verify that no-one has hijacked the IP address. I don't
know why you keep bringing it up.

Note that these issues are not specific to SMTP: XMPP has similar
difficulties with s2s authentication.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole, Lundy, Fastnet: Mainly northeasterly 4 or 5, occasionally 6 in Sole.
Slight or moderate, occasionally rough in Sole and Fastnet. Mainly fair.
Moderate or good.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Alex Bligh <[email-masked]>
Date: Thu, 03 Mar 2011 21:31:23 +0000

--On 3 March 2011 19:39:26 +0000 Tony Finch <[email-masked]> wrote:

> to reach.

What does "can act for" mean? Any smarthost "can act for" (in the
sense of can deliver mail to" any given domain, but it may require
information for the server to determine whether it "can act" at the
time of TLS (e.g. it might require authentication).

I had thought the purpose of SMTP on TLS was to verify that the
server was the server it claimed to be in the HELO line. Whether
the sending server uses that as a decision point as to whether
to send email on it is pretty much up to the sending server.

>From RFC3207
>    The decision of whether or not to believe the authenticity of the
>    other party in a TLS negotiation is a local matter.  However, some
>    general rules for the decisions are:
>
>    -  A SMTP client would probably only want to authenticate an SMTP
>       server whose server certificate has a domain name that is the
>       domain name that the client thought it was connecting to.
>    -  A publicly-referenced  SMTP server would probably want to accept
>       any verifiable certificate from an SMTP client, and would possibly
>       want to put distinguishing information about the certificate in
>       the Received header of messages that were relayed or submitted
>       from the client.

This is a similar degree of usefulness/uselessness to HTTP certs,
which in the vast majority of cases (DN validated) simply tell you
that the server you are visiting has a certificate purchased
by someone who could receive mail at that domain or administer
the zone. And before we get on our high horses about the usefulness
or otherwise of other cert systems, that's not too much different
from DNSSEC.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Mar 2011 08:31:45 +1100

In message <[email-masked]>, Tony F
> know why you keep bringing it up.

BECAUSE YOU CAN'T SECURE INTER SITE SMTP WITH OUT BOTH SECURING THE
MX/A/AAAA LOOKUPS *AND* THE TCP CONNECTION THE SMTP TRANSACTION
GOES OVER.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Mar 2011 10:32:35 +1100

> >       domain name that the client thought it was connecting to.

Which is learnt from the MX record (real or synthesised from the A/AAA
records) or manually configured in the case of a smart relay.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 04 Mar 2011 10:02:45 +0900

Tony Finch wrote:

> mail domains it hosts.

> that requires protocol development.

Just say "another level of indirection" or another CNAME.

By making CNAME domain names pointed by MXes different for each
mail domain name, and letting SMTP think servers with different
CNAME domain names are different servers even if they are
aliases of a single server, TLS should work with MX.

	mail0.example.com	MX 0 mail0.example.net
	mail1.example.com	MX 0 mail1.example.net
	mail0.example.net	CNAME mx.example.net
	mail1.example.net	CNAME mx.example.net

It's like differentiating name based virtual servers by different
CNAMEs pointed from different SVRs, as I pointed out a few weeks
ago.

A problem is that RFC1034 has a wrong example for reasoning
against recursive aliasing. But, it should be fixed. I'll post
an errata with a separate subject.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 04 Mar 2011 12:15:30 +0900

While RFC1034 says:

   Domain names in RRs which point at another name should
   always point at the primary name and not the alias.
   This avoids extra indirections in accessing information.
   For example, the address to name RR for the above host
   should be:

       52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

   rather than pointing at USC-ISIC.ARPA.  Of course, by
   the robustness principle, domain software should not
   fail when presented with CNAME chains or loops; CNAME
   chains should be followed and CNAME loops signalled as
   an error.

"avoids extra indirections" is not a strong requirement
and virtually allowed with the wording of while "CNAME
loops signalled as an error" is a strong requirement.

Thus, while CNAME (and BNAME) chains should be discouraged,
it should be explicitly allowed to use CNAME as a target of
PTR, MX, SVR and so on which does not cause recursion loops,
which is useful for name based differentiation of a service
on a single host.

CNAME as a target of NS should also be discouraged, because
it may cause recursion loop to be resolved by glue, which
requires unnecessarily complex operations.

					Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Mar 2011 16:08:09 +1100

> requires unnecessarily complex operations.
 
CNAME as the target of a NS does not work reliably.  To make it
work reliably you would have to change the additional processing
rules in every deployed nameserver.  You would also have to change
glue to include CNAME records.

Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 4 Mar 2011 10:15:55 +0100

On Thu, Mar 03, 2011 at 11:18:33AM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 37 lines which said:

> There is no specification for how to validate the TLS certificate
> for an MX server, and it is not obvious what such a specification
> should say.

RFC 3207, section 4.1 ?

Also, in the RFC editor queue:

http://www.rfc-editor.org/queue.html#draft-saintandre-tls-server-id-check

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Mar 2011 07:03:49 -0500

No hat.

> which is useful for name based differentiation of a service

I'm not sure I fully agree (or don't -- I just don't know) with your
reasoning, but even if I did I don't believe we could handle this as
an erratum.  Too many implementations have depended on the "no CNAME
target" rule to write off all that history as collective misreading of
the spec.

A

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

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 4 Mar 2011 12:37:01 +0000

> MX/A/AAAA LOOKUPS *AND* THE TCP CONNECTION THE SMTP TRANSACTION

	Did you really need to shout, Mark?

	By the way, I appreciate the courtesy of a personal reply
	(from quite a few posters, not just MarkA), but would appreciate
	it even more if I received only the list copy.

	Thanks all round

	Niall

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 04 Mar 2011 22:53:59 +0900

Andrew Sullivan wrote:

> Too many implementations have depended on the "no CNAME
> target" rule

For example?

						Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 4 Mar 2011 09:45:02 -0500

> For example?

I've been led to believe, at least, that there are mail servers that
are grouchy about this.  Certainly, I know mail implementers who are
grouchy about it.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 04 Mar 2011 15:27:59 +0000

> Date: Fri, 4 Mar 2011 07:03:49 -0500
> From: Andrew Sullivan <[email-masked]>
> 
> ... I don't believe we could handle this as an erratum.  Too many
> implementations have depended on the "no CNAME target" rule to write
> off all that history as collective misreading of the spec.

+1.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 05 Mar 2011 07:21:32 +0900

Andrew Sullivan wrote:

> are grouchy about this.

For example?

> Certainly, I know mail implementers who are
> grouchy about it.

It means that they are grouchy because they must support it,
as RFC 1034 requires so.

The issue is classified merely as a minor issue even at the
time when RFC974 was written (mail routing was a lot more
complex than today):

   Note that the algorithm to delete irrelevant RRs breaks if LOCAL has
   a alias and the alias is listed in the MX records for REMOTE.  (E.g.
   REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL).  This
   can be avoided if aliases are never used in the data section of MX
   RRs.

> requirements that existed in the 1980s were relaxed in the 1990s and no

So, my question is:

	Where is an example for your statement?

						Masataka Ohta

---

From: Brian Dickson <[email-masked]>
Date: Sat, 5 Mar 2011 14:41:29 -0400

> glue to include CNAME records.

Given that there are things that you (can't, or) shouldn't use CNAMEs for...

Let's flip the (implied) question around, then.

Are there things that either *require*, or can *only* be done with, CNAMEs?

I'll give an example of replacing CNAMEs with something else, and we
can use that as a kind of straw man, for these purposes.

(Caveat - yes, I know there are DNSSEC implications to the following.
Let's set aside DNSSEC for now, and address those issues a bit later.)

(BTW - this is from
http://tools.ietf.org/html/draft-dickson-dnsext-ds2-01 appendix A.2.1)

Instead of having a CNAME:

alias.example.com   CNAME  real.example.com.
real.example.com    TXT "This is real data, maintained in a single location."

have a *zone cut* (on both the "CNAME"-wannabe, and on the would-be
CNAME target) with all the RR's  which would have been found at the
target owner name, in the new zone's apex:

alias.example.com NS ns1.example.com
(on ns1.example.com) named.conf (with implicit $ORIGIN of zone.name):
       zone alias.example.com { master; file="czone-data.example.com";};
       zone real.example.com { master; file="czone-data.example.com";};

    file czone-data.example.com:

@         SOA ns1.example.com. postmaster ( 42 7200 600 3600000 60 )
             NS ns1.example.com
             TXT "This is real data, maintained in a single location."

NB - the exact same mechanism, logic, and format, happens to work for
DNAME, so the result is this allows for unified replacement of both
CNAME and DNAME with this, and thus implicitly pre-emptively replaces
BNAME (!!).

There are some real benefits to using this over CNAME.
CNAME targets are not necessarily aware that they *are* CNAME targets,
and there's no easy way to determine that something is a CNAME target.
On the other hand, both the parent and child side of a zone cut are
aware of the zone cut, and both sides have mechanisms for validating
state (lame delegation checks, and zone loading validation logic for
both loading and pre-load checking).
This becomes more important, the more aliases get added (esp. for the
ongoing aliases requirements) and/or the more aliases point to a
single target (e.g. web hosting).

Is there anything in the above, that would prevent the use of
"alias.example.com" as RDATA in any RR type?

(While it would be ambitious to do so, I think maybe it is time to put
an effort into depracating both CNAME and DNAME...)
Would this alternative to CNAME/DNAME make good material for a
proposed BCP? (BCP -- better common practice, in this case)?

Brian

---

From: John Levine <[email-masked]>
Date: 5 Mar 2011 19:20:25 -0000

>have a *zone cut*

You don't have to do anything that complicated.  Just copy the records
from the target to the address of the CNAME.

>       zone real.example.com { master; file="czone-data.example.com";};

And keep in mind that not every DNS server uses BIND format control
statements or zone files.

In any event, this is not a new idea.  We all know that in principle,
anything you can do with B/C/DNAME you could do with sufficiently
disciplined server management.

This confirms my impression that if we're going to do any of this
stuff, it's only useful as part of a system where applications can use
the info in the DNS to auto-provision and make names equivalent at the
application level.

R's,
John

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 06 Mar 2011 09:29:09 +0900

> Are there things that either *require*, or can *only* be

Aliasing.

> have a *zone cut* (on both the "CNAME"-wannabe, and on the would-be

Often, administrators of a canonical name and an alias are
different.

When a user of name based virtual hosting rent hosting and DNS
service from different providers, neither the user nor the DNS
service provider can know when updates occur on the canonical
name.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 06 Mar 2011 10:17:16 +0900

> the info in the DNS to auto-provision and make names equivalent at the

It depends.

If you are selling domain names and sell several or millions
of equivalent domain names at a price of a single ASCII
domain name, you don't want your customer resell the domain
names for many others.

If you charge for each name, let the customers bother.

						Masataka Ohta

---

From: John Levine <[email-masked]>
Date: 6 Mar 2011 01:35:16 -0000

>If you are selling domain names and sell several or millions of
>equivalent domain names at a price of a single ASCII domain name, you
>don't want your customer resell the domain names for many others.

That really, really does not strike me as a problem that we should
try to address with a technical solution.

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Sat, 5 Mar 2011 21:56:33 -0400

> service provider can know when updates occur on the canonical

Actually, it makes *more* sense (using zone cuts) in this case.

The user has the DNS service provider configured so that the
particular FQDN is delegated to the hosting providers' DNS server.
(Here, FQDN is the host name by which the virtual hosting for the user
is configured, like www.user.example.com.)
It is just the single name that is delegated, not the whole domain
that the user "owns".

The hosting provider then configures all their virtual hosting as
needed, and feeds the information on which physical hosts match which
FQDNs to their DNS provisioning engine.
Each virtual host FQDN includes the zone file for the corresponding
physical host, and voila, it just works.

Updates to the mappings (virtual->physical) can be managed without
requiring the user, or the users' DNS provider, to make any changes.
Those changes happen below the corresponding zone cut, on the hosting
provider's DNS infrastructure.

The hosting provider already has all this information, and already has
to maintain the mapping.
All that changes is the particular way that gets published in DNS -
CNAME vs delegated zones.

Brian

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 06 Mar 2011 11:14:25 +0900

> try to address with a technical solution.

The problem is that we provide a technical solution for users
of ASCII domain names purchase millions of equivalent domain
names:

	YYYYYYYYYYYYYYYYYYYYYYY.com
        .
        .
        .
        yyyyyyyyyyyyyyyyyyyyyyy.com

at a price of a single ASCII domain name.

Then, how can you say that users can't enjoy the same thing
with a domain name containing 'y' with diaeresis, upper
case of which is 'Y' *without* diaeresis, or Greek
characters?

The simplest and, perhaps, the fairest solution is to stick
to pure ASCII.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 06 Mar 2011 11:30:41 +0900

> particular FQDN is delegated to the hosting providers' DNS server.

That's too complex not acceptable for users nor the
DNS/hosting providers.

For example, DNS service provider my wife is using (Yahoo
Japan, a major provider in Japan) allow *advanced* users
set up A, CNAME and MX but nothing else.

						Masataka Ohta