For example, with Active Directory, the DNS A record for your foo.com domain must resolve to your domain controllers. Your www.foo.com will resolve to a separate non-domain controller web server.
I think a lot of the commenters here are thinking solely in terms of commercial web services such as twitter.com and such, but there's so much more to the wider landscape.
Thinking about it that way gives me conflicted feelings. Much as I hate what Google has done here I also feel like any organization stupid enough to use their public domain name for their Active Directory domain name deserves every little pain they receive for it.
You lack the compassion that comes with experience.
My $dayjob has our AD root domain the same as our public root domain. Because we implemented AD in the year 2000, and this was Microsoft’s recommendation for domain naming way back then.
And if you use Exchange, you can’t rename your AD domain, you have to rebuild your forest and migrate piecemeal. So we’re stuck with it.
The practice of using Corp.example.com did not evolve until many years after Windows 2000 and Exchange 2000 were in the wild.
So we run http redirectors on each of our domain controllers to send traffic to www.
This one is kind of a "religious" topic for me, I guess. I'm sorry that it is, but it makes me exceedingly defensive.
I trained on Active Directory (AD) with a group of veteran sysadmins in 1999. I don't have access to the "Microsoft Official Curriculum" book from my class in '99 (long-since thrown away), but I have a distinct memory of a lively conversation in class re: the pitfalls of using a public domain name as an AD domain name (or, worse yet, a Forest Root domain name) during the class. It was very evident to our group of veteran sysadmins that using a public domain name in AD would create silly make-work scenarios (like installing IIS on every DC just to run redirect visitors to "www.example.com"-- just as you describe, albeit IIS didn't natively support sending redirects at the time).
I'd go further and suggest that anybody with a modicum of familiarity with DNS knows having multiple roots-of-authority for a single domain name is a bad idea. Microsoft not supporting split-horizon in their DNS server (like BIND does with 'views') compounded the difficulties with such a scenario in an all-Windows environment.
I certainly wouldn't argue that Microsoft has given exclusively good recommendations for AD domain names in the past (evidence ".local" in Windows Small Business Server), but I am reasonably certain that their documentation always suggested that using a subdomain of a public domain name was a supported and workable option.
I started deploying AD in 2000. I've deployed roughly 50 forests in different enterprises, and I've never used a public domain name as an AD domain name. I've domain-renamed all my subsequently-acquired Customers for whom it was an option (which it was, so long as they had not yet installed Exchange 2007), and have been rebuilding the Forests of Customers who made the wrong decision in the past, where it makes economical sense.
Windows 2000 didn't support stub zones, however. At the time that Active Directory was new there wasn't a good way to do split-horizon DNS with the Windows DNS server.
As an aside: I really enjoy your writing about using SRV lookups. It makes me sad that SRV records aren't being as much as they could / should be.
I don’t know anything about AD, so this might be a stupid question: can you not just run a web server on the same host as the AD server or port forward all HTTP traffic to a different server?
A domain controller on the internal network might not be the right place to run a copy of the public-facing content HTTP server (which might be in a datacentre, or even managed and run by an outside party, and might not be served by IIS). Then there are considerations of firewalling rules, browser rules, anti-virus rules, and even DNS rules for machines on the internal network that access a public WWW site that DNS lookups map into non-public IP addresses. (To prevent certain forms of external attacks, system administrators have taken in recent years to preventing this very scenario from working by filtering DNS results.)
Having a disjoint DNS namespace (and the needless make-work that it creates) is the issue, more than running HTTP servers on all your DCs to do redirects. There is absolutely no practical advantage to running an Active Directory domain with a public DNS name. It's all downside. It has always been all downside, and anybody who had any experience with DNS could see that all the way back in the beta and RC releases of the product in 1999 and 2000.
http://pool.ntp.org/ takes me to an "It works!" default Apache 2 page for an Ubuntu installation. As the comment in the issue describes, http://pool.ntp.org/ takes you to a random ntp server.
If you want another example, try google.com using Google's own DNS:
>http://pool.ntp.org/ takes me to an "It works!" default Apache 2 page for an Ubuntu installation. As the comment in the issue describes, http://pool.ntp.org/ takes you to a random ntp server.
Either way, the ask was for a difference in www.example.com vs example.com. Not a difference in www.pool.example.com vs pool.example.com. In the latter case, the different subdomains will still be shown (AFAIK).
>Even if you ultimately end up at the same site through redirects, you're clearly not going to the same site initially.
Which is nothing that an end user is going to care about and doesn't provide an example to the asked question.
That is absolutely insane and someone should be fired and shamed for this. I didn't like just trimming a pure www. but trimming any www. in the hostname is just dumb behaviour.
How would I differentiate between loadbalancer1.www.intranet and loadbalancer1.intranet? THOSE ARE NOT THE SAME.
That's exactly right. www.pool.ntp.org is the project site. pool.ntp.org is for getting an NTP server. Which one you get will depend on your location and random chance. That server will run NTP, but what it happens to run on port 80, if anything, is up to the operator of the server.
A) Consider any sharing platforms where unrelated bodies coexist with distinct subdomains under a common root domain (e.g., Blogspot, Tumbler, etc) While "www" is probably a reserved name and mostly not of practical concern, "m" may be a practical issue.
B) Consider subdomains for test-purpose like "www.test.www.example.com" (now displayed as "test.example.com", which is actually not even the root of the specific subdomain).
C) Users unsure, if they are on the full-featured or a reduced mobile site, when "m" is hidden.
D) I may actually want to have a service agnostic default host at the root and subdomains for dedicated servers (like "www", "ftp", "mail", "stun", "voip", etc). Maybe this one just returns a short text message by design, if accessed on port 80. Not every domain is just about the WWW. (Edit: While we may assume that such a server would forward in practice, this may be assuming too much.)
>> there's a difference between "www.example.com" and "example.com"
> Can you link to a site where these two are different?
There are 3rd level domains where everyone can register "www.{TLD}". E.g., .com.kg, .net.kg, .org.kg. Look at the www.com.kg. It's also available as www.www.com.kg. Or www.org.kg that's in fact www.www.org.kg. If you display just the last part (com.kg, org.kg), does that mean that you're viewing the root website? Nope, that doesn't. That means that chrome is fucked up.
Someone mentioned www.citibank.com.sg vs citibank.com.sg in the issue.
One of my school's websites: I can't remember what it was and this was before I understood what the difference is, but www worked much better than without iirc.
This also applies to m.*, so literally any web-app with a mobile version.
I don't remember the site offhand, but I was going to one recently where example.com didn't even work, it was some weird error page -- you had to use www.example.com. If it comes to me, I'll post it.
Not really fixing it thou because they just strip the www part from the name. If the developer does not setup www.domain.com and the user goes there chrome will not “fix” anything.
I haven’t tested it but it will most likely show up as domain.com in the address bar and will result in an error show to the customer.
If chrome wants to strip www as it’s essentially the same domain.com they can submit an RFC and not just decide for everyone. Honestly I hope they start making more stupid decisions like this so ppl move to Firefox so we have more competition.
> If the developer does not setup www.domain.com and the user goes there chrome will not “fix” anything
Yup, that's on the developers. Hopefully this fix will make it so that it will be easier to setup DNS with just one domain instead of 2. Props to Chrome.
Can you link to a site where these two are different?