Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Pro

> On 3 jan 2015, at 22:53, Mark Andrews <marka(_at_)isc(_dot_)org> wrote:
>
> I suspect in
> most cases there would be a single SRV record pointing to the hosting
> service.  There is only a single CNAME record pointing to the hosting
> service today.
Yes, except in the case for the bare domain name which there can not be any 
CNAME records for. For that you might have a "lame" A/AAAA record pair, which 
references an HTTP server that only gives back 301 to whatever URL you are to 
use -- where the CNAME exists.

I.e. I want to replace:

1 A lookup for domain
2 AAAA lookup for domain
3 Open HTTP connection to whatever target there was for A or AAAA lookup for 
domain
4 Get 301 back
5 A lookup for domain in the result of the 301
6 AAAA lookup for domain in the result of the 301
7 Get back CNAME from either 5 or 6
8 A lookup for domain in the result of the CNAME lookup
9 AAAA lookup for domain in the result of the CNAME lookup
10 Open HTTP connection to whatever target there was for A or AAAA lookup for 
domain

With:

1 URI lookup for domain
2 A lookup for domain in target for URI
3 AAAA lookup for domain in target for URI
4 Open HTTP connection to whatever target there was for A or AAAA lookup for 
domain

I.e. with the URI lookup you can resolve both the issue with lack of CNAME as 
zone apex and the initial 301 to whatever the apex of the web site is.

Or similar shortening of the number of roundtrips in DNS or HTTP with SRV (one 
can argue whether you get rid of the 301 with SRV, or the CNAME or both).

Today I see both 301 redirect and CNAME chain(s) when opening HTTP connections. 
Lots of them.

   Patrik

signature.asc
Description: Message signed with OpenPGP using GPGMail