NetBSD/dist/bind/doc/draft/draft-durand-dnsop-dynrever...

241 lines
6.9 KiB
Plaintext

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.
1. 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".
2. 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.
3. 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.
4. IANA considerations
The dynrev.arpa. domain is reserved for the purpose of this document.
5. Security considerations
Section 2. discusses the the interactions with DNSsec.
6. Authors addresses
Alain Durand
SUN Microsystems, Inc
17, Network Circle
UMPK17-202
Menlo Park, CA 94025
USA
Mail: Alain.Durand@sun.com