In message <32423329.7280.1361833741738.javamail.r...@benjamin.baylink.com>, Ja
y Ashworth writes:
> ----- Original Message -----
> > From: "Mark Andrews" <ma...@isc.org>
>
> > > > 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.
>
> Sure, but both of those were red herrings, as we weren't at that point
> talking about DNS proper anymore, but on-machine interpretation of an
> imported SSL cert against a hostname generated on-machine.
getaddrinfo() is *independent* of the underlying name resolution
technology. The DNS, NIS, /etc/hosts LDAP all have the concepts
of canoical name and alias.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
