How come I can type, say, “foo.com” into my browser bar and get to www.foo.com but if I try it for “fark.com” the name doesn’t resolve and I have to type in the “www.” before it’ll work? Is this down to which DNS server I happen to be going through? How and where the domain name was registered? Celestial alignment? Browser type?
There’s nothing sacred about the “www” prefix, however, it is a very commonly used convention to denote http servers. You can have http servers without the prefix - you can call them anything you want, as long as you have foo.com in the domain registry.
The “www” prefix isn’t really a meaningless prefix in host name resolution. Simply put “host name resolution” means finding a computer on the internet to talk to. A host is an internet domain, again, some place on the internet. We have “top level domains” such as .org, .net, or .com. Whenever you type an address into your web browser or FTP program (let’s say www.mydomain.com), it consults a DNS server to see where it lives, what its IP address is. In theory it first consults a root DNS server to see where .com lives. The .com server finds out (“resolves”) the address for “mydomain” – “mydomain” is called the machine name, and is “your” machine and strictly speaking refers to your own DNS server. The “mydomain” server then does its own DNS search to see where “www” lives – www is a subdomain, of which you can have many. Again, in theory subdomains originally were separate IP addresses, but all types of local virtual DNS exist that allow you to have separate subdomains on a single IP address – Apache et al take care of the details. This gives a single domain – such as straightdope.com – to have .www, .boards, .ftp, and so on as subdomains.
Soooo… the reason some sites require the www subdomain instead of just the machine name is because they’re configured that way.
Correct me if I’m wrong, but the presence of “www” at the beginning of most web addresses is a convention that evolved about a decade ago, when the web was brand new, to distinguish web pages from, say, ftp sites, which were at that time much more common.
That’s correct. According to convention, a company would register a second-level domain name like mycompany.com and then set up separate addresses for “www” for HTTP, “mail” or “smpt” for SMTP, “ftp” for FTP, etc. These might or might not be set up on the same physical server, and they might or might not resolve to the same IP, but they would typically be set up according to this naming convention so no one had to guess where your public FTP server was or where your web server was. AFAIK, this was just a convention rather than a published standard or RFC, and there were plenty of hosts that ignored it for one reason or other.
In many cases the bare second-level domain name would be set up to automatically resolve to the correct server based on protocol. That means if you hit port 80 on mydomain.com, it redirects to www.mydomain.com. If you hit port 25, it redirects to smtp.mydomain.com, etc. for other standard protocol port addresses. Of course, if you set up all your services on one box, you can just call that box mydomain.com and the ports don’t even have to redirect.
www is the machine name, not a subdomain.
In the name www.cs.foo.edu, .edu is the top level domain, foo is the domain name, cs is the subdomain, and www is the host name. In www.foo.edu, there is no subdomain. Just a TLD, domain name, and host name.
Nope, that’s not the role of a registry. A registry only takes a second-level domain name and associates it with an authoritative DSN server(s). So when I need an IP for www.mydomain.com, I query the COM root server to get the authoritative DNS for the mydomain registration and then query that DNS server for the IP I need. Of course, in practice it’s a little more complicated because the DNS servers between mine and the root may cache results and my query may never have to go all the way up the tree, but that’s the gist.
Distinquishing between www.mydomain.com, ftp.mydomain.com, and t3.s2.g1.mydomain.com is the job of the local DNS and routing tables. The registrars aren’t going to keep track of that since they only care about the information needed to populate the root servers. Some registries which also provide hosting or domain forwarding may be providing the subdomain and machine-level routing functions too, but don’t confuse them with the actual registry tasks.