The danger of the trailing dot in the domain name

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.

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.

Stack overflow uses IIS??

> whether this might actually be a bug in IIS to overzealously validate the hostname.

Our two websites both redirect to the version without the dot, both running on IIS6 so it can indeed handle it.

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.

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.

Not the same thing, really, since domains are reversed compared to file paths. In domains, the root token is optional and assumed; like if 'home/user' meant the same thing as '/home/user'.

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

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

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

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.

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

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

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

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.

Use example.com in examples, since mydomain.com is an actual website.

You don't need to add the FQDN - heroku already supports it. E.g. http://www.leedsindustrialestate.co.uk./ is a Heroku hosted site.

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

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.

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.