How about "stopdot"? Seems to cover the function and the form.
---rsk
I agree on what that spec says. My concern that that a rooted
domain name is (will be?) valid in practice, and is supported by
client software seemingly everywhere.
The spec for a URL also calls out what constitutes a hostname, and
I've yet to see a HTTP client that trips over a rooted domain name.
(Yes, I'm aware an alternate bit of terminology has been proposed,
but I'm trying to be consistent for the duration of this thread.)
Still, I'm not arguing about what should be allowed; I'm trying to
come up with the words to explain to end-users.
Well, the followup question is: are absolute host names "real", or /solely/ hint to the local resolver not to search-list?
I will reread 1035 later tonight ...
Well, RFC 3986 (URI) explicitly allows the final dot. See the section
on reg-name in section 3.2.2. Sometimes this RFC is used as one of
the example sowers-of-confusion, because despite the fact that the
relevant section is talking about DNS domain names, the name of the
segment of the URI is called "host", and hostnames don't have a
trailing dot.
It's no wonder people who merely have to implement this stuff are
confused, when the stnadards development organization in question
can't figure out how the terminology works!
A
Yrs, but he wanted the retronym for domain names not containing one, not the dot.
Absolute and relative domain names, as Joe and 1035 said.
RFC 952 as modified by RFC 1123 describe the legal syntax of a hostname.
There is no trailing period.
A hostname is not a domain name, the hostname is just a label, and
has stricter syntax than is allowed in a DNS label; however: When
hostnames are represented in DNS, they have corresponding domain
names. eg for A.example.com
The domain name is unqualified if it contains just the hostname "A".
It is partially qualified, if a subset of the labels are provided "A.example"
The names are called fully qualified, when the domain name shown is
the complete DNS name, with all labels; "A.example.com"
In the DNS, the implicit trailing dot is understood to be part of the
domain name.
Technically "A.example.com" without a trailing dot is unqualified,
for purposes of DNS resolution; if a DNS resolver receives NXDOMAIN
for A.example.com; some resolvers will normally search for
A.example.com.suffix next
However, it is nevertheless commonly referred to as fully-qualified,
with or without the trailing dot, even though syntactically it could
be unqualified; because ".COM" is such a well-known TLD .
In this case, it doesn't actually matter what the RFCs call a FQDN;
it's overridden by common usage of the phrase/acronym (It is
commonly understood that no trailing dot is required, except in the
context of a zone file).
There is little understanding about qualification of hostnames, and
DNS resolver search, and these concepts should probably just go away
/ be simplified, so all valid lookup names are FQDNs or local
hostnames with no dots.
A domain name without a terminal dot is a relative domain name.
-- An application requesting name to address translation gets to decide if a search list is to be used, including the default of dot.
A domain name with a terminal dot is a Fully Qualified Domain Name.
-- An application requesting name to address translation must submit the name as received to the lookup process.
These definitions have been effective of decades and do not need additional terminology.
-- Faulty implementations are not an excuse for ever more complex terminology.
As a side note, a hostname is usually a domain name. A domain name is never necessarily a hostname. For example, the hostname command on my mini returns "minijim", while the domain name used to reach my mini locally is "minijim.local", but that is not my mini's hostname. But my mini's name to address lookup mechanism uses protocols other than DNS to figure that out. But, new terminology for hostnames or domain names was never required.
James R. Cutler
james.cutler@consultant.com
The authoritative document here is, as Joe Abley noted earlier, RFC 1035,
which says, in section 5.1:
"""
Domain names that end in a dot are called absolute, and are taken as
complete. Domain names which do not end in a dot are called relative;
the actual domain name is the concatenation of the relative part with
an origin specified in a $ORIGIN, $INCLUDE, or as an argument to the
master file loading routine. A relative name is an error when no
origin is available.
"""
Or, in more Jewish terms: not so much.
And in fact, I don't believe that you *have* a manual API-level choice
as an application as to whether your resolver library will apply a
search list or not: if you specify an absolute name, it won't; if you
specify a relative name, it will.
Nope: gethostbyname(3) only takes one argument: char *hostname
So the only control you have as app is whether you include the trailing
dot.
(PS: your quoting (or bulleting) protocol is non-standard and non-intuitive)
Cheers,
-- jra
RFC103 5.1 is correct in the context of a DNS zonefile.
In other contexts, however, a domain is absolute without a trailing dot.
One example, would be in the case of the SMTP protocol, where
hostnames are required to _always_ be absolute.
In various common contexts, a domain is always either fully
qualified, or not valid.
Sometimes a trailing dot is allowed, and in some protocols, a
trailing dot is not allowed; however the domain used is still called
a FQDN; it's just different syntax, for a fqdn, with minor
variations..
A trailing dot is not included in the domain portion of an e-mail
address, however within the context of nobody@example.com;
example.com is understood to be a fully qualified domain.
Nothing else really makes sense; "example.com" is absolute and not
relative in this context..
It is also true in the context of a http URL scheme http://www.example.com/
In that context, the www.example.com is a fully qualified domain;
although some browsers
might try appending other suffixes, as an aid to the user, if the
domain cannot be found.
No trailing dot allowed; "each domain label starting and ending with
an alphanumerical character";
The URL is the most common context where a fully qualified domain
would be encountered, e-mail addresses and URLs are the most
common case where the average network user will encounter a domain
name.
For the sake of consistency, if something is considered a FQDN in a
URL and in a SMTP hostname or e-mail address, then it ought to be
made to be considered a fully qualified domain, everywhere.
"
Berners-Lee, Masinter & McCahill [Page 5]
RFC 1738 Uniform Resource Locators (URL) December 1994
host
The fully qualified domain name of a network host, or its IP
address as a set of four decimal digit groups separated by
".". Fully qualified domain names take the form as described
in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
[5]: a sequence of domain labels separated by ".", each domain
label starting and ending with an alphanumerical character and
possibly also containing "-" characters. The rightmost domain
label will never start with a digit, though, which
syntactically distinguishes all domain names from the IP
addresses.
"
From: "Jimmy Hess" <mysidia@gmail.com>
RFC103 5.1 is correct in the context of a DNS zonefile.
In other contexts, however, a domain is absolute without a trailing
dot.
If that can be nailed down authoritatively, then it will answer my
followup questions, and at least locate the problem the OP was having
(that is, it will still work improperly, but at least we'll be able to
blame the app vendors with a straight face).
Sometimes a trailing dot is allowed, and in some protocols, a
trailing dot is not allowed; however the domain used is still called
a FQDN; it's just different syntax, for a fqdn, with minor
variations..
You're backing, effectively, my assertion that the only place you can
*use* a relative domain name *is as input to a local resolver*, I think.
or maybe not.
A trailing dot is not included in the domain portion of an e-mail
address, however within the context of nobody@example.com;
example.com is understood to be a fully qualified domain.
I think 5322 actually says so, no?
Nothing else really makes sense; "example.com" is absolute and not
relative in this context..It is also true in the context of a http URL scheme
http://www.example.com/In that context, the www.example.com is a fully qualified domain;
although some browsers
might try appending other suffixes, as an aid to the user, if the
domain cannot be found.No trailing dot allowed; "each domain label starting and ending with
an alphanumerical character";
The OP asserts that a) if he puts an absolute domain name into a URL
then that will be what the webserver at the other end gets as the
http/1.1 URL (I believe that's the implication of what he's saying,
anyway), and b) if his webserver receives the URL with the trailing
dot *it will try to look it up in the SSL cert that way*.
No, I must have misunderstood him; as I'm painfully aware, that URL
doesn't move until you have the SSL link running. Pants.
The URL is the most common context where a fully qualified domain
would be encountered, e-mail addresses and URLs are the most
common case where the average network user will encounter a domain
name.
The issue isn't FQDN vs non-FQDN; it's FQDN represented as an absolute
domain name with trailing dot vs FQDN represented as a relative domain
without such a dot, but *still* a "rooted" FQDN.
For the sake of consistency, if something is considered a FQDN in a
URL and in a SMTP hostname or e-mail address, then it ought to be
made to be considered a fully qualified domain, everywhere.
Don't tell people for whom
is a valid and common URL that. 
"
Berners-Lee, Masinter & McCahill [Page 5]
RFC 1738 Uniform Resource Locators (URL) December 1994host
The fully qualified domain name of a network host, or its IP
address as a set of four decimal digit groups separated by
".". Fully qualified domain names take the form as described
in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
[5]: a sequence of domain labels separated by ".", each domain
label starting and ending with an alphanumerical character and
possibly also containing "-" characters. The rightmost domain
label will never start with a digit, though, which
syntactically distinguishes all domain names from the IP
addresses.
"
If I'm parsing that right, it means that my assertion was correct:
Browsers given an absolute domain name ought not to send the trailing
dot in the transactions of any type, and servers receiving it ought
to strip it.
Cheers,
-- jra
> My snap reaction is to say that nothing should ever be *trying* to
> compare a rooted F.Q.D.N. against a certificate; it is, as has been
> noted, merely command line/entry field shorthand to tell the local
> resolver where to quit; applications should all be stripping that
> trailing dot.
>
> Do you have evidence that the extra AltName with the trailing dot
> is operationally necessary?'Necessary' is what's hard to ascertain here.
If, under a UNIX-like operating system, you request a PTR with some
command-line tool such as 'dig', you'll get a rooted domain name:
$ dig -x 8.8.8.8 +short
google-public-dns-a.google.com.
You used a tool that returns a entry from the DNS. That tool doesn't
do the reverse mapping into a hostname because it is a tool for querying
the DNS. If you want a tool that deals with hostnames use something that
wraps getnameinfo().
And you can use this rooted domain name get an A record:
$ dig a google-public-dns-a.google.com. +short
8.8.8.8
Again you are confusing domain names with host names.
As a matter of example, if you had automation that was internally
testing your network for trusted certificates, and generated a set
of hostnames based on reverse DNS, then your SSL client will now
be using rooted domain names.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.
So, should browsers send absolute host names in http/1.1 requests, and should
n't servers strip the trailing dot if they get one?I vote No and Yes, resp.
Yes. Note that doesn't mean with a trailing period. Browsers should also
disable searches when following urls not entered in the entry bar.
> From: "Cutler James R" <james.cutler@consultant.com>
> A domain name without a terminal dot is a relative domain name.
> -- An application requesting name to address translation gets to
> decide if a search list is to be used, including the default of dot.
>
> A domain name with a terminal dot is a Fully Qualified Domain Name.
> -- An application requesting name to address translation must submit
> the name as received to the lookup process.
>
> These definitions have been effective of decades and do not need
> additional terminology.
> -- Faulty implementations are not an excuse for ever more complex
> terminology.The authoritative document here is, as Joe Abley noted earlier, RFC 1035,
which says, in section 5.1:"""
Domain names that end in a dot are called absolute, and are taken as
complete. Domain names which do not end in a dot are called relative;
the actual domain name is the concatenation of the relative part with
an origin specified in a $ORIGIN, $INCLUDE, or as an argument to the
master file loading routine. A relative name is an error when no
origin is available.
"""
Which applies to domain names in master files.
Or, in more Jewish terms: not so much.
And in fact, I don't believe that you *have* a manual API-level choice
as an application as to whether your resolver library will apply a
search list or not: if you specify an absolute name, it won't; if you
specify a relative name, it will.Nope: gethostbyname(3) only takes one argument: char *hostname
So the only control you have as app is whether you include the trailing
dot.
On most platforms it isn't the only control. Not gethostname predates
search lists and even heirachical domain named.
For what it is worth I argued for removal of support for partially
qualified domain names when looking at resolving the issues in RFC
1535. "ndots" was the compromise.
I also argued for searches stopping on nodata responses.
I felt and continue to feel both of these are security issues. If
RFC 1535 came up today I believe that different decisions may have
been made but give the political climate at the time that was the
best I could get.
> From: "Mark Andrews" <marka@isc.org>
> RFC 952 as modified by RFC 1123 describe the legal syntax of a
> hostname. There is no trailing period.May someone create a "com" subdomain in a DNS domain you have to work in,
Mark.
It wouldn't bother me. I use sane resolvers and don't use partially qualified
names.
Note, however, that the URI specification actually contemplates the
possibility of the host part being a dom-spec, and the names in that
are able to be terminated with a dot. Or at least that's how I read
it when I looked it up the other day.
A
We can call them "rooted" domain names and "pwned" domain names...
> 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.
Looking for couter-examples...
From: "Brian Reichert" <reichert@numachi.com>
[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.
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.