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

51–60 of 75 posts

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

#51

Post by Cushman »

TazeTSchnitzel wrote: post #49
Cushman wrote: post #47

Earlier quoted context omitted.

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, reverse the path then. "news.ycombinator.com." is equivalent to "/com/ycombinator/news", but more commonly we use "news.ycombinator.com", equivalent to "com/ycombinator/news". The root token is not optional and assumed at all. Instead, there are multiple "search paths", like with binaries on *nix and Windows/DOS. Now, usually, it will check "." ("/") somewhere along the way, but people often have intranet domai…

That's what the spec says. In practice, no one uses fully-qualified domains, and users who generally do not even know they exist rightly assume any domain name ending in a TLD should take them to the site indicated by that root, and it's surprising and confusing if it does not.

Which is why it's pretty different from relative vs. absolute paths, which is a much-used and generally well-understood distinction.

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

#52

Post by TazeTSchnitzel »

Cushman wrote: post #51
TazeTSchnitzel wrote: post #49

Earlier quoted context omitted.

Well, reverse the path then. "news.ycombinator.com." is equivalent to "/com/ycombinator/news", but more commonly we use "news.ycombinator.com", equivalent to "com/ycombinator/news". The root token is not optional and assumed at all. Instead, there are multiple "search paths", like with binaries on *nix and Windows/DOS. Now, usually, it will check "." ("/") somewhere along the way, but people often have intranet domai…

That's what the spec says. In practice, no one uses fully-qualified domains, and users who generally do not even know they exist rightly assume any domain name ending in a TLD should take them to the site indicated by that root, and it's surprising and confusing if it does not. Which is why it's pretty different from relative vs. absolute paths, which is a much-used and generally well-understood distinction.

This is really going to blow up with the new gTLDs though, there is so much more room for conflict between root DNS and local DNS with so many more TLDs.

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

#53

Post by TazeTSchnitzel »

harshreality wrote: post #43
16s wrote: post #37

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.

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

They shouldn't assume equivalence. What should happen is SSl certificates should have both fully-qualified and non-fully-qualified hostnames in them, not just the latter.

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

#54

Post by AnthonyMouse »

zimbatm wrote: post #21
derleth wrote: post #19

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 t…

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.

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

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

#55

Post by jameshart »

dukekarthik wrote: post #35

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 ;; 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-server…

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

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

#56

Post by harshreality »

AnthonyMouse wrote: post #50
harshreality wrote: post #43

Earlier quoted context omitted.

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

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.

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?

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

#57

Post by Cushman »

TazeTSchnitzel wrote: post #52
Cushman wrote: post #51

Earlier quoted context omitted.

That's what the spec says. In practice, no one uses fully-qualified domains, and users who generally do not even know they exist rightly assume any domain name ending in a TLD should take them to the site indicated by that root, and it's surprising and confusing if it does not. Which is why it's pretty different from relative vs. absolute paths, which is a much-used and generally well-understood distinction.

This is really going to blow up with the new gTLDs though, there is so much more room for conflict between root DNS and local DNS with so many more TLDs.

Not the only problem gTLDs are going to cause, either. I'm still hoping they pull the plug on the whole concept.

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

#58

Post by TazeTSchnitzel »

StephenFalken wrote: post #41

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

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