DNAME - Redirection in the DNS
DNAME has had a somewhat chequered history by being associated with the ill-fated A6 RR, but is now happily restored to its full glory in the Pantheon of RRs. DNAME functionality is defined in RFC 6672 (which also updates RFC 3363) DNAME causes all labels BELOW its owner-name - or expressed another way, anything with labels to the left of the owner-name - to be re-directed to another name. It is a potentially confusing, yet powerful, RR that should be used with extreme care. It is CNAME like, but while CNAME provides a single substitution (or aliasing) at the owner (left-hand) name of the associated CNAME RR, DNAME provides substitution (or aliasing) at all levels below the owner-name associated with the DNAME RR. Text explanations are almost useless, instead see the examples below which, hopefully, make the DNAME RR functionality more evident. The DNAME is already a pretty difficult RR to understand and master, if it is used with a wildcard (*) it could easily create such a mess that not even your mother could fix it. RFC 6672 wisely advises (due to certain DNSSEC quirks) against wildcard use without, sadly, expressly forbidding it. But first, the generic format:
Format
owner-name ttl class DNAME redirection-name
us.example.com. IN DNAME example.net.
The DNAME substitutes all names below those appearing in the lefthand name (owner-name) with the redirection-name (or alias if you prefer). The substituted name is then used to find the next record. This new name, like the CNAME, can be satisfied from within the zone or it may lie outside the zone (out-of-bailiwick) in which case it may return a referral (if it points to a subdomain in the zone) or simply returns the name in which case the resolver (recursive name server) has to requery using this new name.
Since every name modified by a DNAME could also be expressed as a single CNAME the server will return both the DNAME RR and a synthesized CNAME version. Since all resolvers are CNAME aware (CNAME dates from the earliest years of DNS - somewhere around the time dinosaurs walked the earth) but not all resolvers are DNAME aware, all resolvers will find something they like (DNAME or CNAME or both even) in the response.
The following examples attempt to illustrate the use and power of DNAME:
DNAME Examples
Example 1 - Simple Out-of-Zone Redirection
Assume the company which owns example.com has been taken over by a company which owns the domain example.net. Further, assume that example.com used to provide a web site www.example.com and a public ftp site ftp.example.com and these will now be hosted under the example.net domain with names of www.example.example.net (for web site) and ftp.example.example.net (for ftp site). Additionally assume we will handle mail addresses of the form user@example.com at mail.example.net. There are two methods of doing this - multiple CNAME RRs or a DNAME RR at the zone apex.
First, the classic CNAME solution:
; zone fragment for example.com
; uses CNAME RRs to re-direct to new domain
$TTL 2d ; zone default = 2 days or 172800 seconds
$ORIGIN example.com.
; zone apex RRs
....
IN MX 10 mail.example.net. ; out of zone email
....
; normal zone RRs
www IN CNAME www.example.example.net. ;out of zone cname - normal usage
ftp IN CNAME ftp.example.example.net. ;out of zone cname - normal usage
Next, the alternative DNAME solution:
; zone fragment for example.com
; uses DNAME RR to re-direct to new domain
$TTL 2d ; zone default = 2 days or 172800 seconds
$ORIGIN example.com.
; zone apex RRs
....
IN DNAME example.example.net.
IN MX 10 mail.example.net. ; unchanged from CNAME solution
....
; www and ftp RRs (or any other) are not required since they are
; BELOW DNAME (which is at the apex)
; any normal zone RRs from this point are IGNORED
; due to the presence of the DNAME
; they can be left in the zone file (as in this example)
; or they could be deleted
www IN A 192.169.2.3
ftp IN A 192.169.2.4
In this example there are few RRs being redirected and thus the CNAME solution works prefectly well. However, in a zone with many hundreds of RRs the DNAME solution is far more efficient. In the DNAME solution the MX RR is still required (pointing to example.net) since the MX owner (left-hand) name (example.com.) is at the zone apex and is not below the DNAME RR (it's at the same name) and thus is not affected by the preceding DNAME RR. Note The server mail.example.net will handle mail from the example.com domain with email addresses of the form user@example.com - no manipulation of these email addresses will occur.
Again in the DNAME solution any RRs in the domain below the owner-name of the DNAME (for instance, www or ftp) will be, in the language of the RFC, 'occluded' which is a fancy way of saying 'will be ignored' so you do not even have to delete them - just leave them to wither on the vine so to speak as shown in the above example.
Example 2 - In-Zone Redirection
This example redirects all domain names from the subdomain us.example.com to the main domain at example.com. Why would anyone want to do that? No idea - but it does illustrate that DNAME can redirect to shorter names, perhaps more imaginative readers will discover a better example:
; zone fragment for example.com
; uses DNAME RR to re-direct to new in-zone name
$TTL 2d ; zone default = 2 days or 172800 seconds
$ORIGIN example.com.
; zone apex RRs
....
IN MX 10 mail.example.net.
....
; normal zone RRs
www IN A 192.168.1.2
ftp IN A 192.168.1.3
....
; first virtual subdomain
$ORIGIN us.example.com.
; could have been written as $ORIGIN us
; if that is clearer. Thought not.
@ IN DNAME example.com.
; or functionally identical
us.example.com. IN DNAME example.com.
; all RRs below this will be re-directed to the base domain
; thus www.us.example.com is re-directed to
; www.example.com
; next virtual subdomain
$ORIGIN uk.example.com.
; the following RRs are not covered by the scope
; of the DNAME and are treated normally
www IN A 192.168.2.3
....
This example shows that substitution may be to shorter names as well as longer ones (as in example 1) and that re-direction can occur in-zone as well as out-of-zone (as in example 1). Again, this could also be accomplished by multiple CNAME RRs. The next virtual subdomain in this example terminates the scope of the DNAME RR, all subsequent RRs will be handled normally.
Example 3 - DNAME Reverse Delegation
For reverse delegations of > /24 (for example /24 or /26 - sub Class C address blocks) the CNAME solution is the most efficient and understandable. For reverse map delegations of < /24 (for example /20 or /18 - sub Class B or Class A blocks) the DNAME RR provides the same delegated reverse map functionality while creating a significantly smaller and more flexible configuration.
For a Class C block (/24) you could have this rather pointless configuration, which simply redirects the whole zone to another named zone - in this case called 0/24.23.168.192.in-addr.arpa.
$ORIGIN 23.168.192.IN-ADDR.ARPA.
@ IN SOA ns1.isp.com. root.isp.com. (
2003080800 ; serial number
2h ; refresh
15m ; update retry
2w ; expiry
3h ; nx = nxdomain ttl
)
IN NS ns1.isp.com.
IN NS ns2.isp.com.
IN DNAME 0/24
; the above could have written as 0/24.23.168.192.in-addr.arpa.
; no other definitions required below this point
; and if present will be 'occluded' a.k.a ignored
Now assume we are implementing 192.168.0/20 for the whole of the block 192.168. This would take 16 blocks out of the base 192.168 with addresses starting at 192.168.0, 192.168.16, 192.168.32, 192.168.48, 192.168.64, 192.168.80, 192.168.96, 192.168.112, 192.168.128, 192.168.144, 192.168.160, 192.168.176, 192.168.192, 192.168.208, 192.168.224, 192.168.240. Using a CNAME solution would require a zone file with 64K CNAME RRs. Not small. In this case the power of DNAME asserts itself and we have a zone file that contains only 256 DNAME entries and looks like below:
$ORIGIN 168.192.IN-ADDR.ARPA.
; zone apex stuff for SOA and NS RRs
....
; NS RR(s) for zone 168.192.in-addr.arpa appear here
NS ns1.example.com.
NS ns1.example.com.
; delegation RRs appear at end of file for simplicity
0 DNAME 0.0/20
; alternative way of writing above
;0.168.192.in-addr.arpa DNAME 0.0/20.168.192.in-addr.arpa.
0 DNAME 0.0/20
1 DNAME 1.0/20
....
15 DNAME 15.0/20
; end of first block
16 DNAME 16.16/20
17 DNAME 17.16/20
....
31 DNAME 31.16/20
; end of block
32 DNAME 32.32/20
33 DNAME 33.32/20
....
47 DNAME 47.32/20
; end of block
48 DNAME 48.48/20
49 DNAME 49.48/20
....
63 DNAME 63.48/20
; end of block
64 DNAME 64.64/20
65 DNAME 65.64/20
....
79 DNAME 79.64/20
; end of block
80 DNAME 80.80/20
81 DNAME 81.80/20
....
95 DNAME 95.80/20
; end of block
96 DNAME 96.96/20
97 DNAME 97.96/20
....
111 DNAME 111.96/20
; end of block
112 DNAME 112.112/20
113 DNAME 113.112/20
....
127 DNAME 127.112/20
; end of block
128 DNAME 128.128/20
129 DNAME 129.128/20
....
143 DNAME 143.128/20
; end of block
144 DNAME 144.144/20
145 DNAME 145.144/20
....
159 DNAME 159.144/20
; end of block
160 DNAME 160.160/20
161 DNAME 161.160/20
....
175 DNAME 175.160/20
; end of block
176 DNAME 176.176/20
177 DNAME 177.176/20
....
191 DNAME 191.176/20
; end of block
192 DNAME 192.192/20
193 DNAME 193.192/20
....
207 DNAME 207.192/20
; end of block
208 DNAME 208.208/20
209 DNAME 209.208/20
....
223 DNAME 223.208/20
; end of block
224 DNAME 224.224/20
225 DNAME 225.224/20
....
239 DNAME 239.224/20
; end of block
240 DNAME 240.240/20
241 DNAME 241.240/20
....
255 DNAME 255.240/20
; end of last block
; define delegation NS RR(s)
; define point of delegation NS for all 16 blocks
....
; example delegation for 128/20
; note: this a private domain either one or two NS RR(s) required
; one is shown due to laziness and to illustrate the one NS point
128/20 NS someserver.example.com.
; points to server with zone 128/20.168.192.in-addr.arpa
; the server is out-of-zone so does not require any A/AAAA glue RR
....
; delegation for 192/20
....
Explanation: Assume we run the IP 192.168.193.57 against this file - the name used in the query will be 57.193.168.192.in-addr.arpa which is satisfied by:
193 DNAME 193.192/20
The output from this is a DNAME of 57.193.192/20.168.192.in-addr.arpa. (and a synthesized CNAME with the same name). This is then used to query the reverse zone of 192/20.168.192.in-addr.arpa. (see notes below) which will yield the correct PTR RR. The key point is that for the DNAME to be unique, and therefore not have excessive scope, the selection value (in this case 193) must appear in both the left and right-hand names.
Notes:
16 reverse files with zones names of 0/20.168.192.in-addr.arpa ..... 240/20.168.192.in-addr.arpa are required with delegation NS RR(s) in the main zone file - only 128/20 delegation is shown above for illustrative (and laziness) reasons.
The delegation zone could be named anything required but a crude convention of X/Y has been used to give a vague indication of file content (the character / is allowed by RFC 2181 but X-Y could be used if you are feeling either squeamish or in a risk-averse mood). X is the base IP address in the reverse map and Y is the prefix (slash) value. Thus, 128/20.168.192.in-addr.arpa. starts with the entry for 192.168.128.0 (and ends with 192.168.143.255) and we are extracting a /20 subnet. The first couple of lines of this file are shown for illustration:
$ORIGIN 128/20.168.192.IN-ADDR.ARPA.
; zone apex stuff for SOA and NS RRs
....
0.128 PTR fqdn.
1.128 PTR fqdn1.
....
255.143 PTR fqdn4096.
You can generate DNAME delegations using various /Prefixes using our IPv4 Reverse Zone Generator.
Example 4 - DNAME Network Renumbering
Preamble: To a very great extent NAT has avoided the problem of IPv4 network renumbering even though its primary motivation may have been to expand the IPv4 address pool. By using private (RFC 1918) IPv4 addresses in normal operation and embedding the global/routable IP addresses in a NAT gateway of some sort the user is isolated from network number changes (or at the very least only has to modify them in the NAT gateway). This is certainly true for residential users and many commercial users (with static IPv4s) have adopted the same architecture since the NAT-PAT gateway provides a useful firewall like function to isolate the network. The world is split between those who regard NAT as inherently evil, because it broke the End-to-End purity of the original Internet, and those who regard it as an Internet life saver and devil take the consequences. Throw into the mix NAT's anonymity, relatively simple configuration in conjunction with DHCP and the IPv4 End-to-End model was, essentially, dead.
IPv6 was supposed to change all this. A well structured (hierarchical) global address, tons of addresses (blade-of-grass level), fairly aggressive anti-NAT stance and a true era of End-to-End computing would re-emerge from the rubble of IPv4. The only problem was that in an end-to-end world if the service supplier (ISP) changed, every IPv6 address would change. This has serious implication for systems like DNS. So the concept of network renumbering entered the lexicon. The IPv6 A6 RR coupled with bit-labels and DNAME was originally proposed to do this. The A6 RR and bit-labels bit (ouch) the dust (RFC 3363 and RFC 6563) and the problem remains extant (fancy way of saying it is not yet solved).
IPv6 Addresses and DNAME
The simplest and most effective tool for those who use IPv6 stateful configuration is to use the DHCPv6's DDNS feature to enable forward and reverse mapping zone file updates. Network re-numbering is handled entirely by DHCPv6 configuration in both the forward and reverse domains. Clearly a new reverse map IPv6 zone file needs to be configured into DNS to reflect the new network number.
For IPv6 stateless configuration (SLAAC or SLAAC with stateless DHCP) the problem is more accute. There is currently no provision for updating either the forward or reverse zone files from the individual PC (partly due to the complexity of provisioning secure credentials for the use of either TSIG or SIG(0)). While it is relatively straightforward to discover the SLACC generated IPv6 address (its EUI-64 address being calculated from the MAC) it remains a manual process to update the forward and reverse maps. Additionally the anonymous IPv6 address feature of RFC 4941, if activated (the default is off), may make even the process of IPv6 address discovery time consuming.
Summary: The DNAME RR has no role to play in IPv6 forward mapping. This is because (unlike IPv4) the separators between address elements of IPv6 use ':' not a '.'. Thus, synthesizing an IPv6 address from its various addressing elements (routing prefix, subnet address, IID)using DNAME, necessary to simplify network renumbering, would not result in a valid IPv6 address using any sensible scheme (the DNAME can join elements but only using a '.' (dot)).
DNAME has no role to play in the routing prefix (which essentially means it has no role to play in network renumbering) this is because the landing zone file (the first zone file in the users delegation) in any reverse tree is the routing prefix (or some element of it).
DNAME does have a role (perhaps trivial depending on the configuration method) to play in reducing or shortening those impossibly long, human-unfriendly strings in the reverse map. Some possibilities are shown below - perhaps more imaginative readers can add more.
Scenario 1 - Stateful DHCPv6 tight range
Assume example.com (how predictable) has been gven a /48 allocation (or even a /64 allocation) with a routing prefix of 2001:db8:0 (or 2001:db8:0:0 if /64) and stateful DHCPv6 has been configured to use a dense set of addresses from 1 to say 256 (using only 8 bits or two nibbles to keep it simple) then the following files could be built:
; landing reverse zone file
$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
; normal NS RRs for zone
....
@ DNAME hosts.example.com.
; end of landing zone file
; reverse zone file
$ORIGIN hosts.example.com.
; normal NS RRs for zone
1.0 PTR mail.example.com.
2.0 PTR www.example.com
....
E.F PTR almost.example.com.
F.F PTR last.example.com.
; end of reverse zone file
The addressing is perfectly normal (even if it looks strange) so hosts.example.com could be updated normally by DDNS from stateful DHCPv6 simply by pointing to the normal landing zone file (0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. in this case). All this solution does is to get rid of the humongous IPv6 reverse map strings quickly by using DNAME substitution and means that the reverse file hosts.example.com never changes - the landing zone file will change with network renumbering but not hosts.example.com. How useful is that? Depends.
Scenario 2 - SLAAC Allocated IPs
Assume example.com (how predictable) has been gven a /48 allocation (or even a /64 allocation) with a routing prefix of 2001:db8:0 (or 2001:db8:0:0 if /64) and SLAAC configures the addresses. Recall that a EUI-64 (used by SLAAC) is created from the top 24 bits of the MAC (the manufactuers ID) plus x'FFFE then, assuming we have a limited number of vendor LAN cards, we could do the following:
; landing reverse zone file
$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
; normal NS RRs for zone
....
E.F.F.F.0.0.0.0.0.0 DNAME mfg1.example.com.
E.F.F.F.0.0.0.0.0.1 DNAME mfg2.example.com.
E.F.F.F.0.F.0.0.0.1 DNAME mfg3.example.com.
E.F.F.F.0.0.1.0.0.1 DNAME mfg4.example.com.
; end of landing zone file
; reverse zone file for manufacturer 4
$ORIGIN mfg4.example.com.
; normal NS RRs for zone
1.0.0.0.0.0 PTR mail.example.com.
2.0.0.0.0.0 PTR www.example.com
....
E.0.0.0.0.0 PTR almost.example.com.
F.F.A.C.E.1 PTR last.example.com.
; end of reverse zone file
In the above example a total of 4 reverse files would be needed mfg1.example.com, mfg2.example.com, mfg3.example.com and mfg4.example.com (only mfg4 is shown for illustration all the zone files would use the same format). The addressing is perfectly normal (even if it looks strange) so mfg1, mfg2, mfg3 and mfg4.example.com could be updated normally by DDNS from stateless (probably) DHCPv6 simply by pointing to the normal landing zone file (0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. in this case).
Again, this solution simply reduces the humongous IPv6 reverse map strings quickly by using DNAME substitution and means that the reverse files mfg1, mfg2, mfg3 and mfg4.example.com never change - the landing zone file will change with network renumbering but not the manufacturer based zone files. The same trick could be used with subnets (further up the IPv6 address tree). The solution needs a limited number of vendor IDs (manufacturers) to reduce the number of files involved and has some further merit in that by using the vendor name (rather than, say, mfg2) further information is added. Finally, if RFC 4941 anonimity procedures are being used (they generate pseudo random addresses based on the EUI-64) this solution is probably dead in the water.
Note: The landing zone file uses the DNAME as a form of delegation (strictly re-direction) and illustrates one of the DNAME's potential properties (or side-effects) - delegation without the need for an NS RR(s).
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
