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

[Alex Bligh <[e-mail]>]

--On 1 March 2011 00:37:39 +0000 Niall O'Reilly <[e-mail]> 
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