looking for terminology recommendations concerning non-rooted FQDNs
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... -- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
In message <20130221225540.GA99258@numachi.com>, Brian Reichert writes:
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.
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Fri, 2013-02-22 at 16:57 +1100, Mark Andrews wrote:
RFC 952 as modified by RFC 1123 describe the legal syntax of a hostname. There is no trailing period.
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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
On Fri, Feb 22, 2013 at 05:19:03PM +1100, Karl Auer wrote:
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. :) I do appreciate the feedback provided thus far.
Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
----- Original Message -----
From: "Brian Reichert" <reichert@numachi.com>
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.
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Fri, Feb 22, 2013 at 12:41:33PM -0500, Jay Ashworth wrote:
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...
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
In short, "yes, Jay, I do". Got it. :-) You saw Joe's second reply? Brian Reichert <reichert@numachi.com> wrote:
On Fri, Feb 22, 2013 at 12:41:33PM -0500, Jay Ashworth wrote:
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...
Cheers, -- jra -- Jay R. Ashworth Baylink
jra@baylink.com
Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
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. Brian Reichert <reichert@numachi.com> wrote:
On Fri, Feb 22, 2013 at 05:21:02PM -0500, Jay Ashworth wrote:
In short, "yes, Jay, I do". Got it. :-)
:)
You saw Joe's second reply?
Apparently, I lost track of that while writing this up. :)
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On Fri, Feb 22, 2013 at 05:46:27PM -0500, Jay Ashworth wrote:
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.
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. :) -- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
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 ... Brian Reichert <reichert@numachi.com> wrote:
On Fri, Feb 22, 2013 at 05:46:27PM -0500, Jay Ashworth wrote:
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.
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. :)
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
In message <97006e8c-d3bd-4ced-b814-fc880130fbe1@email.android.com>, Jay Ashwor th writes:
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.
Brian Reichert <reichert@numachi.com> wrote:
On Fri, Feb 22, 2013 at 05:21:02PM -0500, Jay Ashworth wrote:
In short, "yes, Jay, I do". Got it. :-)
:)
You saw Joe's second reply?
Apparently, I lost track of that while writing this up. :)
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In message <20130222215502.GD99258@numachi.com>, Brian Reichert writes:
On Fri, Feb 22, 2013 at 12:41:33PM -0500, Jay Ashworth wrote:
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.
- 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...
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.
com
Designer The Things I Think RFC 2 100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1 274
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote:
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...
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
----- Original Message -----
From: "Brian Reichert" <reichert@numachi.com>
On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: [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. === More formally: "is a host/domain name with a trailing dot *actually a legal host name? Or is that merely local shorthand notation for resolvers and DNS server zone files, to define absoluteness. In short: are domain names on-the-wire *always* to be interpreted as absolute even in the absence of a trailing dot." My personal opinion, based on about 2 decades of watching from the outside, and of systems analysis and application design in non-internet contexts, is to say that yes, they must; there is *in fact* no reason for a relative domain name to leave a machine, since the context for it's relativity is dependent on the resolv.conf on that machine for lookups, and on which zone file it's in for service... and that the implication of that is that any application/library which takes a text-string host/domain name handed to it from off-machine ought to normalize away any trailing dot. I invite counter-arguments and -citations. :-) Cheers, -- jr 'yeah, I know, it's Monday' a -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Mon, Feb 25, 2013 at 09:49:19AM -0500, Jay Ashworth wrote:
----- Original Message -----
From: "Brian Reichert" <reichert@numachi.com>
On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: [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.
My understanding is this: Unless you're doing client certificate verification (wherein the server is making decisions about which clients attempting a connection), all validation/verification is done by the client. The SSL client retrieves the server's certificate, and the set of values in the Subject and the Subject Alternative Name is compared against the hostname/IP address used to initiate the process. This comparison is (to my understanding) straight-forward (modulo UTF8 encodings, etc.). The upshot (assuming I'm not totally off base here), is that other than getaddrinfo(), nothing is acting on the semantics of the supplied hostname (or IP address). They are 'just strings', and are (essentially) compared as such.
Cheers, -- jr 'yeah, I know, it's Monday' a -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
----- Original Message -----
From: "Brian Reichert" <reichert@numachi.com>
My understanding is this:
Unless you're doing client certificate verification (wherein the server is making decisions about which clients attempting a connection), all validation/verification is done by the client.
Right; my apologies; I know better than to post Before Coffee. :-)
The SSL client retrieves the server's certificate, and the set of values in the Subject and the Subject Alternative Name is compared against the hostname/IP address used to initiate the process. This comparison is (to my understanding) straight-forward (modulo UTF8 encodings, etc.).
The upshot (assuming I'm not totally off base here), is that other than getaddrinfo(), nothing is acting on the semantics of the supplied hostname (or IP address). They are 'just strings', and are (essentially) compared as such.
Right. And I'm asserting that that's wrong: the client side libraries Really Ought To normalize that name before trying to compare it against the retrieved certificate to see if it matches, which would relieve you of having to have the altName with the trailing dot in such a cert. The controlling standard *appears* to be RFC 2246, TLS v1.0. I'm doing some work this morning, but that's up in a tab for coffee breaks; I'll try to figure out what I think Dierks and Allen thought about this topic, if anything, during the day. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Mon, Feb 25, 2013 at 11:26:47AM -0500, Jay Ashworth wrote:
The upshot (assuming I'm not totally off base here), is that other than getaddrinfo(), nothing is acting on the semantics of the supplied hostname (or IP address). They are 'just strings', and are (essentially) compared as such.
Right. And I'm asserting that that's wrong: the client side libraries Really Ought To normalize that name before trying to compare it against the retrieved certificate to see if it matches, which would relieve you of having to have the altName with the trailing dot in such a cert.
I know for internal testing, I've had to introduce unqualified hostnames in the CSR as well (e.g. 'testhost', instead of 'testhost.example.com'), to handle the case of the client not using domain names at all (when framing queries). This illustrates that there's not even an effort to synthesize a FQDN. Who should implement the normalization logic? Not the SSL library, certainly. That sounds like the bailiwick of the resolver library...
The controlling standard *appears* to be RFC 2246, TLS v1.0. I'm doing some work this morning, but that's up in a tab for coffee breaks; I'll try to figure out what I think Dierks and Allen thought about this topic, if anything, during the day.
I look forward to the fruits of your research. :)
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
----- Original Message -----
From: "Brian Reichert" <reichert@numachi.com>
Right. And I'm asserting that that's wrong: the client side libraries Really Ought To normalize that name before trying to compare it against the retrieved certificate to see if it matches, which would relieve you of having to have the altName with the trailing dot in such a cert.
I know for internal testing, I've had to introduce unqualified hostnames in the CSR as well (e.g. 'testhost', instead of 'testhost.example.com'), to handle the case of the client not using domain names at all (when framing queries). This illustrates that there's not even an effort to synthesize a FQDN.
And there probably shouldn't be, and yes, you will probably have to have short names in there as altnames; there isn't -- and again, cannot be -- a rule for that; it's implementation dependent.
Who should implement the normalization logic? Not the SSL library, certainly. That sounds like the bailiwick of the resolver library...
No, in fact, I think this is layer... 3 or 4, not 2; this *should* be in the SSL library -- *you're not resolving this name*.
The controlling standard *appears* to be RFC 2246, TLS v1.0. I'm doing some work this morning, but that's up in a tab for coffee breaks; I'll try to figure out what I think Dierks and Allen thought about this topic, if anything, during the day.
I look forward to the fruits of your research. :)
Pomegranates. Martha Stewart taught me over the weekend how to get the seeds out without ruining them. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
----- Original Message -----
From: "Jay Ashworth" <jra@baylink.com>
Who should implement the normalization logic? Not the SSL library, certainly. That sounds like the bailiwick of the resolver library...
No, in fact, I think this is layer... 3 or 4, not 2; this *should* be in the SSL library -- *you're not resolving this name*.
Or maybe even above that. RFC 5246 seems the currently controlling spec, and neither it nor the Wikipedia article on this: https://en.wikipedia.org/wiki/Transport_Layer_Security actually says *what the client is supposed to do with the Server Certificate* which 7.4.2 says the server will send; appendix D.2 explicitly punts that question "upstairs"... but I'm not sure exactly to where, as I don't know in detail how HTTPS connections are generally set up. I suspect, though, that at this point, it leaves NANOG's domain. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
In message <15455394.7034.1361803759023.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
----- Original Message -----
From: "Brian Reichert" <reichert@numachi.com>
On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: [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.
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.
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.
===
More formally: "is a host/domain name with a trailing dot *actually a legal host name?
No. See RFC 952
Or is that merely local shorthand notation for resolvers and DNS server zone files, to define absoluteness. In short: are domain names on-the-wire *always* to be interpreted as absolute even in the absence of a trailing dot."
My personal opinion, based on about 2 decades of watching from the outside, and of systems analysis and application design in non-internet contexts, is to say that yes, they must; there is *in fact* no reason for a relative domain name to leave a machine, since the context for it's relativity is dependent on the resolv.conf on that machine for lookups, and on which zone file it's in for service...
and that the implication of that is that any application/library which takes a text-string host/domain name handed to it from off-machine ought to normalize away any trailing dot.
I invite counter-arguments and -citations. :-)
Cheers, -- jr 'yeah, I know, it's Monday' a -- Jay R. Ashworth Baylink jra@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: marka@isc.org
On Tue, Feb 26, 2013 at 09:07:24AM +1100, Mark Andrews wrote:
In message <15455394.7034.1361803759023.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
More formally: "is a host/domain name with a trailing dot *actually a legal host name?
No. See RFC 952
In the case of URIs, RFC 2396 (circa 1998) seems to allow for it, if I read the ABNF for 'hostname' right in section 3.2.2. But that's the only place I see it.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
----- Original Message -----
From: "Brian Reichert" <reichert@numachi.com>
More formally: "is a host/domain name with a trailing dot *actually a legal host name?
No. See RFC 952
In the case of URIs, RFC 2396 (circa 1998) seems to allow for it, if I read the ABNF for 'hostname' right in section 3.2.2.
But that's the only place I see it.
Concur, unhappily. And at this point, we are *definitely* out-of-scope for NANOG. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
----- 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. As I note here:
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.
:-)
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? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
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.
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 jra@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: marka@isc.org
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
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.
And except on length and first-digit-allowed, 1123 punts naming to 952 (which doesn't really say) and in 6.1, to 1034 and 1035. So I know what my light night reading will be (unless Albitz, Liu, Mockapetris, or any of the BIND team are around on the list :-)
RFC 1535 is NOT a STANDARD. Not all RFC are created equal.
Typo. 1035 (as updated by whatever is on-point, if anything). And Mark: could you please trim your quoting a bit? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
In message <17812038.7306.1361835383974.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
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.
And except on length and first-digit-allowed, 1123 punts naming to 952 (which doesn't really say) and in 6.1, to 1034 and 1035. So I know what my light night reading will be (unless Albitz, Liu, Mockapetris, or any of the BIND team are around on the list :-)
952 says hostnames don't end in a period. Note that periods are only allowed when they serve to delimit components of "domain style names". <hname> ::= <name>*["."<name>] <name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>] 1123 turned <name> into <name> ::= <let-or-digit>[*[<let-or-digit-or-hyphen>]<let-or-digit>] it also banned all digit tlds (no covered in the grammar).
RFC 1535 is NOT a STANDARD. Not all RFC are created equal.
Typo. 1035 (as updated by whatever is on-point, if anything).
And 1035 refers you to 952 + 1123 for hostnames. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs. For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names. HOSTS.TXT == RFC 952. Host names and domain names are not interchangable in all contexts. You need to know the subtle differences and when which rules apply. Lots of rfcs fail to make the proper distinctions and use domain name when they mean domain style hostname. Mark
And Mark: could you please trim your quoting a bit?
Cheers, -- jra -- Jay R. Ashworth Baylink jra@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: marka@isc.org
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
On 2/25/13, Jay Ashworth <jra@baylink.com> wrote:
From: "Brian Reichert" <reichert@numachi.com> [snip] 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.
By the time the hostname is sent over HTTP, the SSL connection is already established, and all the SSL negotiation already happened.. it's up to the client to validate the server's FQDN matches the CN of the certificate, or an alternative DNS name; which are all are (hopefully) or ought to be, by definition FQDNs, before the server knows what hostname(s) HTTP requests will be made against. If the domain in a certificate were not interpreted as a FQDN by the client, this would mean, that the certificate for CN=bigbank.example.com might be used to authenticate a connection to https://bigbank.example.com which do the local resolver search order, is in fact a DNS lookup of bigbank.example.com.intranet.example.com Which might be captured by a Wildcard A record for *.com found in the intranet.example.com. zone and pointed to a server containing a phishing attack against bigbank.example.com; with a DNS cache poisoned by a false negative cache NXDOMAIN entry for bigbank.example.com. The exeption to not sending the domain name before encryption, would be the shiny new TLS protocol version with the server supporting the rarely used SNI extension; extension for server name indication, that will one day allow virtual hosting for TLS protected HTTP transport, sharing one IP address, with a different X509 certificate served up by the server, based on which hostname has been requested (once browsers and servers begin to support TLS1.2 as a replacement for SSL); in this case, the crypto stack on the server does gain access to the hostname. It probably doesn't matter if the server removes the "." or not, before sending it.. the server has to allow the dot. The HTTP/1.1 does mention something about HTTP proxies possibly being able to handle a hostname that is not a FQDN, solely by appending their own domain to the hostname; appending a suffix to the hostname is allowed, in that specific case, but a FQDN must not be changed. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2 " The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2). If a proxy receives a host name which is not a fully qualified domain name, it MAY add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy MUST NOT change the host name. " -- -JH
----- Original Message -----
From: "Jimmy Hess" <mysidia@gmail.com>
By the time the hostname is sent over HTTP, the SSL connection is already established, and all the SSL negotiation already happened..
Correct, and yes, I did already know that (though, this morning, before coffee, it would have been hard to tell for sure :-).
it's up to the client to validate the server's FQDN matches the CN of the certificate, or an alternative DNS name; which are all are (hopefully) or ought to be, by definition FQDNs, before the server knows what hostname(s) HTTP requests will be made against.
Also correct. Our issue on point is this: that match where we supply an FQDN is performed by *some piece of code*, which knows that there are multiple names against which to match. What does that code do with a hostname string which is terminated by a period (it apparently does not treat it specially, and just attempts to match with it included, from Brian's experience) and... Is that the proper behavior?
If the domain in a certificate were not interpreted as a FQDN by the client, this would mean, that the certificate for CN=bigbank.example.com might be used to authenticate a connection to https://bigbank.example.com which do the local resolver search order, is in fact a DNS lookup of bigbank.example.com.intranet.example.com
Sure: you can't match a supplied server domain name against cert names which are *longer* (have more atoms) than it is; I get that, see why, and approve.
Which might be captured by a Wildcard A record for *.com found in the intranet.example.com. zone and pointed to a server containing a phishing attack against bigbank.example.com; with a DNS cache poisoned by a false negative cache NXDOMAIN entry for bigbank.example.com.
As is mentioned in RFC 1535, which Mark chastised me for accidentally mentioning a couple hours ago; yes. :-) Oh wait; no, this is a different *class* of attack, no? I can't *have* a wildcard for *.com, *because my resolvers won't ask my servers for that; they'll ask the root*; or do I need to finish reading 1535?
The exeption to not sending the domain name before encryption, would be the shiny new TLS protocol version with the server supporting the rarely used SNI extension; extension for server name indication, that will one day allow virtual hosting for TLS protected HTTP transport, sharing one IP address, with a different X509 certificate served up by the server, based on which hostname has been requested (once browsers and servers begin to support TLS1.2 as a replacement for SSL); in this case, the crypto stack on the server does gain access to the hostname.
Wow; we *really* don't want to implement IPv6, do we? :-)
It probably doesn't matter if the server removes the "." or not, before sending it.. the server has to allow the dot.
It's not a question of what the server does; the server returns a Server Certificate packet, which the client library either matches on itself, or hands upstairs to ... something else. One of those two things makes the comparison, and our question is: Should that thing trim a trailing dot *off the local string*, before matching the names that came in in the cert. If my assertion from this morning, that names are automatically "absolute" in 1035 terms -- that is, a domain name with a dot after is equal to one without -- *everywhere except* 1) in a resolver query (where they're a hint to the resolver, and *don't* go out with the dot over the wire -- at leastI think they don't; I have to double check... and 2) inside a zone file, where they're a hint to the *server* about where to root the record; against $ORIGIN or not... is true, then the behavior I suggest for opening an SSL/TLS connection should also hold: strip the dot before you match, then match absolutely.
The HTTP/1.1 does mention something about HTTP proxies possibly being able to handle a hostname that is not a FQDN, solely by appending their own domain to the hostname; appending a suffix to the hostname is allowed, in that specific case, but a FQDN must not be changed.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2 " The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2). If a proxy receives a host name which is not a fully qualified domain name, it MAY add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy MUST NOT change the host name. "
Hmmm. I don't know that that applies here; we're strictly HTTPS; can you proxy that? Even if you could, the thing you need to look at is inside the encrypted channel, I think. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Mon, 25 Feb 2013 19:07:20 -0600, Jimmy Hess said:
If the domain in a certificate were not interpreted as a FQDN by the client, this would mean, that the certificate for CN=bigbank.example.com might be used to authenticate a connection to https://bigbank.example.com which do the local resolver search order, is in fact a DNS lookup of bigbank.example.com.intranet.example.com
Which might be captured by a Wildcard A record for *.com found in the intranet.example.com. zone and pointed to a server containing a phishing attack against bigbank.example.com; with a DNS cache poisoned by a false negative cache NXDOMAIN entry for bigbank.example.com.
I am *sooo* tempted to say "I recommend my competitors do DNS lookups this way" :)
On Feb 25, 2013, at 6:30 AM, Brian Reichert <reichert@numachi.com> wrote:
On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote:
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.
getaddrinfo should not reject foo.blah.com. or foo.blah.com. However, it will use the data… foo.blah.com will have the domain search strings (if any) appended, so for example, if your search configuration is "blah.com, example.com", then it will search for foo.blah.com.blah.com., foo.blah.com.example.com., and foo.blah.com. until it finds a match. However, that's for the resolver library. In terms of matching the CN in a certificate, this should always be FQDN and the trailing dot should not be present. If OpenSSL (the command line tool) is passing foo.blah.com. to the SSL functions and not just getaddrinfo(), then, it is a bug. Owen
On 02/25/2013 11:47 AM, Owen DeLong wrote:
On Feb 25, 2013, at 6:30 AM, Brian Reichert <reichert@numachi.com> wrote:
On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote:
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.
getaddrinfo should not reject foo.blah.com. or foo.blah.com. However, it will use the data… foo.blah.com will have the domain search strings (if any) appended, so for example, if your search configuration is "blah.com, example.com", then it will search for foo.blah.com.blah.com., foo.blah.com.example.com., and foo.blah.com. until it finds a match.
The lookup order should be foo.blah.com, foo.blah.com.blah.com, foo.blah.com.example.com ?
However, that's for the resolver library. In terms of matching the CN in a certificate, this should always be FQDN and the trailing dot should not be present. If OpenSSL (the command line tool) is passing foo.blah.com. to the SSL functions and not just getaddrinfo(), then, it is a bug.
Owen
-- -______________________ David Miller dmiller@tiggee.com
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
However, that's for the resolver library. In terms of matching the CN in a certificate, this should always be FQDN and the trailing dot should not be present. If OpenSSL (the command line tool) is passing foo.blah.com. to the SSL functions and not just getaddrinfo(), then, it is a bug.
If I understood Brian correctly, his problem is that people/programs are trying to retrieve things from, eg: https://my.host.name./this/is/a/path and the SSL library fails the certificate match if the cert doesn't contain the absolute domain name as an altName -- because *the browser* (or whatever) does not normalize before calling the library. As I suggest in another thread, I think the SSL library probably ought to be normalizing off that trailing dot itself, before trying to match the string supplied to the names in the retrieved cert. It sounds as if you might agree with me, at least in principle. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Feb 25, 2013, at 9:18 AM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
However, that's for the resolver library. In terms of matching the CN in a certificate, this should always be FQDN and the trailing dot should not be present. If OpenSSL (the command line tool) is passing foo.blah.com. to the SSL functions and not just getaddrinfo(), then, it is a bug.
If I understood Brian correctly, his problem is that people/programs are trying to retrieve things from, eg:
https://my.host.name./this/is/a/path
and the SSL library fails the certificate match if the cert doesn't contain the absolute domain name as an altName -- because *the browser* (or whatever) does not normalize before calling the library.
As I suggest in another thread, I think the SSL library probably ought to be normalizing off that trailing dot itself, before trying to match the string supplied to the names in the retrieved cert.
It sounds as if you might agree with me, at least in principle.
I don't see any reason that the SSL library shouldn't normalize the name and remove the trailing dot. However, even if the SSL library does so, I see no valid reason that would relieve the browser of the obligation to do so as well. Be conservative in what you send (or pass to a library) and liberal in what you accept. Under that principle, the SSL library should accept either one and normalize it. However, the browser should also normalize what it passes to the SSL library. Owen
On Mon, Feb 25, 2013 at 12:18:00PM -0500, Jay Ashworth wrote:
If I understood Brian correctly, his problem is that people/programs are trying to retrieve things from, eg:
https://my.host.name./this/is/a/path
and the SSL library fails the certificate match if the cert doesn't contain the absolute domain name as an altName -- because *the browser* (or whatever) does not normalize before calling the library.
I'd argue that if you have an absolute domain name, then that _is_ the 'normalized' form of the domain name; it's an unambigious representation of the domain name. (Here, I'm treating the string as a serialized data structure.) Choosing to remove the notion of "this is rooted", and then asking any (all?) other layers to handle the introduced ambiguity sounds like setting yourself up for the issues that RFC 1535 was drawing attention to.
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
On 02/25/2013 09:49 AM, Brian Reichert wrote:
On Mon, Feb 25, 2013 at 12:18:00PM -0500, Jay Ashworth wrote:
If I understood Brian correctly, his problem is that people/programs are trying to retrieve things from, eg:
https://my.host.name./this/is/a/path
and the SSL library fails the certificate match if the cert doesn't contain the absolute domain name as an altName -- because *the browser* (or whatever) does not normalize before calling the library.
I'd argue that if you have an absolute domain name, then that _is_ the 'normalized' form of the domain name; it's an unambigious representation of the domain name. (Here, I'm treating the string as a serialized data structure.)
Choosing to remove the notion of "this is rooted", and then asking any (all?) other layers to handle the introduced ambiguity sounds like setting yourself up for the issues that RFC 1535 was drawing attention to.
Brian, This may be a silly question, but what's your goal here? Your OP was about terminology, but the thread has gone down several different off-topic ratholes. Doug
On Mon, Feb 25, 2013 at 10:10:55AM -0800, Doug Barton wrote:
Brian,
This may be a silly question, but what's your goal here? Your OP was about terminology, but the thread has gone down several different off-topic ratholes.
That was indeed by original goal, and there have been a couple of useful suggestions, and I thank this forum for all of the suggestions and feedback. I later mentioned why I was pursuing the terminology (use case surrounding entries in a SAN), and there's some effort to consider whether or not my issue is really a non-issue. Which it might be.
Doug
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
----- Original Message -----
From: "Brian Reichert" <reichert@numachi.com>
On Mon, Feb 25, 2013 at 12:18:00PM -0500, Jay Ashworth wrote:
If I understood Brian correctly, his problem is that people/programs are trying to retrieve things from, eg:
https://my.host.name./this/is/a/path
and the SSL library fails the certificate match if the cert doesn't contain the absolute domain name as an altName -- because *the browser* (or whatever) does not normalize before calling the library.
I'd argue that if you have an absolute domain name, then that _is_ the 'normalized' form of the domain name; it's an unambigious representation of the domain name. (Here, I'm treating the string as a serialized data structure.)
I disagree, and happily, I can tell you exactly why.
Choosing to remove the notion of "this is rooted", and then asking any (all?) other layers to handle the introduced ambiguity sounds like setting yourself up for the issues that RFC 1535 was drawing attention to.
The interface we're talking about here is an application on a machine asking the SSL library "does the certificate which I have retrieved and handed to you for processing match this domain name?" *Since that certificate has [possibly] come from a different machine*, the context in which that evaluation must be done seems necessarily to be "over the wire/remote", and -- if you accept my earlier premise -- *it[1] is inherently absolute, no matter what it contains*. Since that context exists, you can then safely strip off the trailing dot inside the library before making said comparison. This is not the same circumstance as being presented with a shortname, where the actual IP connection/SSL retrieval was done based on the resolver applying a search path: in this case there's no obvious thing which the library could add, whereas it *is* obvious what you should strip (and, I allege, why) in the absolute-name-provided case. [1] The context of the evaluation, and by extension, the context of the string you're handing the SSL library to do the match. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
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. Rich Kulawiec <rsk@gsp.org> wrote:
On Fri, Feb 22, 2013 at 05:19:03PM +1100, Karl Auer wrote:
It's a convention common enough and useful enough that I can see why people would want a handy term for it.
How about "stopdot"? Seems to cover the function and the form.
---rsk
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
----- Original Message -----
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. Or *course* the trailing dot matters, even if only due to the behavior of DNS resolvers. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
In message <24339470.6878.1361551954109.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
----- Original Message -----
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.
Or *course* the trailing dot matters, even if only due to the behavior of DNS resolvers.
Cheers, -- jra -- Jay R. Ashworth Baylink jra@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: marka@isc.org
On Fri, Feb 22, 2013 at 04:57:42PM +1100, Mark Andrews wrote:
RFC 952 as modified by RFC 1123 describe the legal syntax of a hostname. There is no trailing period.
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 -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
On 2013-02-22, at 14:01, Andrew Sullivan <asullivan@dyn.com> wrote:
On Fri, Feb 22, 2013 at 04:57:42PM +1100, Mark Andrews wrote:
RFC 952 as modified by RFC 1123 describe the legal syntax of a hostname. There is no trailing period.
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.
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
----- Original Message -----
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. :-)
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. :-) Cheers, -- jr 'new intercalations on every message for authentication' a -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Jay, On 2013-02-22, at 14:20, Jay Ashworth <jra@baylink.com> wrote:
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. :-)
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
----- Original Message -----
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. :-)
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. :-)
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On 2013-02-22, at 14:39, Jay Ashworth <jra@baylink.com> wrote:
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 :-) 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
On Fri, Feb 22, 2013 at 01:39:21PM -0500, Jay Ashworth wrote:
but since the dot is a separator (I believe by definition), if it exists at the end, it has to be separating *something*.
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 -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
On 2/22/13 11:01 AM, Andrew Sullivan wrote:
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.
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.
On Fri, Feb 22, 2013 at 02:10:02PM -0800, Eric Brunner-Williams wrote:
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.
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 -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
http://domainincite.com/page/5?s=right+of+the+dot -- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
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
----- Original Message -----
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. """ 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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On 2/22/13, Jay Ashworth <jra@baylink.com> wrote: 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. "
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. """
Jay R. Ashworth Baylink -- -JH
----- Original Message -----
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 http://www.slac.physics/ is a valid and common URL that. :-)
" 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. "
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Fri, Feb 22, 2013 at 10:26:58PM -0600, Jimmy Hess wrote:
No trailing dot allowed; "each domain label starting and ending with an alphanumerical character";
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 -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
We can call them "rooted" domain names and "pwned" domain names... --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
-----Original Message----- From: Andrew Sullivan [mailto:asullivan@dyn.com] Sent: Saturday, 23 February, 2013 15:15 To: nanog@nanog.org Subject: Re: looking for terminology recommendations concerning non-rooted FQDNs
On Fri, Feb 22, 2013 at 10:26:58PM -0600, Jimmy Hess wrote:
No trailing dot allowed; "each domain label starting and ending with an alphanumerical character";
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
-- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
In message <30545475.6952.1361592063875.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
----- Original Message -----
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.
(PS: your quoting (or bulleting) protocol is non-standard and non-intuitive)
Cheers, -- jra
-- Jay R. Ashworth Baylink jra@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: marka@isc.org
On 2/21/13, Mark Andrews <marka@isc.org> wrote:
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.
-- Brian Reichert <reichert@numachi.com> BSD admin/developer at large
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- -JH
participants (16)
-
Andrew Sullivan -
Barry Shein -
Brian Reichert -
Cutler James R -
David Miller -
Doug Barton -
Eric Brunner-Williams -
Jay Ashworth -
Jimmy Hess -
Joe Abley -
Karl Auer -
Keith Medcalf -
Mark Andrews -
Owen DeLong -
Rich Kulawiec -
Valdis.Kletnieks＠vt.edu