
The danger of the trailing dot in the domain name - nicolly
http://saynt2day.blogspot.ru/2013/03/danger-of-trailing-dot-in-domain-name.html
======
pilif
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.

~~~
kostya-kow
Stack overflow uses IIS??

~~~
martinced
Yes and it really showed in the beginning: they had lots of issues and you
could constantly see the cat saying _"sorry, i am wurkin' on fixin' yer
problem"_ (don't remember the exact msg but it was a lolzcat message).

SO is also hardly something impressive from a UI point of view: it is a very
simple UI really not doing much. Usenet readers from 20 years ago were way
more capable than SO...

~~~
heartbreak
What does IIS have to do with the UI, exactly? It's just a web server.

~~~
pmorici
The site's UI is simple and yet the server still can't handle it perhaps was
the implication.

~~~
ams6110
I'm not seeing a direct connection between UI simplicity and server
capability. I can serve a hideously complex UI with a very minimal demand on
the server. Demand on the server is much more about actual traffic, not the UI
being rendered in the browser.

------
TazeTSchnitzel
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
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
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!

------
16s
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
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
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
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?

~~~
AnthonyMouse
>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.

Then you're probably still in trouble either way. But suppose the key for the
actual cert for "fqdn." was generated with a bad random number generator like
what happened with Debian a while back, or the attacker at one point broke
into the webserver for "fqdn." and copied the private key and has since been
locked but without revoking the compromised certificate, or it was revoked but
the client isn't checking CRLs. Now the fact that you used "fqdn." and not
"fqdn" in your cert saves you from Mallory's attack using
"fqdn.localsite.com".

>They're not equivalent, but most or all major CAs issue certs without
terminating dots, apparently.

The CAs will issue a cert for whatever you ask them to issue it for. The issue
is that people ask them for certs without the trailing dot.

The real trouble is that we've basically trained the whole world to type
"example.com" and not "example.com." and then when it comes to HTTPS, if you
type " <https://example.com> " then the cert has to have "example.com" at
least in addition to if not instead of "example.com." or it isn't going to
work. But that's no excuse for not allowing the distinction in cases where it
can be made, e.g. for subdomains that serve cookies but are never typed by the
user, so that the cert for those can contain only the dot-terminated name and
the attacker then has a harder time impersonating the subdomain to pilfer the
cookie.

~~~
harshreality
SSL libraries seem to treat CNs as fully-qualified, even without the dot. Do
we really want a global ssl PKI where non-fqdn CNs are allowed? If not, why
should anyone care about trailing dots for ssl cert validation purposes?

~~~
AnthonyMouse
>Do we really want a global ssl PKI where non-fqdn CNs are allowed?

It might not have been a bad idea to prohibit it twenty years ago, but at this
point it seems unlikely because everybody expects the contrary.

> If not, why should anyone care about trailing dots for ssl cert validation
> purposes?

Because if the cert has the dot and the address the client is connecting to
doesn't, you may not be connected to the right machine.

If I was writing a piece of client software, what I would do sooner than just
allowing them to be considered identical is to do a name lookup for
"example.com." if that's what's in the cert presented by "example.com" and
make sure the IP address is identical to the one for the "example.com" I'm
connected to, and then be OK if they are and fail validation if they aren't.

------
judofyr
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.

------
__david__
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
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__
> "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...](https://tools.ietf.org/html/draft-cheshire-dnsext-
multicastdns-15)

~~~
derefr
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.

------
dukekarthik
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.

~~~
jameshart
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/> will look for a machine called
"mymacbookpro.home." as well as "mymacbookpro.home.". But
<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/>, 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..

------
derefr
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?

------
StephenFalken
There are some interesting addresses that explore that property of Full
Qualified Domain Names. For instance, try this on your browser:

<http://dk./>

It would be curious if ICANN would define "The Internet entry address" as the
root address of DNS:

<http://./>

~~~
TazeTSchnitzel
I recall that <http://to./> used to be the world's shortest URL shortener.

------
raverbashing
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)

------
demetrius
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
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.

------
hiddenfeatures
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
Use example.com in examples, since mydomain.com is an actual website.

~~~
sp332
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_doma...](https://en.wikipedia.org/wiki/Top-
level_domain#Reserved_domains)

------
aaron695
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.

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

------
th0114nd
Why is this something that people do?

~~~
pax
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

------
adam-f
curiously "slashdot.org." redirects to "slashdot.slashdot.org"

curiouser and curiouser, "slashdot.slashdot.org." redirects to
"slashdot.slashdot.slashdot.org"

and so on... =)

------
derleth
[http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web...](http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-
fully-qualified-domain-name.html)

> [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.)

~~~
zimbatm
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.

~~~
AnthonyMouse
>If you depend on a DNS resolver that spoofs domain searches, what guaranteed
that it wouldn't simply spoof the full resolution as well ?

A lot of DHCP servers do DDNS. That allows you to change your computername and
get your computer registered in the local DNS as whatever-you-want followed by
the local domain which is usually in the search domains list. You can't get
registered as "google.com" but you can get registered as
"google.com.example.com" when "example.com" is in the search domain, and now
you're "google.com" (but not "google.com.") to everybody on the local network.

~~~
zimbatm
Yeah agreed but what's the most likely outcome. You rewriting your urls or you
fixing your network / kicking the offending user ? You're not only impacting
browsing experience but also all the scripts that are trying to connect to the
domain like your google drive sync agent.

~~~
AnthonyMouse
>Yeah agreed but what's the most likely outcome. You rewriting your urls or
you fixing your network / kicking the offending user ?

Who is "you"? The person who can fix the URLs is rarely the same person who
can kick the offending user off the local network. If the latter person is not
doing their job (or is about to but hasn't yet), you're still better off
fixing your URLs.

>You're not only impacting browsing experience but also all the scripts that
are trying to connect to the domain like your google drive sync agent.

You don't have to break the old stuff, just start using the final dot for new
stuff.

