Minor error in this post: 'IN' doesn't refer to the answer's inclusion in the given DNS type -- it's a short form of Internet, and is meant to denote the address family being returned (the field is called 'CLASS' in DNS-speak). Other options include Hesiod and Chaos (as well as a number of reserved / private values)
Another very forgivable error is a mis-understanding about how recursive queries work. The article says
"dig randomly picked one of the root server responses, in this case f.root-servers.net., and asked it for the next part of the domain name in question, info. The info section of the hierarchy is run by a company that operates their own set of servers. dig asks one of these servers for the NS records for bugsplat.info and then finally asks one of those servers for the A record for empoknor.bugsplat.info.."
but in actuality every server in the hierarchy is queried for the full name; "empoknor.bugsplat.info". Technically even the root servers may be authoritative for that name, there's no way to know in advance where the zone-cuts are.
Correct, and very common misconception. While I applaud the author's attempts to simplify DNS, it's somewhat evident they've not looked at the very clearly written RFCs which cover both mistakes.
Sorry if I came off as condescending, it looked that way when I read it again. The rfcs are 1034 and 35 and are very interesting reads. 5321 is good too. For example, did you know that you don't need an mx record for email? If none is present, it will default to the a record. DNSSEC is in 4034, among others.
Also, I think maybe more explanation about the main benefit of CNAMES, a virtual host based setup where many domains point to the same IP.
https://www.iana.org/assignments/dns-parameters/dns-paramete...