summaryrefslogtreecommitdiff
path: root/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt')
-rw-r--r--contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt240
1 files changed, 0 insertions, 240 deletions
diff --git a/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt
deleted file mode 100644
index 224e7ad1697e2..0000000000000
--- a/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt
+++ /dev/null
@@ -1,240 +0,0 @@
-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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-