UNIX System Administration Handbook - Evi Nemeth [267]
$ORIGIN 243.138.128.in-addr.arpa.
1 IN CNAME 1.0-63
2 IN CNAME 2.0-63
...
63 IN CNAME 63.0-63
64 IN CNAME 64.64-127
65 IN CNAME 65.64-127
...
To delegate the 0-63 piece of the reverse zone to the customer that has been assigned that subnet, we’d add the following NS records:
0-63 IN NS ns1.customer1.com.
0-63 IN NS ns2.customer1.com.
...
customer1.com’s site would have a zone file that contained the reverse mappings for the 0-63.243.138.128.in-addr.arpa zone. For example:
1 IN PTR host1.customer1.com.
2 IN PTR host2.customer1.com.
...
By adding this extra component, we create a new “cut” at which to perform delegation. When someone looks up the reverse mapping for 128.138.243.1, for example, the CNAME record at 1.243.138.128.in-addr.arpa refocuses their search to the name 1.0-63.243.138.128.in-addr.arpa, and that name is controlled by the customer.
The customer’s files are clean; it’s only the ISP that must deal with an inelegant configuration mess. But things can get even more complicated. Customer1 could itself be an ISP that wants to further subdivide its addresses. But that’s OK: BIND supports CNAME chains up to 8 links long, and since a byte has only eight bits, we can never run out. CNAME chains are discouraged but not forbidden in the RFCs; they do slow down name resolution since each link in a CNAME chain causes the link to be followed and a new query for the target to be initiated.
This whole scheme is a blatant misuse of the CNAME record, but it’s so powerful and useful that a variant of it has become the official standard for the handling of IPv6 reverse zones. See the information about DNAME records on page 451 for more information.
Very early in the life of the CNAME hack, the $GENERATE command (see page 453) was added to named’s repertoire to facilitate the creation of resource records in the parent zone. For example, to produce the records for the first subnet, the following lines suffice:
$ORIGIN 243.138.128.in-addr.arpa.
$GENERATE 0-63 $ CNAME $.0-63
0-63 NS ns1.customer1.com.
0-63 NS ns2.customer1.com.
The $ in the $GENERATE command iterates from 0 to 63 and creates 64 different CNAME records. The other three /26 networks would be handled similarly.
The CNAME hack works fine for BIND 8 and 9. Some older BIND 4 resolvers don’t expect to get a CNAME when they query for a PTR record, so they fail. Yet another good reason to upgrade, perhaps.
LOC records
A LOC record describes the geographic location and, optionally, the physical size (diameter) of a DNS object. LOC records currently have no effect on the technical operation of the Internet, and no standard software looks for them. However, a number of interesting potential uses for the information have been suggested, including route tracing and optimization, automated mapping, and network research.
LOC records are defined in RFC1819.
The format is:
name [ttl] IN LOC lat lon [alt [size [hp [vp]]]]
The latitude and longitude are given as space-separated degrees, minutes, and seconds followed by N, S, E, or W. Seconds can be omitted; if they are, minutes can also be omitted.
The other fields are all specified in centimeters (no suffix) or meters (m). alt is the object’s altitude, size is the diameter of the object’s bounding sphere, hp is the horizontal precision of the measurement, and vp is the vertical precision. The default size is one meter, and the default horizontal and vertical precisions are 10 meters and 10 kilometers, respectively.
Here is an example for caida.org in San Diego, California:
caida.org. IN LOC 32 53 01 N 117 14 25 W 107m 30m 18m 15m
Many of the graphical visualization tools written by CAIDA (the Cooperative Association for Internet Data Analysis) require latitude and longitude data, and sites are encouraged to include it in their DNS. However, if you are paranoid and run a high-visibility server or ISP, you may not want the general public to know the exact location of your machines. In such situations, we recommend that you use inexact values. They are still