Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The danger of the trailing dot in the domain name

saynt2day.blogspot.ru

Post reply on HN
Print view View original

11–20 of 75 posts

Re: The danger of the trailing dot in the domain name

#11

Post by __david__ »

derefr wrote: post #5
__david__ wrote: post #2

What is the rationale for web browsers to consider "example.com." different from "example.com" when validating SSL certificates? At first blush this seems silly, but I may not have thought through the security consequences thoroughly.

Well, for the purposes of SSL verification, or any of these other tests, "localhost" and "localhost." are two very different machines--one is "your" localhost, while the other is "the" localhost [theoretically, the A record for a TLD called "localhost"]. Same with "foo.local" and "foo.local." Any non-rooted domain actually has the potential to have what is called a "search domain" applied to it: if your own host's FQ…

> "localhost" and "localhost." are two very different machines--one is "your" localhost, while the other is "the" localhost

I don't think this is correct. Check out RFC 2606--it implies that .localhost (the TLD) is localhost, which means "localhost" and "localhost." are the same (one will definitely not have a search domain added to it though).

I suspect the same applies to .local—I just checked and the multicast DNS draft RFC [1] refers to ".local." everywhere.

[1] https://tools.ietf.org/html/draft-cheshire-dnsext-multicastd...

Re: The danger of the trailing dot in the domain name

#12

Post by derefr »

__david__ wrote: post #11
derefr wrote: post #5

Earlier quoted context omitted.

Well, for the purposes of SSL verification, or any of these other tests, "localhost" and "localhost." are two very different machines--one is "your" localhost, while the other is "the" localhost [theoretically, the A record for a TLD called "localhost"]. Same with "foo.local" and "foo.local." Any non-rooted domain actually has the potential to have what is called a "search domain" applied to it: if your own host's FQ…

> "localhost" and "localhost." are two very different machines--one is "your" localhost, while the other is "the" localhost I don't think this is correct. Check out RFC 2606--it implies that .localhost (the TLD) is localhost, which means "localhost" and "localhost." are the same (one will definitely not have a search domain added to it though). I suspect the same applies to .local—I just checked and the multicast DNS…

Hrm, you're right--that's what I get for using any specific examples :)

Any other TLD--besides the special-cased "private virtual" ones (localhost., local.)--will still have this problem, though.

Re: The danger of the trailing dot in the domain name

#14

Post by joosters »

pilif wrote: post #10

The fact that the two IIS based sites (Microsoft, Stack overflow) both fail with an outright error 400 complaining about a bad host name makes me wonder whether this might actually be a bug in IIS to overzealously validate the hostname. The trailing dot is totally valid and there's no need to complain.

The 400 error is just the web server complaining that there is no web site to deliver to you for that hostname. It isn't complaining about the hostname being invalid, per se.

Re: The danger of the trailing dot in the domain name

#16

Post by paulbeattie »

pilif wrote: post #10

The fact that the two IIS based sites (Microsoft, Stack overflow) both fail with an outright error 400 complaining about a bad host name makes me wonder whether this might actually be a bug in IIS to overzealously validate the hostname. The trailing dot is totally valid and there's no need to complain.

I think you might be right. I just tried it on an IIS server set to accept any hostname at the IP the site is bound to and it returned a 400 error as well. Removing the trailing dot made it work.

Re: The danger of the trailing dot in the domain name

#17

Post by hkolk »

__david__ wrote: post #2

What is the rationale for web browsers to consider "example.com." different from "example.com" when validating SSL certificates? At first blush this seems silly, but I may not have thought through the security consequences thoroughly.

From the looks of it, Safari ignores the trailing dot when validating (as you can see when going to https://www.facebook.com./ ). Curl on the other hand doesn't

Re: The danger of the trailing dot in the domain name

#18

Post by zmb_ »

__david__ wrote: post #2

What is the rationale for web browsers to consider "example.com." different from "example.com" when validating SSL certificates? At first blush this seems silly, but I may not have thought through the security consequences thoroughly.

Because technically speaking they are different things. "example.com." refers to a domain name in a system with a nameless root (like the Internet DNS namespace managed by ICANN). "example.com" would refer to some different (non existent) domain name system with a root called "com".

The problem is that in practice many implementations that use DNS names display "example.com" to the user when they really mean "example.com." and many certificates are signed for "example.com" when they really mean to be signing for "example.com." A proper implementation would use "example.com." everywhere, but might choose to display "exmample.com" in the GUI if they consistently translate between the two.

Re: The danger of the trailing dot in the domain name

#19

Post by derleth »

http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web...

> [The trailing dot in the domain name is] there for a reason. It made the domain name a fully qualified one, and thus unambiguous and not prone to search path spoofing.

[snip]

> For example: Posit that the web browser uses the BIND DNS Client library and the search example.net directive is present in that library's resolv.conf configuration file.

> In the case that the URL provided by the user is http://example.com/, a web browser would pass example.com to the BIND DNS Client library for looking up its IP address(es). Because the RES_DNSRCH option is set and the domain name does not end in a trailing dot, the BIND DNS Client library would take the domain name to not be in fully-qualified form and apply its "search path" mechanism. It would look up example.com.example.net. and, if that domain name happened to exist, would return the IP address(es) corresponding to that domain name instead of the IP address(es) corresponding to example.com.. The web browser would contact the content HTTP server at the former IP address(es) without the user being aware of it.

> In the case that the URL provided by the user is http://example.com./, a web browser would pass example.com. to the BIND DNS Client library for looking up its IP address(es). Because the domain name ends in a trailing dot, the BIND DNS Client library would take the domain name to be in fully-qualified form and not apply its "search path" mechanism. It would look up example.com. and, would return the IP address(es) corresponding to that domain name.

> The fully-qualified domain name would thus prevent search path spoofing. (See RFC 1535 and RFC 1536 § 6 for more discussion of this.)

Re: The danger of the trailing dot in the domain name

#20

Post by mfwoods »

hkolk wrote: post #17
__david__ wrote: post #2

What is the rationale for web browsers to consider "example.com." different from "example.com" when validating SSL certificates? At first blush this seems silly, but I may not have thought through the security consequences thoroughly.

From the looks of it, Safari ignores the trailing dot when validating (as you can see when going to https://www.facebook.com./ ). Curl on the other hand doesn't

Firefox (nightly) and chromium don't ignore the trailing dot either and both display an invalid certificate error.
Post reply on HN