UNIX System Administration Handbook - Evi Nemeth [266]
CNAME records
CNAME records assign additional names to a host. These nicknames are commonly used either to associate a function with a host or to shorten a long hostname. The real name is sometimes called the canonical name (hence, “CNAME”).
Some examples:
ftp IN CNAME anchor
kb IN CNAME kibblesnbits
The format of a CNAME record is
nickname [ttl] IN CNAME hostname
When the DNS software encounters a CNAME record, it stops its query for the nickname and switches to the real name. If a host has a CNAME record, other records (A, MX, NS, etc.) for that host must refer to its real name, not its nickname. For example, the lines
colo-gw IN A 128.138.243.25
moogie IN CNAME colo-gw
www IN CNAME moogie
are OK. But assigning an address or mail priority (with an A or MX record) to either www or moogie in this example would be wrong.
CNAME records can nest eight deep in BIND. That is, a CNAME record can point to another CNAME, and that CNAME can point to a third CNAME, and so on, up to seven times; the eighth target must be the real A record.
Some sites use CNAME records in a weak attempt at load balancing. They map the public name of their web server to several different machines:
www IN CNAME web1
www IN CNAME web2
www IN CNAME web3
This use of CNAME records is nonstandard. In fact, it is illegal. An option in BIND 8 allowed you to use this against-the-spec mechanism. BIND 9 is pickier, so it’s really not a good idea to use multiple CNAMES. A better way to achieve the same result is to have multiple A records for the web server that point to different machines.
The CNAME hack
CNAMEs are also used to torture the existing semantics of DNS into supporting reverse zones for networks that are not subnetted on a byte boundary. Before CIDR addressing was commonplace, most subnet assignments were on byte boundaries or within the same organization, and the reverse delegations were easy to manage. For example, if the class B network 128.138 was subnetted into a set of class C-like networks, each subnet would make a tidy package for the in-addr.arpa domain. The reverse zone for the 243 subnet would be 243.138.128.in-addr.arpa.
See page 276 for more information about CIDR.
But what happens if the 243 subnet is further divided into, say, four pieces as a /26 network? If all four pieces are assigned to the same organization, there is actually no problem. The four subnets can still share a single file that contains all their PTR records. However, if the 243 subnet is assigned to an ISP that wants to delegate each /26 network to a different customer, a more complicated solution is necessary. The ISP must either maintain the reverse records on behalf of each client, or it must find a way to take the third octet of the IP address (243 in this case) and divide it into four different pieces that can be delegated independently.
When an administrative boundary falls in the middle of a byte, you have to be sneaky. You must also work closely with the domain above or below you. The trick is this: for each possible host address in the natural in-addr.arpa zone, add a CNAME that deflects the lookup to a zone controlled by the owner of the appropriate subnet. This scheme makes for messy zone files on the parent, but it does let you delegate authority to the actual users of each subnet.
Here is the scheme in gory detail. The parent organization (in our case, the ISP) creates CNAME records for each possible IP address with an extra fake component (dot-separated chunk) that represents the subnet. For example, in the /26 scenario just described, the first quarter of the addresses would have a “0-63” component, the second quarter would have a “64-127” component, and so on. Here’s what it looks