Only 2? Wouldn't you have to hit the root, then the tld server, then the name server for the domain, and if it isn't the root domain (example.net), but if it is a sub-domain (www.example.net) which could potentially return more NS records ... and the process would have to happen all over again.
That’d be no different with the CNAME alias technique, right?
I’m not seeing any reason for the CNAME technique; seems like the NS technique should be every bit as good, without needing another domain name (which costs money and is another moving part). I’d like to know if I’m misreading anything.
This is inaccurate. There's never been a reason to not assign an A record to @.
The historic structure of DNS is that names were given to systems within a domain. So you might have pikachu.company.com, squirtle.company.com, etc. It wouldn't make sense to just assign an address to the domain itself because we simply didn't have the technology to drive sophisticated consolidated sites on one system. You might need to get some files off one host, and some off another. We didn't have load balancers, and we often didn't have drive space to hold everything in one place.
MX doesn't have this problem of scale, as MX specifies multiple systems per SMTP spec.
Sometimes people would create www.pikachu.company.com, and sometimes they wouldn't. The www prefix was sometimes a handy default, but certainly wasn't ubiquitous.
The real change here is the rise of single endpoints for a domain. This began by assigning "www" as place to look for web content for the entire domain and almost in unison people began to also add A records to the domain itself. After all, why wouldn't we?
CNAME is different, of course, because CNAME aliases all record types - not just A records.
It is very poor practice to use CNAME for things like this. In the example above, mat-sts.his-domain will inherit any records of his-domain: A, AAAA, MX, and what not.
Since CNAME is not specific to A or AAAA records, a CNAME record on the root domain would also override your SOA and NS records, which is probably not what you want.
The problem though is that you can't put MX and CNAME records at the same point in the DNS hierarchy. So if you want to host a site on an ELB at acme.pagerduty.com, you can't then put in MX records for acme.pagerduty.com, because they'll conflict with the CNAME you need to put there.
This all happens because it creates ambiguity. If you want to look up the MX record of a name that has both MX and CNAME entries (say acme.pagerduty.com), should the name resolver:
a) Grab the MX record at acme.pagerduty.com; OR
b) Do what is usually implied by a CNAME record, and pull the target of acme.pagerduty.com, and search for an MX record at that name?
Because of the potential for conflict, the DNS spec simply forbids CNAME records from existing alongside most other records.
At this point, doesn't it make more sense to have fully arbitrary strings as domain names, and use something like the last 2 characters to map to the appropriate top level entity ?
The explosion of top-level domains doesn't seem to serve any real practical purpose except moving money around, and moving to a better system altogether would be the logical step.
For a new project it will probably not matter at all.
The thing with www though is, that you can use CNAMEs for aliasing on the DNS level. Technically you can use CNAMEs on domain root to alias the whole domain to another one, thus leading to you not being able to add other records (for example MX) to this domain, which you probably want to do.
Plus "DNS related code" can be stretched pretty far to "code that uses DNS." so it's the one I prefer.
The only thing I wish was easier was having a TLD for network local names but not link-local names. I typically just buy a name for that but it seems clunky since any in-use name that uses public DNS TLDs I feel ought to be DNS server independent.
Ok, so let's assume you are right. Did he make the wrong choice? The shorter name seems strictly better to me- whether we feel it is trivially better, it saves traffic and the domain name has lost no information.
If he reworked old code just to save 50 bytes, that would probably be a mistake, but it sounds like the work was being done anyway and he had the choice to save 50 bytes OR use a longer domain name.
> 1. Some hosts might want you to use a CNAME record to send them your web traffic, and CNAME records are undesirable for apex domain names because they can't coexist with other records you might need (like MX).
Nitpick: With the exception of RRSIGs, a CNAME record must be the only record at a given owner name. Since the apex of a zone has a SOA record, a CNAME cannot exist there.
Definitely simpler, and a good argument against using the root domain.
Thanks for clarifying!
reply