mail us  |  mail this page

contact us
training  | 
tech stuff  | 

BIND 9 Support

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:

  1. 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.

  2. 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.

Pro DNS and BIND by Ron Aitchison

Contents

tech info
guides home
dns articles
intro
contents
1 objectives
big picture
2 concepts
3 reverse map
4 dns types
quickstart
5 install bind
6 samples
reference
7 named.conf
8 zone records
operations
9 howtos
10 tools
11 trouble
programming
12 bind api's
security
13 dns security
bits & bytes
15 messages
resources
notes & tips
registration FAQ
dns resources
dns rfcs
change log

Creative Commons License
This work is licensed under a Creative Commons License.

If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox

Search

web zytrax.com

Share

Icons made by Icomoon from www.flaticon.com is licensed by CC 3.0 BY
share page via facebook tweet this page

Page

email us Send to a friend feature print this page Display full width page Decrease font size Increase font size

Resources

Systems

FreeBSD
NetBSD
OpenBSD
DragonFlyBSD
Linux.org
Debian Linux

Software

LibreOffice
OpenOffice
Mozilla
GitHub
GNU-Free SW Foundation
get-dns

Organizations

Open Source Initiative
Creative Commons

Misc.

Ibiblio - Library
Open Book Project
Open Directory
Wikipedia

Site

CSS Technology SPF Record Conformant Domain
Copyright © 1994 - 2024 ZyTrax, Inc.
All rights reserved. Legal and Privacy
site by zytrax
hosted by javapipe.com
web-master at zytrax
Page modified: January 20 2022.