To:
dnsop@cafax.se
From:
Pekka Savola <pekkas@netcore.fi>
Date:
Sun, 16 Mar 2003 14:07:09 +0200 (EET)
Sender:
owner-dnsop@cafax.se
Subject:
durand-dnsop-dynreverse-00 comments
Hi, A few comments on the ipv6 dynamic reverse proposal which will be on agenda. ==> I think the idea is interesting but probably useless or even damaging. Responses in dynrev.arpa zone are not service provider -specific which is one of the main reasons for doing reverse queries: obtaining *any* more information than just an IP address. Better fix would be working on the real reverse DNS population, or disabling reverse DNS checks. ==> This kind of action has security implications also: if reverse check is done to ensure (some form) of security, and this provides a synthetized record for any query, what is the use of that? ==> another perspective to this in my comments on ietf-dnsop-ipv6-dns-issues-02: it seems to me that the wildcard record is exactly what seems to be looked for here. editorial: ---------- 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]. ==> boilerplate identical to official ones would be nice. 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 ==> s/relies/rely/ its existence and decent status. Some applications performs some ==> s/performs/perform/ (very) weak security checks based on it. Mail relays relies on it for ==> s/relies/rely/ some anti-spams checks an some FTP server will not let you in unless your IP address resolve properly with a PTR record. ==> s/server/servers/, s/resolve/resolves/ preserver anonymity. If those addresses are to resolve in the reverse ==> s/preserver/preserve/ 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. ==> 2^80 is a better analogy. or /48) in the ip6.arpa. domain. or in the DNS resolvers (either the ==> s/domain./domain/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings #---------------------------------------------------------------------- # To unsubscribe, send a message to <dnsop-request@cafax.se>.