241 lines
6.9 KiB
Plaintext
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|