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.
>
> As I note here:
>
> > > Yes, but that's not the question, Brian, assuming I understand the proble
> m
> > > 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
>
> I think 952 is functionally obsolete, requireing a <24 char name length;
> I would have expected citations, perhaps, to 1535.
>
> Care to expand?
Ok. RFC 952 as modified by RFC 1123. This covers all legal hostnames
in use today including those that do not fit in the DNS. The DNS
supports hostnames up to 253 bytes (255 bytes in wire encoding).
RFC 1123 allow hostnames to go to 255 bytes. I'm deliberately
ignoring IDN's as they still need to map back into what is permitted
by RFC 952 as modified by RFC 1123.
RFC 1535 is NOT a STANDARD. Not all RFC are created equal.
> Cheers,
> -- jra
> --
> Jay R. Ashworth Baylink j...@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: ma...@isc.org
