Should host/domain names travel over the internet with a trailing dot?

Jimmy Hess mysidia at gmail.com
Tue Feb 26 01:07:20 UTC 2013


On 2/25/13, Jay Ashworth <jra at baylink.com> wrote:
>> From: "Brian Reichert" <reichert at numachi.com>
[snip]
> name it's looking up before doing the SSL interaction with the server side,
> a process with which I'm not familiar enough to know if the client actually
> send the host/domain name to the server end.  Assuming it does -- and I
> am -- the question is: should it take the dot off.

By the time the hostname is sent over HTTP, the SSL connection is
already established, and all the SSL negotiation already happened..
it's up to the client to validate the server's FQDN  matches the CN of
the certificate, or an alternative DNS name;  which are all are
(hopefully) or ought to be, by definition FQDNs,   before  the server
knows what hostname(s)  HTTP requests will be made against.



If  the domain in a certificate were not interpreted as a FQDN by the
client,   this would mean,  that the certificate for
CN=bigbank.example.com
might be used to authenticate a connection to  https://bigbank.example.com
which do the local resolver search order, is in fact a DNS lookup of
bigbank.example.com.intranet.example.com

Which might be captured by a Wildcard A record for  *.com  found in
the   intranet.example.com.   zone  and pointed to a server
containing a phishing attack against bigbank.example.com;   with  a
DNS cache poisoned by  a false negative cache NXDOMAIN entry   for
bigbank.example.com.





The exeption to not sending the domain name before encryption, would
be the shiny new TLS protocol version with the server supporting the
rarely used SNI extension;  extension for server name indication,
that will one day allow virtual hosting for TLS protected HTTP
transport,  sharing one IP address,  with a different X509 certificate
served up by the server, based on which hostname has been requested
(once browsers and servers begin to support  TLS1.2 as a replacement
for SSL);    in this case,  the  crypto stack  on the server does gain
access to the hostname.

It probably doesn't matter if the server removes the "." or not,
before sending it.. the server has to allow the dot.


The  HTTP/1.1   does mention something about HTTP proxies possibly
being able to handle a hostname that is not a FQDN,  solely by
appending their own domain to the hostname;  appending a suffix to the
hostname is allowed,  in that specific case,  but a FQDN must not be
changed.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2
"
The use of IP addresses in URLs SHOULD be avoided whenever possible
(see RFC 1900 [24]). If the abs_path is not present in the URL, it
MUST be given as "/" when used as a Request-URI for a resource
(section 5.1.2). If a proxy receives a host name which is not a fully
qualified domain name, it MAY add its domain to the host name it
received. If a proxy receives a fully qualified domain name, the proxy
MUST NOT change the host name.
"

--
-JH




More information about the NANOG mailing list