Internet Engineering Task Force                             Alain Durand
INTERNET-DRAFT                                          SUN Microsystems
Feb 21, 2003
Expires Aug 2, 2003



                Dynamic reverse DNS for IPv6
              <draft-durand-dnsop-dynreverse-00.txt>



Status of this memo


   This memo provides information to the Internet community.  It does
   not specify an Internet standard of any kind.  This memo is in full
   conformance with all provisions of Section 10 of RFC2026 [RFC2026].

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



Abstract

   This document describes a method to dynamically generate PTR records
   and corresponding A or AAAA records when the reverse path DNS tree is
   not populated.

   A special domain dynrev.arpa. is reserved for that purpose.


. Introduction

   In IPv4, the reverse path tree of the DNS under in-addr.arpa.
   although not perfectly maintained, is still mostly usable and its
   existence is important for a number of applications that relies on
   its existence and decent status.  Some applications performs some
   (very) weak security checks based on it. Mail relays relies on it for
   some anti-spams checks an some FTP server will not let you in unless
   your IP address resolve properly with a PTR record.

   IPv6 addresses being much longer (and cumbersome) than IPv4
   addresses, it is to fear that the reverse path tree under ip6.arpa.
   would not be as well maintained.  Also, tools like 6to4, Isatap and
   others have made creative use of the 128 bits of an IPv6 address to
   automatically embed an IPv4 address to enable seamless connection to
   the IPv6 Internet. However, no provision has been made to make sure
   the reverse path tree gets automatically updated as well for those
   new IPv6 addresses.  One step furter, RFC3041 describes a mechanism
   to basically use random bits in the bottom part of an IPv6 address to
   preserver anonymity. If those addresses are to resolve in the reverse
   path tree, it obviously has to be with anonymous data as well.
   Another point to note is that home customer ISPs in IPv4 have a
   current practice to pre-populate the reverse path tree with names
   automatically derived from the IP addresses. This practice is no
   longer possible in IPv6, where IP address allocation is not dense as
   it is the case in IPv4. The mere size of typical customer allocation
   (2^48 according to the recommendation of RFC3177) makes it
   impossible.

   Applications that check the existence of PTR records usually follow
   this by checking if the name pointed by the PTR resolve in a A (or
   AAAA for IPv6) that match the original IP address. Thus the forward
   path tree must also include the corresponding data.

   One simple approach of this problem is to simply declare the usage of
   the reverse path DNS as described above obsolete.  The author believe
   this is too strong an approach for now.

   Similarly, a completely different approach would be to deprecate the
   usage of DNS for the reverse tree altogether and replace it by
   something inspired from ICMP name-info messages. The author believes
   that this approached is an important departure from the current
   practise and thus not very realistic.  Also, there are some concerns
   about the the security implications of this method as any node could
   easily impersonate any name. This approach would fundamentally change
   the underlying assumption of "I trust what has been put in the DNS by
   the local administrators" to "I trust what has been configured on
   each machine I query directly".



. Dynamic record generation

   If static pre-population of the tree is not possible anymore and data
   still need to be returned to applications using getnameinfo(), the
   alternative is dynamic record generation.  This can be done is two
   places: in the DNS servers responsible for the allocated space (/64
   or /48) in the ip6.arpa. domain.  or in the DNS resolvers (either the
   sub resolver library or the recursive DNS server).

   2.1. On the resolver side.

   The resolver, either in the recursive DNS server or in the stub
   library could theoretically generate this data.

   In case DNSsec is in place, the recursive DNS server would have to
   pretend these records are authentic.

   If the synthesis is done in the stub-resolver library, no record
   needs to be actually generated, only the right information needs to
   be passed to getnameinfo() and getaddrinfo().  If the synthesis is
   done in the recursive DNS server, no modification is required to
   existing stub resolvers.


2.2. On the server side.

   PTR records could be generated automatically by the server
   responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
   prefixes or basically anything in between) when static data is not
   available.

   There could be impact on DNSsec as the zone or some parts of the zone
   may need to be resigned each time a DNS query is made for an
   unpopulated address. This can be seen as a DOS attack on a DNSsec
   zone, so server side synthesis is not recommended if DNSsec is
   deployed.



. Synthesis

   The algorithm is simple: Do the normal queries. If the query returns
   No such domain, replace this answer by the synthetized one if
   possible.

3.1. PTR synthesis

   The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
   where [X] is any valid DNS name.

   The fact that the synthetized PTR points to the dynrev.arpa. domain
   is an indication to the applications that this record has been
   dynamically generated.


3.2. A synthesis

   If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
   record for the string [X].dynrev.arpa. which value is d.c.b.a. with
   a,b,c & d being integer [0..255]


3.3. AAAA synthesis

   If [X] is in the form
   a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
   addr.arpa, one can synthetized a AAAA record for the string
   [X].dynrev.arpa. which value is
   FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
   a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.


3.4. Server side synthesis

   If synthesis is done on the server side, PTR could be set not to use
   the dynrev.arpa domain but the local domain name instead.  It culd be
   for instance dynrev.mydomain.com.

   Note also that server side synthesis is not incompatible with
   resolver side synthesis.



. IANA considerations

   The dynrev.arpa. domain is reserved for the purpose of this document.



. Security considerations

   Section 2. discusses the the interactions with DNSsec.



. Authors addresses

   Alain Durand
   SUN Microsystems, Inc
   17, Network Circle
   UMPK17-202
   Menlo Park, CA 94025
   USA
   Mail: Alain.Durand@sun.com