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

Mon Feb 25 22:07:24 UTC 2013

In message <15455394.7034.1361803759023.JavaMail.root at benjamin.baylink.com>, Ja
y Ashworth writes:
> ----- Original Message -----
> > From: "Brian Reichert" <reichert at numachi.com>
> 
> > On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote:
> [I believe this is Brian, then Mark: ]
> > > > When I did my initial development with OpenSSL, I observed:
> > > >
> > > > - If I did not have the rooted domain name in the SAN, then any SSL
> > > >   client stack would fail the verification if a rooted domain name
> > > >   was used to connect to the SSL server.
> > >
> > > Well you have a broken SSL client app. If it is accepting non legal
> > > hostnames it should be normalising them before passing them to the
> > > ssl layer.
> > 
> > From what little research I've done (only OpenSSL), the SSL client
> > is relying on getaddrinfo(3) to do name resolution. In turn, I
> > haven't found an implementation of getaddrinfo(3) that rejects
> > rooted domain names as non-legal.

And getaddrinfo() returns the canonical name (ai_canonname) which
is the name found after searching, if any, and CNAMEs (DNAME) have
been followed.  It doesn't have a period at the end unless there
is a implementation bug.

     struct addrinfo {
             int ai_flags;           /* input flags */
             int ai_family;          /* protocol family for socket */
             int ai_socktype;        /* socket type */
             int ai_protocol;        /* protocol for socket */
             socklen_t ai_addrlen;   /* length of socket-address */
             struct sockaddr *ai_addr; /* socket-address for socket */
             char *ai_canonname;     /* canonical name for service location */
             struct addrinfo *ai_next; /* pointer to next in list */
     };

Now http{s} clients and server administrators have misused CNAME
for years so ai_canonname is not as useful as it should be.
ai_canonname should match the expected name in the presented CERT.
As a result the http{s} client needs to do the normalisation including
search list processing.  Yes there are lots of broken clients.

> Yes, but that's not the question, Brian, assuming I understand the problem
> as well as I think I do.  The question is not how the client does the
> name resolution on the client machine -- it's what it does with the domain
> 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.
> 
> === 
> 
> More formally: "is a host/domain name with a trailing dot *actually a 
> legal host name?

No.  See RFC 952

> Or is that merely local shorthand notation for resolvers
> and DNS server zone files, to define absoluteness.  In short: are domain
> names on-the-wire *always* to be interpreted as absolute even in the 
> absence of a trailing dot."
> 
> My personal opinion, based on about 2 decades of watching from the outside,
> and of systems analysis and application design in non-internet contexts,
> is to say that yes, they must; there is *in fact* no reason for a relative
> domain name to leave a machine, since the context for it's relativity is
> dependent on the resolv.conf on that machine for lookups, and on which
> zone file it's in for service...
> 
> and that the implication of that is that any application/library which
> takes a text-string host/domain name handed to it from off-machine ought
> to normalize away any trailing dot.
> 
> I invite counter-arguments and -citations.  :-)
> 
> Cheers,
> -- jr 'yeah, I know, it's Monday' a
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.co
> m
> Designer                     The Things I Think                       RFC 210
> 0
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DI
> I
> St Petersburg FL USA               #natog                      +1 727 647 127
> 4
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org