Re: SNI vs Host: and a trailing dot

I don't know if there is a good solution to this.

Maybe browsers should always resolve the difference before submitting to 
a proxy or server so that the server or proxy doesn't need to 
second-guess the client.

We had a version of WinGate that had dots on the end of all 
fully-qualified names.  In an HTTP proxy usually the vast majority of 
names are fully qualified, BUT the vast majority of anchors in web pages 
do not have a dot.

I personally would like to see the end of dot-terminated names in http.

Maybe it would be better to treat any name with more than 1 token to be 
fully qualified, and thereby force people to be reasonable about how 
they name their local servers.

Otherwise we risk breaking a lot of stuff to "fix" some minor edge 
cases.




------ Original Message ------
From: "Amos Jeffries" <squid3@treenet.co.nz>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 17/03/2016 2:20:12 a.m.
Subject: Re: SNI vs Host: and a trailing dot

>On 17/03/2016 2:02 a.m., Willy Tarreau wrote:
>>  Hi guys,
>>
>>  On Thu, Mar 17, 2016 at 01:44:24AM +1300, Amos Jeffries wrote:
>>>  On 17/03/2016 1:09 a.m., Michael Sweet wrote:
>>>>  FWIW, CUPS has traditionally stripped the trailing dot from both 
>>>>since most printers (and web sites, for that matter) have difficulty 
>>>>handling "example.com."
>>>>
>>>
>>>
>>>  FWIW; Squid likewise does that as well.
>>>
>>>  IIRC we determined that the trailing dot syntax was an outcome of 
>>>people
>>>  partially understanding the DNS specifications. Those DNS specs talk
>>>  about using the trailing dot to terminate the domain labels. But on
>>>  close inspection it is only supposed to be used in the wire-format 
>>>for
>>>  DNS packets. Intermediate representations like HTTP messages or TLS 
>>>SNI
>>>  are expected to have no trailing dot for valid FQDN.
>>
>>  Not exactly because you have the problem when you need to 
>>differenciate
>>  host names that belong to your local domain and other ones. For 
>>example
>>  you could have a host called "www.example.com" on your local domain, 
>>and
>>  if you want to be sure to use the public www.example.com and not
>>  www.example.com.my.local.domain, the only way is to add the trailing 
>>dot.
>>
>
>Currently .local exists to resolve the problem.
>
>Previously to that the resolv.conf ndots and domain/search features 
>were
>the way to do it.
>
>And previously (sort of in parallel as well) there was the DNS 
>specified
>recommendation/algorithm for ordering a local query before global query
>(or was it vice versa?). That got applied for each of the resolv.conf
>lookups. Which you seem to be describing below;
>
>
>>  I remember having been in this exact situation many years ago by 
>>which
>>  I couldn't connect to my default gateway's web interface until I 
>>realized
>>  that the name "gw" that I was using on my local network was first 
>>resolved
>>  as "gw.work.local" which was my company's groupware server and it 
>>couldn't
>>  be accessed from where I was located (hence my belief that the device 
>>did
>>  not respond). Simply passing "http://gw./" solved the issue for me.
>>
>>  However I have no idea where in the chain this dot needs to be 
>>trimmed,
>>  but it definitely has a use case for the end user and in HTTP URIs 
>>(though
>>  not frequent).
>
>
>IIRC; the DNS specs said tolerant software could expect it occasionally
>in users input and should trim. Which effectively means during input
>validation for any software, via any input means.
>
>
>Cheers
>Amos
>
>

Received on Wednesday, 16 March 2016 23:29:38 UTC