4

I've searched quite a bit and can't seem to find a straight, modern answer on this.

If I am hosting a domain, say, mydomain.com, on a machine which is going to solely be used for that domain, and there are no subdomains, is there a real, practical reason besides compliance to create an arbitrary hostname (i.e. myhost) just in order to have a three-part FQDN (myhost.mydomain.com) to satisfy some sort of RFC or convention that's expected.

This seems to make a lot of undue complexities from my perspective, and I'm not sure if there's an advantage to this or if it's just a hold-over from a time where all web resources came from a subdomains such as www and ftp which may need to scale to separate machines.

I don't use www on my domain, either, which is ill-advised for all I know from an administrators perspective (though removing it is the norm from a designer's perspective)...

birchbark
  • 43
  • 1
  • 3

2 Answers2

8

You should never give your server a name containing only the naked domain name.

The primary reason is that many services use the hostname internally, and may presume that the server is named separately from the domain name.

Among other things, this can cause email to not be delivered. It can also cause more subtle breakage, from programs which think your domain is com because you have named the machine example.com. A complete list of the things that could break is probably not possible.

As long as you have only a single server that you're raising as a pet, you can probably work around the problems this will cause. But when you expand (you either will expand, or you'll go out of business) then you're eventually going to start raising livestock, and at that point you're going to have to shoot your pet.

I always recommend keeping good habits and practices even when you don't strictly need to, since when you do need them later, they will already be ingrained.

Community
  • 1
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • Thank you! This is the only answer that gives an actual *reason* for the best-practice that I've heard recommended (with varying emphasis) on so many websites. In my case, it's a personal static website so I wont be expanding in the future -- but in either case, I understand that nothing but bugs can be gained by violating this particular assumption. – birchbark May 30 '14 at 17:41
0

You don't have to create subdomains if you don't want to. It's very common practice to have www point to @ so that if an internet browser is directed to either www.domain.com or domain.com, they'll end up at your front page regardless.

The reason people create subdomains is because they do other things besides just www, such as ftp.domain.com and owa.domain.com and development.domain.com, etc.

If you want to talk about the complications that would be introduced with this if you were using Active Directory, a split-horizon DNS zone and an internal network, that's a completely different story. But you're not.

Edit: Michael Hampton's answer is way better than mine.

Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • 1
    He's talking about _naming the server_, not DNS. I think. – Michael Hampton May 30 '14 at 14:11
  • Ok, well you could name your machine `mydomain` if you really wanted to, but it's an awful idea if you ever plan on scaling out, at all, so almost no one ever really does that. – Ryan Ries May 30 '14 at 14:16
  • Yes, I was talking about the server's hostname. I've used a cname for www to @ for many years and rewrite urls to drop the www -- no problems there for my purposes. I was setting up an MTA for the first time and had to create a FQDN and was feeling rebellious about this but Michael Hampton's answer has prevented my secession from the union of good sense. – birchbark May 30 '14 at 17:46