Using DNAME to rename IP6.INT
isc-tn-2002-1

Abstract

Various political and technical pressures have recently led to the deprecation of the IP6.INT name space in favour of IP6.ARPA. This makes IPv6 PTR data management difficult, since interim clients will search IP6.INT while standard clients will search IP6.ARPA. We present a simple method based on DNAME RR's (see RFC2672) and ISC BIND9 whereby zone information can be managed in a single location and then made visible in two namespaces.

Legal Notice

This memo describes a methodology in use inside ISC which may be of use to other members of the Internet technical community. Distribution of this memo is unlimited, if full attribution is given.

Table of Contents

• 1. Introduction and Overview
• 2. Zone Data
• 3. Acknowledgements
• 4. Works Cited
• Author's Address

1. Introduction and Overview

The IETF recently decided (see [RFC3152])to restandardize IPv6 PTR RRs such that they will be found in the IP6.ARPA namespace rather than under the interim IP6.INT namespace.

Interim clients -- all IPv6 endstations to date -- will continue to search the IP6.INT namespace for PTRs when the getnameinfo() function (see RFC2553bis) is called to translate an IPv6 address into a hostname.

Network managers must make their PTR data reachable under both the interim (IP6.INT) and standard (IP6.ARPA) name spaces in order to serve the full community of IPv6 endstations in both the present and future.

A very simple solution to this is the use of DNAME RR's (see [RFC2672]) to effectively "tail-rename" portions of the interim (IP6.INT) namespace into the standard (IP6.ARPA) namespace.

This approach will work for any point in the namespace including the top level (.IP6.INT itself) or for the entire 6Bone (E.F.F.3.IP6.INT), as long as all authority servers for the PTR zone fully implement DNAME RR behaviour as specified in [RFC2672]. BIND9 is one such server implementation, available free of charge, and works in nearly all modern operating systems and platforms.

If some of the authority servers for a DNAME-containing IP6.INT zone comply with only the earlier DNS standards (e.g., [RFC1035] and [RFC2181], as supported by ISC BIND8), then they will not be able to load or serve zones which contain DNAME RR's and will be "lame" for those zones. This creates a minor performance problem but is not fatal.

If some of the authority servers for a DNAME-containing IP6.INT zone load the zone expecting to serve DNAME RR's opaquely, then they will give a NOERROR/ANCOUNT=0 or NXDOMAIN response when queried for an IP6.INT PTR RR. This will cause endstation address-to-hostname translations to fail outright, and is therefore fatal.

2. Zone Data

Here is the master file for 2001:04F8:/32's interim (IP6.INT) PTR zone.

  $ORIGIN 8.f.4.0.1.0.0.2.ip6.int.
  $TTL 2H
  @  SOA    ns-ext.vix.com. hostmaster.isc.org. (
		      2002082201      ; serial
		      8H              ; refresh
		      30M             ; retry
		      30D             ; expiry
		      1H )            ; minimum

     NS     ns-ext.vix.com.
     NS     ns.ripe.net.

     TXT    "$Revision: 1.5 $"

     DNAME  8.f.4.0.1.0.0.2.ip6.arpa.
                

In this example, there is a normal and valid SOA and two NS RR's, along with an optional RCS identifier (stored as a TXT RR), followed by a DNAME RR. Once deployed, this zone never needs to be edited unless the SOA or NS information changes.

The actual PTR data for 2001:04F8:/32 is under the standard (IP6.ARPA) zone as told on the right hand side of the DNAME RR's, an excerpt of which is:

  $ORIGIN 1.0.0.0.8.f.4.0.1.0.0.2.ip6.arpa.       ; Palo Alto
  $ORIGIN d.0.0.0                                 ; vlan pa-blue

  f.2.0.0.8.0.e.f.f.f.7.4.3.0.2.0  PTR  pa-blue.fwpaa.isc.org.
  8.f.b.4.0.0.e.f.f.f.7.4.3.0.2.0  PTR  pa-blue.fwpab.isc.org.
  e.7.0.b.3.c.e.f.f.f.b.2.0.0.a.0  PTR  isrv4.isc.org.
  a.7.7.e.7.0.e.f.f.f.8.f.0.0.2.0  PTR  phred.isc.org.
                

BIND9's configuration file would include two "zone" declarations:

  zone "8.f.4.0.1.0.0.2.ip6.arpa" {       // ARIN ISC6-1
	  type master;
	  file "pri/2001:04F8:";
  };

  zone "8.f.4.0.1.0.0.2.ip6.int" {        // ARIN ISC6-1 (.int)
	  type master;
	  file "pri/2001:04F8:.int";
  };
                

Note that the name given to the DNAME-containing file ends in ".int" in order to distinguish it as a metazone which hardly ever needs to be edited.

3. Acknowledgements

This idea originated with Mark Andrews.

4. Works Cited

Author's Address