In message <32423329.7280.1361833741738.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
----- Original Message -----
From: "Mark Andrews" <marka@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: marka@isc.org