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

[Alex Bligh <[e-mail]>]

--On 1 March 2011 10:25:45 +0000 Niall O'Reilly <[e-mail]> 
wrote:

> 	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.

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.

-- 
Alex Bligh