W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: SNI vs Host: and a trailing dot

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 17 Mar 2016 02:20:12 +1300
To: ietf-http-wg@w3.org
Message-ID: <56E95D8C.9030108@treenet.co.nz>
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 13:20:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC