looking for terminology recommendations concerning non-rooted FQDNs

Mailman List Mirror (Read Only)
1

I'm trying to nail down some terminology for doc purposes.

The issue: most resources on the net freely describe a fully-qualified
domian name ('FQDN') as to exclude the root domain; i.e, they exclude
the trailing dot as mandated by some RFCs such as RFC 1535:

  http://www.ietf.org/rfc/rfc1535.txt

    An absolute "rooted" FQDN is of the format {name}{.} A non
    "rooted" domain name is of the format {name}

I'm trying to come up with some human-facing terminology that names
these two forms:

  "a.b.c."
  "a.b.c"

Many resources on the net use the term 'rooted domain name' for the
former, but they're collectively ambigious about what the other
form should be called.

Does anyone here have any solid advice, or can point me to a resource
that would call out useful conventions?

This was all fueled by Microsoft's client code apparently stripping
the root domain from PTR record results; I'm separately trying to
track down why that's occuring...

2

I'm trying to nail down some terminology for doc purposes.

The issue: most resources on the net freely describe a fully-qualified
domian name ('FQDN') as to exclude the root domain; i.e, they exclude
the trailing dot as mandated by some RFCs such as RFC 1535:

RFC 1535 is Informational. It has no status to mandate anything.

  http://www.ietf.org/rfc/rfc1535.txt

    An absolute "rooted" FQDN is of the format {name}{.} A non
    "rooted" domain name is of the format {name}

I'm trying to come up with some human-facing terminology that names
these two forms:

  "a.b.c."
  "a.b.c"

Many resources on the net use the term 'rooted domain name' for the
former, but they're collectively ambigious about what the other
form should be called.

Does anyone here have any solid advice, or can point me to a resource
that would call out useful conventions?

This was all fueled by Microsoft's client code apparently stripping
the root domain from PTR record results; I'm separately trying to
track down why that's occuring...

RFC 952 as modified by RFC 1123 describe the legal syntax of a hostname.
There is no trailing period.

3

No - but a trailing period is a (common?) way to indicate that the name
as given is complete, so in a lot of contexts a trailing period is at
least not illegal, and is often usefully meaningful.

The best example is inside zone files, where a trailing period indicates
that the origin should not be appended. It's used (by the resolver
library?) to indicate that any domain search suffixes should not be
attempted. In Firefox (and probably other browsers) it indicates that
the browser should not try common suffixes like ".com" if the hostname
provided does not resolve.

It's a convention common enough and useful enough that I can see why
people would want a handy term for it.

Regards, K.

4

May someone create a "com" subdomain in a DNS domain you have to work in,
Mark.

Or *course* the trailing dot matters, even if only due to the behavior
of DNS resolvers.

Cheers,
-- jra

5

It's a convention common enough and useful enough that I can see why
people would want a handy term for it.

The core issue I'm trying to resolve surrounds the generation of a
CSR. We're trying automate this process for a network appliance
my employer sells.

When our appliance generates a CSR for itself, among the steps is
to get a PTR record; by convention (or otherwise) these are rooted
domain names.

When we generate a CSR, we're choosing to include the rooted domain
name, as well as the other form (for now, I guess it should be
called a FQDN, the version without the trailing dot).

The resulting issued certificate has both forms in the SubjectAltName
field, and this allows both hostname forms to be used to establish
an SSL connection to our server. They are considered distinct for
the Subject verification phase.

It's come to my attention that some commercial certificate vendors
think that having multiple hostnames in the SAN list costs more
money; go figure. Our customers then have to go through some
soul-searching to pare down the list of hostnames in the SAN in the
CSR.

There's some understandable questions about why we include both
forms, and whether or not they are necessary.

We need to document our policies and recommendations, and I'm trying
to establish the vocabulary.

Hence my original question. Irrespective of the state of RFCs,
there are competing conventions, and ambiguous terminology. And I
was seeking guidance. :slight_smile:

I do appreciate the feedback provided thus far.

6

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?

Cheers,
-- jra

7

Mark is of course correct about this, but it doesn't fully help.

The basic problem is (as always) the confusion about the difference
between a hostname and a fully-qualified domain name, which so happens
to be also a hostname.

Whether we like it or not, this ambiguity is no longer something that
can be resolved. What you have to do is know whether you are dealing
with a hostname (no final dot, because the hostname syntax doesn't use
it), a domain name relative to the root (no final dot, because
implicitly you're not using the search path; it is nearly impossible
to tell the difference between this and a host name), a domain name
relative to something else, relying on your search path (bad, evil,
and wrong, just stop it or you get what you deserve), or an actually
fully-qualified domain name (final dot). The second of these is about
to get harder to distinguish from the third, because of the new gTLD
programme at ICANN.

I wish there were a neat answer to the problem. There isn't.

A

8

Actually, I think the problem is the confusion between a label string terminated in a dot (to indicate that no search domain should be appended) and a label string not so-terminated (which might mean that a search domain is attempted, depending on local configuration).

There is no simple terminology to distinguish between the two cases that I am aware of.

I think the original question's context was how to format a CN in a CSR. I believe the most useful answer is "single CN, fully-qualified domain name with no trailing dot".

The terminology "root zone" or "root domain" to explain the trailing dot is misleading and unhelpful, I find.

Joe

9

From: "Joe Abley" <jabley@hopcount.ca>

Actually, I think the problem is the confusion between a label string
terminated in a dot (to indicate that no search domain should be
appended) and a label string not so-terminated (which might mean that
a search domain is attempted, depending on local configuration).

In fact, Joe, I think it's distinguishing your second case from "a label
string which is intended to reference a rooted FQDN, but the user did not
specify the trailing dot -- and yet still does not want a search path
applied"...

which is 99.9999% of the time outside of large corporate and college
campuses, and only 99.9% of the time, otherwise. :slight_smile:

The terminology "root zone" or "root domain" to explain the trailing
dot is misleading and unhelpful, I find.

No, what's *really* unhelpful and misleading is the people who say that
it is the *dot* which specifies the name of the root, rather than the
null labelstring which *follows* that dot (which is what it actually
is, and I'll save everyone's stomach linings by not saying the words
"alternate root" here. :slight_smile:

Cheers,
-- jr 'new intercalations on every message for authentication' a

10

Jay,

Actually, I think the problem is the confusion between a label string
terminated in a dot (to indicate that no search domain should be
appended) and a label string not so-terminated (which might mean that
a search domain is attempted, depending on local configuration).

In fact, Joe, I think it's distinguishing your second case from "a label
string which is intended to reference a rooted FQDN, but the user did not
specify the trailing dot -- and yet still does not want a search path
applied"...

That's the same as my second case.

"rooted FQDN" is also not well-defined outside this thread. I don't think just adopting the terminology unilaterally is going to make it so.

The terminology "root zone" or "root domain" to explain the trailing
dot is misleading and unhelpful, I find.

No, what's *really* unhelpful and misleading is the people who say that
it is the *dot* which specifies the name of the root,

The dot doesn't specify the name of the root. That's why it's confusing.

rather than the
null labelstring which *follows* that dot (which is what it actually
is, and I'll save everyone's stomach linings by not saying the words
"alternate root" here. :slight_smile:

There is no null label string following the dot in a fully-qualified domain name, in this context. You're confusing the presentation of domain names with wire-format encoding of domain names.

Joe

11

From: "Joe Abley" <jabley@hopcount.ca>

> In fact, Joe, I think it's distinguishing your second case from "a label
> string which is intended to reference a rooted FQDN, but the user did not
> specify the trailing dot -- and yet still does not want a search path
> applied"...

That's the same as my second case.

"rooted FQDN" is also not well-defined outside this thread. I don't
think just adopting the terminology unilaterally is going to make it
so.

It isn't?

I knew what he meant immediately, without having to read the rest of
the sentence: an ascii represenation of a fully qualified hostname
with a period at the end.

>> The terminology "root zone" or "root domain" to explain the trailing
>> dot is misleading and unhelpful, I find.
>
> No, what's *really* unhelpful and misleading is the people who say
> that it is the *dot* which specifies the name of the root,

The dot doesn't specify the name of the root. That's why it's
confusing.

Oh: we're in violent agreement. :slight_smile:

> rather than the
> null labelstring which *follows* that dot (which is what it actually
> is, and I'll save everyone's stomach linings by not saying the words
> "alternate root" here. :slight_smile:

There is no null label string following the dot in a fully-qualified
domain name, in this context. You're confusing the presentation of
domain names with wire-format encoding of domain names.

Well, alas, I think you have to unpack that last sentence at least one
more layer for me to be sure what I'm agreeing or disagreeing with...

but since the dot is a separator (I believe by definition), if it exists
at the end, it has to be separating *something*.

Cheers,
-- jra

12

In fact, Joe, I think it's distinguishing your second case from "a label
string which is intended to reference a rooted FQDN, but the user did not
specify the trailing dot -- and yet still does not want a search path
applied"...

That's the same as my second case.

"rooted FQDN" is also not well-defined outside this thread. I don't
think just adopting the terminology unilaterally is going to make it
so.

It isn't?

Nope.

I knew what he meant immediately, without having to read the rest of
the sentence: an ascii represenation of a fully qualified hostname
with a period at the end.

I could have guessed the same thing, but the phrase is not in common use, and hence I think "not well-defined" is the right description.

but since the dot is a separator (I believe by definition), if it exists
at the end, it has to be separating *something*.

I had a quick look, and RFC 1035 agrees with you, so I guess I have to eat my words :slight_smile:

  When a user needs to type a domain name, the length of each label is
  omitted and the labels are separated by dots ("."). Since a complete
  domain name ends with the root label, this leads to a printed form which
  ends in a dot. We use this property to distinguish between:

     - a character string which represents a complete domain name
       (often called "absolute"). For example, "poneria.ISI.EDU."

     - a character string that represents the starting labels of a
       domain name which is incomplete, and should be completed by
       local software using knowledge of the local domain (often
       called "relative"). For example, "poneria" used in the
       ISI.EDU domain.

  Relative names are either taken relative to a well known origin, or to a
  list of domains used as a search list. Relative names appear mostly at
  the user interface, where their interpretation varies from
  implementation to implementation, and in master files, where they are
  relative to a single origin domain name. The most common interpretation
  uses the root "." as either the single origin or as one of the members
  of the search list, so a multi-label relative name is often one where
  the trailing dot has been omitted to save typing.

So I guess we have a winner, according to the spec: "absolute domain name". I don't believe that's in common usage either, but at least it is referenced in the specification.

Joe

13

Without getting into metaphysics, we can think of the dot in the
presentation format as representing the separators in the wire
format. In the wire format, of course, these separators are octets
that indicate the size of the next label. And since the final label
is null, the separator indicates a zero length in the wire format.
Therefore, in the presentation format, the final separator is
indicative of the (null) root label after.

But if we want to skirt metaphysics, the problem here is the status of
the presentation vs. wire format. If these are two perfectly co-equal
forms of representation, then we have a funny problem, since in the
global DNS the wire format is _never_ a relative lookup (the search
path gets appended before lookup). If on the other hand the
presentation format is merely one for human consumption, and the wire
format is canonical, then there's just a representational problem.

This of course doesn't actually help with the original question, which
is how to refer to all these things unambiguously. I have no idea how
to solve that: the different terms have an established use, and fixing
ambiguities in established use is a problem far beyond the bounds of
networking.

A

14

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.

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

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.

- I could generate a CSR with both formats of hostnames.

- My OpenSSL-based CA (and our internal MS-based CA) would sign
  said certificate request, preserving all of the hostnames in the SAN.

- and now using a roted domain name was successful.

And I figured, if both OpenSSL and Microsoft's Certificate Services,
(and their respective SSL clients) behaved the same way, I just
coded my automated generation of the CSR to include the rooted
domain names, just to cover my bases.

I did not expect that misc commercial entities would punish people
under these circumstances...

Now, I expect in this specific customer's case, I'm reasonably
certain that they won't have a tool chain / work flow / whatever,
that would introduce a rooted domain name.

But, I don't know if I can guarantee that for all of our current
and future clients. I don't know if the practices suggested by RFC
1535 will come into effect, but I wanted to future-proof our product
in this regard...

15

just keep in mind that while "." ought to be a label separator, the
utc's bidi algorithm allows the directionality of a label to "leak"
across the "period" character, where it is not a terminal character.

hilarity ensues.

16

In short, "yes, Jay, I do". Got it. :slight_smile:

You saw Joe's second reply?

17

In short, "yes, Jay, I do". Got it. :slight_smile:

:slight_smile:

You saw Joe's second reply?

Apparently, I lost track of that while writing this up. :slight_smile:

18

Yes, this is true, although that's at yet another layer _above_ the
DNS presentation layer. That is, the . we are talking about is in the
DNS presentation layer, which ought only ever to contain A-labels
(xn--somethinghere) and not U-labels. (Someone suggested to me that
the motto for IDNA ought to be, "Insufficient complication can always
be solved by another layer of misdirection.")

A

19

So, should browsers send absolute host names in http/1.1 requests, and shouldn't servers strip the trailing dot if they get one?

I vote No and Yes, resp.

20

The first question is tough, only because of the depth of the
exatblished convention. I think I would argue 'Yes', as to remove
ambiguity, but that naively makes a lot of legacy software trip in
unexpected ways.

As for the second question, I generally disapprove of throwing away
information, so I say No.

Clearly I like to make trouble for myself. :slight_smile: