contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt

   1 Internet Engineering Task Force                             Alain Durand
   2 INTERNET-DRAFT                                          SUN Microsystems
   3 Feb 21, 2003
   4 Expires Aug 2, 2003
   5
   6
   7
   8                 Dynamic reverse DNS for IPv6
   9               <draft-durand-dnsop-dynreverse-00.txt>
  10
  11
  12
  13 Status of this memo
  14
  15
  16    This memo provides information to the Internet community.  It does
  17    not specify an Internet standard of any kind.  This memo is in full
  18    conformance with all provisions of Section 10 of RFC2026 [RFC2026].
  19
  20    The list of current Internet-Drafts can be accessed at
  21    http://www.ietf.org/ietf/1id-abstracts.txt
  22    The list of Internet-Draft Shadow Directories can be accessed at
  23    http://www.ietf.org/shadow.html.
  24
  25
  26
  27 Abstract
  28
  29    This document describes a method to dynamically generate PTR records
  30    and corresponding A or AAAA records when the reverse path DNS tree is
  31    not populated.
  32
  33    A special domain dynrev.arpa. is reserved for that purpose.
  34
  35
  36 1. Introduction
  37
  38    In IPv4, the reverse path tree of the DNS under in-addr.arpa.
  39    although not perfectly maintained, is still mostly usable and its
  40    existence is important for a number of applications that relies on
  41    its existence and decent status.  Some applications performs some
  42    (very) weak security checks based on it. Mail relays relies on it for
  43    some anti-spams checks an some FTP server will not let you in unless
  44    your IP address resolve properly with a PTR record.
  45
  46    IPv6 addresses being much longer (and cumbersome) than IPv4
  47    addresses, it is to fear that the reverse path tree under ip6.arpa.
  48    would not be as well maintained.  Also, tools like 6to4, Isatap and
  49    others have made creative use of the 128 bits of an IPv6 address to
  50    automatically embed an IPv4 address to enable seamless connection to
  51    the IPv6 Internet. However, no provision has been made to make sure
  52    the reverse path tree gets automatically updated as well for those
  53    new IPv6 addresses.  One step furter, RFC3041 describes a mechanism
  54    to basically use random bits in the bottom part of an IPv6 address to
  55    preserver anonymity. If those addresses are to resolve in the reverse
  56    path tree, it obviously has to be with anonymous data as well.
  57    Another point to note is that home customer ISPs in IPv4 have a
  58    current practice to pre-populate the reverse path tree with names
  59    automatically derived from the IP addresses. This practice is no
  60    longer possible in IPv6, where IP address allocation is not dense as
  61    it is the case in IPv4. The mere size of typical customer allocation
  62    (2^48 according to the recommendation of RFC3177) makes it
  63    impossible.
  64
  65    Applications that check the existence of PTR records usually follow
  66    this by checking if the name pointed by the PTR resolve in a A (or
  67    AAAA for IPv6) that match the original IP address. Thus the forward
  68    path tree must also include the corresponding data.
  69
  70    One simple approach of this problem is to simply declare the usage of
  71    the reverse path DNS as described above obsolete.  The author believe
  72    this is too strong an approach for now.
  73
  74    Similarly, a completely different approach would be to deprecate the
  75    usage of DNS for the reverse tree altogether and replace it by
  76    something inspired from ICMP name-info messages. The author believes
  77    that this approached is an important departure from the current
  78    practise and thus not very realistic.  Also, there are some concerns
  79    about the the security implications of this method as any node could
  80    easily impersonate any name. This approach would fundamentally change
  81    the underlying assumption of "I trust what has been put in the DNS by
  82    the local administrators" to "I trust what has been configured on
  83    each machine I query directly".
  84
  85
  86
  87 2. Dynamic record generation
  88
  89    If static pre-population of the tree is not possible anymore and data
  90    still need to be returned to applications using getnameinfo(), the
  91    alternative is dynamic record generation.  This can be done is two
  92    places: in the DNS servers responsible for the allocated space (/64
  93    or /48) in the ip6.arpa. domain.  or in the DNS resolvers (either the
  94    sub resolver library or the recursive DNS server).
  95
  96    2.1. On the resolver side.
  97
  98    The resolver, either in the recursive DNS server or in the stub
  99    library could theoretically generate this data.
 100
 101    In case DNSsec is in place, the recursive DNS server would have to
 102    pretend these records are authentic.
 103
 104    If the synthesis is done in the stub-resolver library, no record
 105    needs to be actually generated, only the right information needs to
 106    be passed to getnameinfo() and getaddrinfo().  If the synthesis is
 107    done in the recursive DNS server, no modification is required to
 108    existing stub resolvers.
 109
 110
 111 2.2. On the server side.
 112
 113    PTR records could be generated automatically by the server
 114    responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
 115    prefixes or basically anything in between) when static data is not
 116    available.
 117
 118    There could be impact on DNSsec as the zone or some parts of the zone
 119    may need to be resigned each time a DNS query is made for an
 120    unpopulated address. This can be seen as a DOS attack on a DNSsec
 121    zone, so server side synthesis is not recommended if DNSsec is
 122    deployed.
 123
 124
 125
 126 3. Synthesis
 127
 128    The algorithm is simple: Do the normal queries. If the query returns
 129    No such domain, replace this answer by the synthetized one if
 130    possible.
 131
 132 3.1. PTR synthesis
 133
 134    The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
 135    where [X] is any valid DNS name.
 136
 137    The fact that the synthetized PTR points to the dynrev.arpa. domain
 138    is an indication to the applications that this record has been
 139    dynamically generated.
 140
 141
 142 3.2. A synthesis
 143
 144    If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
 145    record for the string [X].dynrev.arpa. which value is d.c.b.a. with
 146    a,b,c & d being integer [0..255]
 147
 148
 149 3.3. AAAA synthesis
 150
 151    If [X] is in the form
 152    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-
 153    addr.arpa, one can synthetized a AAAA record for the string
 154    [X].dynrev.arpa. which value is
 155    FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
 156    a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
 157
 158
 159 3.4. Server side synthesis
 160
 161    If synthesis is done on the server side, PTR could be set not to use
 162    the dynrev.arpa domain but the local domain name instead.  It culd be
 163    for instance dynrev.mydomain.com.
 164
 165    Note also that server side synthesis is not incompatible with
 166    resolver side synthesis.
 167
 168
 169
 170 4. IANA considerations
 171
 172    The dynrev.arpa. domain is reserved for the purpose of this document.
 173
 174
 175
 176 5. Security considerations
 177
 178    Section 2. discusses the the interactions with DNSsec.
 179
 180
 181
 182 6. Authors addresses
 183
 184    Alain Durand
 185    SUN Microsystems, Inc
 186    17, Network Circle
 187    UMPK17-202
 188    Menlo Park, CA 94025
 189    USA
 190    Mail: Alain.Durand@sun.com
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226
 227
 228
 229
 230
 231
 232
 233
 234
 235
 236
 237
 238
 239
 240