Should host/domain names travel over the internet with a trailing dot?
Mark Andrews
marka at isc.org
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
More information about the NANOG
mailing list