[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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>.

Home | Date list | Subject list