Re: wrt: draft-ietf-dnsop-inaddr-required-00.txt

[Bill Manning <bmanning@ISI.EDU>]

% > Except that if my forward delegation doesn't work, nobody can come to
% > my web pages.  Even the CEO will notice that (well, after his secretary
% > points it out to him).  From the end user point of view, if forward
% > delegation doesn't work, the host isn't on the Internet (whatever "the
% > Internet" is).

	Based on applications use of the name->address mapping
	Few (if any) existing applications use the address-name mapping.
	
	Some applications try to strengthen the integrity check by
	verifying that the name-address & address-name pairs are
	consistant. Thats -one- step up on the authenication ladder
	and in the absence of any other methods is useful.
	
% As this discussion progresses, I'd like to suggest the following: We
% either work toward a BCP document which says:

	"... work toward a BCP..." is just plain wrong. One documents
	BCPs, not create them on the fly.

% 1. IN-ADDR mappings are required, MUST be properly configured, and
% explains why.
% 
% or.
% 
% 2. IN-ADDR mappings are entirely optional, MUST NOT be used for
% authentication under any circumstances (i.e not even if the IN-ADDR PTR
% result is then looked up to verify), and explains why.


	What applications could be enabled by accurate address-name
	maps?  How can we help enable this?  #1 is closer than #2.

% Right now, at least 15% of the end-user stations are not covered by
% pointer records (data from some very active websites I host). This
% covers dialups, corporate networks, DSL subnets, etc.

	Some preliminary data indicates that the accuracy of 
	the forward database (TLDs et.al.) has dropped below
	the accuracy of the inverse database (in-addr.arpa)
	
	
% -----------------------------------------------------------------
% Daniel Senie                                        dts@senie.com
% Amaranth Networks Inc.                    http://www.amaranth.com
% 


-- 
--bill