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