7 ms·

The danger of the trailing dot in the domain name

182 points by nicolly 14y ago

__david__ 14y ago
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.
- derefr 14y ago
  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 FQDN is bob.example.com, going to "foo.com" can actually take you to "foo.com.example.com.", just like going to "foo" can take you to "foo.example.com." It's just that, conventionally, although it was always an option to use weird TLD-lookin' subdomain hierarchies within domains like that, nobody does it, because it's so confusing. I don't think much at all would break if we enforced a "if your non-rooted domain ends in a known TLD, canonicalize it to a rooted domain before comparison" rule in browsers, the OpenSSL and OpenSSH libraries, etc., and then require that going forward, all X.509 certs, CORS policies, and so forth which are meant to refer to an FQDN are issued only for the rooted version. [If you're curious, DNS zone records themselves are always already canonicalized into rooted form whenever you edit them through any sensible interface.]
  - __david__ 14y ago
    > "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-multicastdns-15 https://tools.ietf.org/html/draft-cheshire-dnsext-multicastd...
    - derefr 14y ago
      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.
- gingerlime 14y ago
  It's a very good question. I particularly wonder if one can set "www.example.com" to point to a different address from "www.example.com." (globally, not via changing /etc/hosts or your local dns server...)? If they are practically equivalent, then I can't think of much security benefit from treating them differently. Even if changing the behaviour won't cause any security risk, I can't imagine this being a simple change to make. The SSL certificate contains a digital signature that is performed on a hash of many details, including the CN which is typically the FQDN (without the trailing dot). The `CN==requested-server-name?' matching can be performed at different layers and is probably deeply embedded within the specification and in different implementations. Add this to the practicality of needing to use both www.example.com and www.example.com. - it seems that the balance is in favour of keeping things simple and as the post suggested, use a redirect (or buying an extra certificate).
- hkolk 14y ago
  From the looks of it, Safari ignores the trailing dot when validating (as you can see when going to https://www.facebook.com./ https://www.facebook.com./ ). Curl on the other hand doesn't
  - mfwoods 14y ago
    Firefox (nightly) and chromium don't ignore the trailing dot either and both display an invalid certificate error.
- zmb_ 14y ago
  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.
derefr 14y ago
D'oh. It would seem to me that for the purposes of X.509/CORS/server config/etc. equality, domains which seem to be rooted in any of the TLD registries should be canonicalized first to add the dot on both sides (along with doing the IRI -> URI conversion and so forth that should happen either way.) Is there any reason that would be a bad idea?
demetrius 14y ago
I use RequestPolicy to whitelist access to other domains' resources. Usually most sites that have CSS on external resources show up as black-and-white, which is perfectly readable. But this one is displayed as blue text on red background... WTF?
- derefr 14y ago
  It's something I see a lot over slow connections--more commonly, black text on a black background, where eventually a white "content-layer background" image will load behind the text, making it readable.
deleted 14y ago
[deleted]
raverbashing 14y ago
I wouldn't call it a 'danger' more like an 'annoyance', unless someone is MITM you with a certificate for the name ending in dot or something like that Maybe redirect, but I'd go for making it not work, period. (I don't mean 'broken', I mean blank page or forbidden)
pilif 14y ago
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.
- joosters 14y ago
  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.
  - pilif 14y ago
    I thought so too, but then I made a little experiment: pilif@shion:~$ curl -I -H "Host: example.com" http://198.252.206.16/ HTTP/1.1 404 Not Found Content-Length: 4129 Date: Sat, 16 Mar 2013 12:28:22 GMT vs. pilif@shion:~$ curl -I -H "Host: example.com." http://198.252.206.16/ HTTP/1.1 400 Bad Request Content-Length: 334 Content-Type: text/html; charset=us-ascii Date: Sat, 16 Mar 2013 12:28:56 GMT The IP is the one from stackoverflow.com. When querying for a host they are not configured (try any), you will get a 404 plus an explanation page that the selected Q&A community doesn't exist. When you try the same host with a trailing dot, you get a generic IIS error 400. This is too much of a coincidence and I value it as a strong sign that my hypothesis might be correct. I have no IIS at my disposal to replicate paulbeattie's experiment, but the outcome he described further helps confirming my suspicion (no matter the downvotes he got) Same experiment works with microsoft.com too: pilif@shion:~$ curl -I -H "Host: example.com." http://65.55.57.27/ HTTP/1.1 400 Bad Request Content-Length: 334 Content-Type: text/html; charset=us-ascii Server: Microsoft-HTTPAPI/2.0 Date: Sat, 16 Mar 2013 12:35:10 GMT Connection: close pilif@shion:~$ curl -I -H "Host: example.com" http://65.55.57.27/ HTTP/1.1 200 OK Cache-Control: private Content-Length: 0 Server: Microsoft-IIS/8.0 (snip)
    - joosters 14y ago
      That's odd, I would have thought that '404 Not Found' would be the wrong response to send, although you could argue either way. I used to develop a web server ages ago (Zeus Web Server), it would try and match the Host: header against all the sites it was configured to server, and if none matched, it would send a 400 error back. (Incidentally, it would happily strip off the trailing dot from the hostname)
judofyr 14y ago
Also note that Chrome allows you to set document.domain = "" if you have the trailing dot so you could use it for cross-origin communication.
th0114nd 14y ago
Why is this something that people do?
- pax 14y ago
  Why, is this something that people do? no, I read it as a solution to a problem that doesn't occur. It's way worse if somebody would type a comma or any other letter at the end of the domain name, as I just learned, the dot is the best character to mistake at the end of a domain
  - deleted 14y ago
    [deleted]
- jvdh 14y ago
  Because they can. Curiosity is a very strong and very valid reason to do things. It can very often lead to new insights. And of course it is also necessary from a security point of view to test these kinds of things to see if they lead to strange behaviour.
derleth 14y ago
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-fully-qualified-domain-name.html 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/ 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./ 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.)
- zimbatm 14y ago
  The search path spoofing argument is weak. If you depend on a DNS resolver that spoofs domain searches, what guaranteed that it wouldn't simply spoof the full resolution as well ? In practice nobody uses the dot at the end except when writing BIND files.
  - sp332 14y ago
    The DNS resolver doesn't need to spoof anything. If you're on network example.net and there's a server on that network called "google" then typing "google" into your address bar will resolve to google.example.net in a completely legitimate way, with no DNS spoofing.
hiddenfeatures 14y ago
Just tried it with my app on heroku and get an HTTP 404 "no such app" error. Tried to add www.mydomain.com. to the domain list in the admin interface. Didn't work either stating "Domain is invalid". Gna...
- emddudley 14y ago
  Use example.com in examples, since mydomain.com is an actual website.
  - sp332 14y ago
    Or if you want to make it clear that it's your domain, mydomain.example or mydomain.test https://en.wikipedia.org/wiki/Top-level_domain#Reserved_domains https://en.wikipedia.org/wiki/Top-level_domain#Reserved_doma...
- mmmmm 14y ago
  You don't need to add the FQDN - heroku already supports it. E.g. http://www.leedsindustrialestate.co.uk./ http://www.leedsindustrialestate.co.uk./ is a Heroku hosted site.
dukekarthik 14y ago
The trailing dot (.) at the end of the domain name denotes the root nameservers. There are 13 such servers in the world. $ dig ns . ; <<>> DiG 9.8.1-P1 <<>> ns . ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38974 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 21088 IN NS a.root-servers.net. . 21088 IN NS b.root-servers.net. . 21088 IN NS c.root-servers.net. . 21088 IN NS d.root-servers.net. . 21088 IN NS e.root-servers.net. . 21088 IN NS f.root-servers.net. . 21088 IN NS g.root-servers.net. . 21088 IN NS h.root-servers.net. . 21088 IN NS i.root-servers.net. . 21088 IN NS j.root-servers.net. . 21088 IN NS k.root-servers.net. . 21088 IN NS l.root-servers.net. . 21088 IN NS m.root-servers.net. ;; Query time: 51 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Sat Mar 16 19:32:57 2013 ;; MSG SIZE rcvd: 228 This is very helpful in DNS propagation and pointing the appropriate authoritative zone for all the TLDs.
- 16s 14y ago
  Every "web developer" should read the first three chapters of the Cricket book. The profound ignorance (that many web developers have) of DNS is inexcusable: http://www.amazon.com/DNS-BIND-5th-Cricket-Liu/dp/0596100574 http://www.amazon.com/DNS-BIND-5th-Cricket-Liu/dp/0596100574
- jameshart 14y ago
  The . doesn't indicate the root nameservers at all - it indicates that the DNS name to be resolved is an absolute name, not a relative name. All nameservers - root or otherwise - specify the names they know relative to the absolute global domain namespace root, ".". When resolving a hostname, your computer's DNS resolver will look for it in various 'search path' contexts, much like a shell looks for executables relative to all the directories in your PATH. Asking it to resolve news.ycombinator.com will lead to it looking for news.ycombinator.com., but also maybe trying various connection-specific DNS suffixes your network interfaces have configured, or global search suffixes. Commonly macs, for example, try resolving names within the domain 'directory' of "home." - http://mymacbookpro/ http://mymacbookpro/ will look for a machine called "mymacbookpro.home." as well as "mymacbookpro.home.". But http://mymacbookpro./ http://mymacbookpro./ is specifying the absolute path - the resolver won't look for mymacbookpro.home., only mymacbookpro. Conversely, if you type in http://news.ycombinator.com/ http://news.ycombinator.com/, it will look for a "news.ycombinator.com.home." as well as a "news.ycombinator.com.". Yes, you're right - that is an opening for a spoofing attack if you use a compromised or untrustworthy DNS service on your local network. The root nameservers are just one place your DNS resolver looks to to ask questions like "who is the authoritative DNS server for domain names in .com.?" once it's decided to look up a name like news.ycombinator.com..
16s 14y ago
You can cd to /home/user or /home/user/ as well. The dot's in DNS are equivalent to the slashes in your Unix file system. / is root . is root I'm shocked that many people on HN don't seem to understand this.
- harshreality 14y ago
  My shock is that some webservers don't remove an ending dot before trying to match a virtual host (any besides IIS?), and that web browsers don't assume equivalence, for website SSL cert CN purposes, between "fqdn." and "fqdn". I'm also shocked that chrome and firefox send a relative domain in Host: headers if that's what's typed into the url bar. Why wouldn't they send the fqdn? Is it specified this way in some RFC? What does this browser "feature" do other than require webservers in orgs with corpdomain.com search paths to add additional vhost aliases to ensure all the requests get to the right place? Switching vhosts to an intranet website based on the request's Host header does not provide any security in an intranet/dns-search-path setup.
  - AnthonyMouse 14y ago
    It's because it makes the attacker's job easier. "fqdn." and "fqdn" are not the same thing. They may not resolve to the same machine. If one of them resolves to the attacker's machine, you certainly don't want them to be equivalent.
    - harshreality 14y ago
      They're not equivalent, but most or all major CAs issue certs without terminating dots, apparently. So I fail to see how distinguishing them during browser checks for cert validity accomplishes anything. If an attacker controls "fqdn.localsite.com." when the client's (Alice's) intended destination is "fqdn.", isn't the client fooled when Alice has a localsite.com dns search path, if the attacker (Mallory) manages to get a cert for "fqdn"? (Let's suppose Mallory has access to email for "hostmaster@fqdn." but can't get access to the actual "fqdn." webserver to do the attack that way; Mallory sets up "fqdn.localsite.com." to fool Alice's browser which is subject to a "localsite.com." search path.) If it's the reverse, where Mallory is external and controls "fqdn." and Alice is expecting to get to "fqdn.localsite.com." because of dns search rules, but the dns search rules are broken and Alice gets sent to "fqdn." instead, Mallory wins because the CA-issued cert for the "fqdn." site won't have the terminating dot, right?
TazeTSchnitzel 14y ago
Where have we got to the point where a relative hostname is accepted by 100% of websites yet an absolute hostname isn't? Surely it should be the other way round, this is a ridiculous state of affairs!
- AnthonyMouse 14y ago
  Up voted, because "forward example.com. to example.com" is exactly backwards. Think about what happens to the user who doesn't have 'example.com' (the relative hostname) resolve to the same address as 'example.com.' (the absolute hostname). Now they want to get to 'example.com.', they type 'example.com.' and they get forwarded to 'example.com', which resolves to example.com.localdomain.com according to their local DNS server. Oops.
  - TazeTSchnitzel 14y ago
    It's like having everything rely on directories called "com" and "net", but when someone uses the correct, absolute path of "/com" or "/net" it somehow stops working. Nobody would stand for the latter happening with relative paths, yet somehow relative domains are the default! Madness!
StephenFalken 14y ago
There are some interesting addresses that explore that property of Full Qualified Domain Names. For instance, try this on your browser: http://dk./ http://dk./ It would be curious if ICANN would define "The Internet entry address" as the root address of DNS: http://./ http://./
- TazeTSchnitzel 14y ago
  I recall that http://to./ http://to./ used to be the world's shortest URL shortener.
mrjaeger 14y ago
Is there any workaround on heroku for this? Just tried my HTTPS site and can confirm the trailing dot gives an warning.
adam-f 14y ago
curiously "slashdot.org." redirects to "slashdot.slashdot.org" curiouser and curiouser, "slashdot.slashdot.org." redirects to "slashdot.slashdot.slashdot.org" and so on... =)
aaron695 14y ago
Soooo does anyone have any reason to believe this matters in the wild? I like the article it's interesting though, but to me it seems purely theoretical.

182 points by nicolly 14y ago

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.

derefr 14y ago
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 FQDN is bob.example.com, going to "foo.com" can actually take you to "foo.com.example.com.", just like going to "foo" can take you to "foo.example.com." It's just that, conventionally, although it was always an option to use weird TLD-lookin' subdomain hierarchies within domains like that, nobody does it, because it's so confusing. I don't think much at all would break if we enforced a "if your non-rooted domain ends in a known TLD, canonicalize it to a rooted domain before comparison" rule in browsers, the OpenSSL and OpenSSH libraries, etc., and then require that going forward, all X.509 certs, CORS policies, and so forth which are meant to refer to an FQDN are issued only for the rooted version. [If you're curious, DNS zone records themselves are always already canonicalized into rooted form whenever you edit them through any sensible interface.]
- __david__ 14y ago
  > "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-multicastdns-15 https://tools.ietf.org/html/draft-cheshire-dnsext-multicastd...
  - derefr 14y ago
    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.
gingerlime 14y ago
It's a very good question. I particularly wonder if one can set "www.example.com" to point to a different address from "www.example.com." (globally, not via changing /etc/hosts or your local dns server...)? If they are practically equivalent, then I can't think of much security benefit from treating them differently. Even if changing the behaviour won't cause any security risk, I can't imagine this being a simple change to make. The SSL certificate contains a digital signature that is performed on a hash of many details, including the CN which is typically the FQDN (without the trailing dot). The `CN==requested-server-name?' matching can be performed at different layers and is probably deeply embedded within the specification and in different implementations. Add this to the practicality of needing to use both www.example.com and www.example.com. - it seems that the balance is in favour of keeping things simple and as the post suggested, use a redirect (or buying an extra certificate).
hkolk 14y ago
From the looks of it, Safari ignores the trailing dot when validating (as you can see when going to https://www.facebook.com./ https://www.facebook.com./ ). Curl on the other hand doesn't
- mfwoods 14y ago
  Firefox (nightly) and chromium don't ignore the trailing dot either and both display an invalid certificate error.
zmb_ 14y ago
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.

derefr 14y ago

D'oh. It would seem to me that for the purposes of X.509/CORS/server config/etc. equality, domains which seem to be rooted in any of the TLD registries should be canonicalized first to add the dot on both sides (along with doing the IRI -> URI conversion and so forth that should happen either way.) Is there any reason that would be a bad idea?

demetrius 14y ago

I use RequestPolicy to whitelist access to other domains' resources. Usually most sites that have CSS on external resources show up as black-and-white, which is perfectly readable. But this one is displayed as blue text on red background... WTF?

derefr 14y ago
It's something I see a lot over slow connections--more commonly, black text on a black background, where eventually a white "content-layer background" image will load behind the text, making it readable.

deleted 14y ago

[deleted]

raverbashing 14y ago

I wouldn't call it a 'danger' more like an 'annoyance', unless someone is MITM you with a certificate for the name ending in dot or something like that Maybe redirect, but I'd go for making it not work, period. (I don't mean 'broken', I mean blank page or forbidden)

pilif 14y ago

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.

joosters 14y ago
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.
- pilif 14y ago
  I thought so too, but then I made a little experiment: pilif@shion:~$ curl -I -H "Host: example.com" http://198.252.206.16/ HTTP/1.1 404 Not Found Content-Length: 4129 Date: Sat, 16 Mar 2013 12:28:22 GMT vs. pilif@shion:~$ curl -I -H "Host: example.com." http://198.252.206.16/ HTTP/1.1 400 Bad Request Content-Length: 334 Content-Type: text/html; charset=us-ascii Date: Sat, 16 Mar 2013 12:28:56 GMT The IP is the one from stackoverflow.com. When querying for a host they are not configured (try any), you will get a 404 plus an explanation page that the selected Q&A community doesn't exist. When you try the same host with a trailing dot, you get a generic IIS error 400. This is too much of a coincidence and I value it as a strong sign that my hypothesis might be correct. I have no IIS at my disposal to replicate paulbeattie's experiment, but the outcome he described further helps confirming my suspicion (no matter the downvotes he got) Same experiment works with microsoft.com too: pilif@shion:~$ curl -I -H "Host: example.com." http://65.55.57.27/ HTTP/1.1 400 Bad Request Content-Length: 334 Content-Type: text/html; charset=us-ascii Server: Microsoft-HTTPAPI/2.0 Date: Sat, 16 Mar 2013 12:35:10 GMT Connection: close pilif@shion:~$ curl -I -H "Host: example.com" http://65.55.57.27/ HTTP/1.1 200 OK Cache-Control: private Content-Length: 0 Server: Microsoft-IIS/8.0 (snip)
  - joosters 14y ago
    That's odd, I would have thought that '404 Not Found' would be the wrong response to send, although you could argue either way. I used to develop a web server ages ago (Zeus Web Server), it would try and match the Host: header against all the sites it was configured to server, and if none matched, it would send a 400 error back. (Incidentally, it would happily strip off the trailing dot from the hostname)

judofyr 14y ago

Also note that Chrome allows you to set document.domain = "" if you have the trailing dot so you could use it for cross-origin communication.

th0114nd 14y ago

Why is this something that people do?

pax 14y ago
Why, is this something that people do? no, I read it as a solution to a problem that doesn't occur. It's way worse if somebody would type a comma or any other letter at the end of the domain name, as I just learned, the dot is the best character to mistake at the end of a domain
- deleted 14y ago
  [deleted]
jvdh 14y ago
Because they can. Curiosity is a very strong and very valid reason to do things. It can very often lead to new insights. And of course it is also necessary from a security point of view to test these kinds of things to see if they lead to strange behaviour.

derleth 14y ago

http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-fully-qualified-domain-name.html 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/ 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./ 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.)

zimbatm 14y ago
The search path spoofing argument is weak. If you depend on a DNS resolver that spoofs domain searches, what guaranteed that it wouldn't simply spoof the full resolution as well ? In practice nobody uses the dot at the end except when writing BIND files.
- sp332 14y ago
  The DNS resolver doesn't need to spoof anything. If you're on network example.net and there's a server on that network called "google" then typing "google" into your address bar will resolve to google.example.net in a completely legitimate way, with no DNS spoofing.

hiddenfeatures 14y ago

Just tried it with my app on heroku and get an HTTP 404 "no such app" error. Tried to add www.mydomain.com. to the domain list in the admin interface. Didn't work either stating "Domain is invalid". Gna...

emddudley 14y ago
Use example.com in examples, since mydomain.com is an actual website.
- sp332 14y ago
  Or if you want to make it clear that it's your domain, mydomain.example or mydomain.test https://en.wikipedia.org/wiki/Top-level_domain#Reserved_domains https://en.wikipedia.org/wiki/Top-level_domain#Reserved_doma...
mmmmm 14y ago
You don't need to add the FQDN - heroku already supports it. E.g. http://www.leedsindustrialestate.co.uk./ http://www.leedsindustrialestate.co.uk./ is a Heroku hosted site.

dukekarthik 14y ago

The trailing dot (.) at the end of the domain name denotes the root nameservers. There are 13 such servers in the world. $ dig ns . ; <<>> DiG 9.8.1-P1 <<>> ns . ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38974 ;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 21088 IN NS a.root-servers.net. . 21088 IN NS b.root-servers.net. . 21088 IN NS c.root-servers.net. . 21088 IN NS d.root-servers.net. . 21088 IN NS e.root-servers.net. . 21088 IN NS f.root-servers.net. . 21088 IN NS g.root-servers.net. . 21088 IN NS h.root-servers.net. . 21088 IN NS i.root-servers.net. . 21088 IN NS j.root-servers.net. . 21088 IN NS k.root-servers.net. . 21088 IN NS l.root-servers.net. . 21088 IN NS m.root-servers.net. ;; Query time: 51 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Sat Mar 16 19:32:57 2013 ;; MSG SIZE rcvd: 228 This is very helpful in DNS propagation and pointing the appropriate authoritative zone for all the TLDs.

16s 14y ago
Every "web developer" should read the first three chapters of the Cricket book. The profound ignorance (that many web developers have) of DNS is inexcusable: http://www.amazon.com/DNS-BIND-5th-Cricket-Liu/dp/0596100574 http://www.amazon.com/DNS-BIND-5th-Cricket-Liu/dp/0596100574
jameshart 14y ago
The . doesn't indicate the root nameservers at all - it indicates that the DNS name to be resolved is an absolute name, not a relative name. All nameservers - root or otherwise - specify the names they know relative to the absolute global domain namespace root, ".". When resolving a hostname, your computer's DNS resolver will look for it in various 'search path' contexts, much like a shell looks for executables relative to all the directories in your PATH. Asking it to resolve news.ycombinator.com will lead to it looking for news.ycombinator.com., but also maybe trying various connection-specific DNS suffixes your network interfaces have configured, or global search suffixes. Commonly macs, for example, try resolving names within the domain 'directory' of "home." - http://mymacbookpro/ http://mymacbookpro/ will look for a machine called "mymacbookpro.home." as well as "mymacbookpro.home.". But http://mymacbookpro./ http://mymacbookpro./ is specifying the absolute path - the resolver won't look for mymacbookpro.home., only mymacbookpro. Conversely, if you type in http://news.ycombinator.com/ http://news.ycombinator.com/, it will look for a "news.ycombinator.com.home." as well as a "news.ycombinator.com.". Yes, you're right - that is an opening for a spoofing attack if you use a compromised or untrustworthy DNS service on your local network. The root nameservers are just one place your DNS resolver looks to to ask questions like "who is the authoritative DNS server for domain names in .com.?" once it's decided to look up a name like news.ycombinator.com..

16s 14y ago

You can cd to /home/user or /home/user/ as well. The dot's in DNS are equivalent to the slashes in your Unix file system. / is root . is root I'm shocked that many people on HN don't seem to understand this.

harshreality 14y ago
My shock is that some webservers don't remove an ending dot before trying to match a virtual host (any besides IIS?), and that web browsers don't assume equivalence, for website SSL cert CN purposes, between "fqdn." and "fqdn". I'm also shocked that chrome and firefox send a relative domain in Host: headers if that's what's typed into the url bar. Why wouldn't they send the fqdn? Is it specified this way in some RFC? What does this browser "feature" do other than require webservers in orgs with corpdomain.com search paths to add additional vhost aliases to ensure all the requests get to the right place? Switching vhosts to an intranet website based on the request's Host header does not provide any security in an intranet/dns-search-path setup.
- AnthonyMouse 14y ago
  It's because it makes the attacker's job easier. "fqdn." and "fqdn" are not the same thing. They may not resolve to the same machine. If one of them resolves to the attacker's machine, you certainly don't want them to be equivalent.
  - harshreality 14y ago
    They're not equivalent, but most or all major CAs issue certs without terminating dots, apparently. So I fail to see how distinguishing them during browser checks for cert validity accomplishes anything. If an attacker controls "fqdn.localsite.com." when the client's (Alice's) intended destination is "fqdn.", isn't the client fooled when Alice has a localsite.com dns search path, if the attacker (Mallory) manages to get a cert for "fqdn"? (Let's suppose Mallory has access to email for "hostmaster@fqdn." but can't get access to the actual "fqdn." webserver to do the attack that way; Mallory sets up "fqdn.localsite.com." to fool Alice's browser which is subject to a "localsite.com." search path.) If it's the reverse, where Mallory is external and controls "fqdn." and Alice is expecting to get to "fqdn.localsite.com." because of dns search rules, but the dns search rules are broken and Alice gets sent to "fqdn." instead, Mallory wins because the CA-issued cert for the "fqdn." site won't have the terminating dot, right?

TazeTSchnitzel 14y ago

Where have we got to the point where a relative hostname is accepted by 100% of websites yet an absolute hostname isn't? Surely it should be the other way round, this is a ridiculous state of affairs!

AnthonyMouse 14y ago
Up voted, because "forward example.com. to example.com" is exactly backwards. Think about what happens to the user who doesn't have 'example.com' (the relative hostname) resolve to the same address as 'example.com.' (the absolute hostname). Now they want to get to 'example.com.', they type 'example.com.' and they get forwarded to 'example.com', which resolves to example.com.localdomain.com according to their local DNS server. Oops.
- TazeTSchnitzel 14y ago
  It's like having everything rely on directories called "com" and "net", but when someone uses the correct, absolute path of "/com" or "/net" it somehow stops working. Nobody would stand for the latter happening with relative paths, yet somehow relative domains are the default! Madness!

StephenFalken 14y ago

There are some interesting addresses that explore that property of Full Qualified Domain Names. For instance, try this on your browser: http://dk./ http://dk./ It would be curious if ICANN would define "The Internet entry address" as the root address of DNS: http://./ http://./

TazeTSchnitzel 14y ago
I recall that http://to./ http://to./ used to be the world's shortest URL shortener.

mrjaeger 14y ago

Is there any workaround on heroku for this? Just tried my HTTPS site and can confirm the trailing dot gives an warning.

adam-f 14y ago

curiously "slashdot.org." redirects to "slashdot.slashdot.org" curiouser and curiouser, "slashdot.slashdot.org." redirects to "slashdot.slashdot.slashdot.org" and so on... =)

aaron695 14y ago

Soooo does anyone have any reason to believe this matters in the wild? I like the article it's interesting though, but to me it seems purely theoretical.