From f50ae72ec3417cae55dd4e085991c01af9fdc5f1 Mon Sep 17 00:00:00 2001 From: Martin Nagy Date: Wed, 11 Feb 2009 20:37:59 +0100 Subject: Initial commit --- doc/draft/draft-durand-dnsop-dynreverse-00.txt | 240 +++++++++++++++++++++++++ 1 file changed, 240 insertions(+) create mode 100644 doc/draft/draft-durand-dnsop-dynreverse-00.txt (limited to 'doc/draft/draft-durand-dnsop-dynreverse-00.txt') diff --git a/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/doc/draft/draft-durand-dnsop-dynreverse-00.txt new file mode 100644 index 0000000..224e7ad --- /dev/null +++ b/doc/draft/draft-durand-dnsop-dynreverse-00.txt @@ -0,0 +1,240 @@ +Internet Engineering Task Force Alain Durand +INTERNET-DRAFT SUN Microsystems +Feb 21, 2003 +Expires Aug 2, 2003 + + + + Dynamic reverse DNS for IPv6 + + + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- cgit