Best practices for FQDN for standalone domain (is a two part domain.tld okay?)

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

Answer

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.