Subject: [dnsop] I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-00.txt

From: [email-masked]
Date: Tue, 12 Sep 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Domain Name System Operations Working Group of the IETF.

	Title		: Considerations for the use of DNS Reverse Mapping
	Author(s)	: D. Senie, A. Sullivan
	Filename	: draft-ietf-dnsop-reverse-mapping-considerations-00.txt
	Pages		: 9
	Date		: 2006-9-12
	
Mapping of addresses to names is a feature of DNS.  Many sites
implement it, many others do not.  Some applications attempt to use
it as a part of a security strategy.  The goal of this document is to
encourage proper deployment of address to name mappings, and provide
guidance for their use.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reverse-mapping-considerations-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-dnsop-reverse-mapping-considerations-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsop-reverse-mapping-considerations-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 13 Sep 2006 12:39:43 +0200

> 	Filename	: draft-ietf-dnsop-reverse-mapping-considerations-00.txt

In section 2:

                                   RIPE's policy appears to require
   Local Internet Regisgtries to perform further delegation on blocks
   delegated by RIPE to them, but it does not actually make this a
   requirement [RIPE302].  It does, however, explicitly permit
   registrants of address space to delegate authority for requesting
   reverse delegation.

s/Regisgtries/

"appears to require"... "but it does not actually make this a requirement"

This phrasing strikes me as quite odd. :)

The RIPE NCC will delegate to anyone who is responsible for address space in
their region. If you are the maintainer for this address space, you can choose
to handle the reverse or not.

In section 4.1:

   Regional Registries and any Local Registries to whom they delegate
   SHOULD establish and convey a policy to those to whom they delegate
   blocks that IN-ADDR mappings are required.  Policies SHOULD require
   those receiving delegations to provide IN-ADDR service, to delegate
   to downstream customers, or both.

I disagree with this, for a number of reasons.

Argument from Idealism

My belief is that DNS works as well as it does, because the maintainer of the
delegated domain can decide how important it is for that domain to work. So, if
you don't care you can use a single host running an unpatched Windows 95 for
your server. If it's critical to your business, you can have redundant machines
using a variety of DNS software operating in different networks and countries.
Whatever.

By implementing a policy that "requires" people to implement IN-ADDR, you are
telling them that you know more about their needs than they do. This probably
isn't true, and even if it is, knowing better doesn't give anyone the right to
make decisions for other people. :)

Argument from Pragmatism

It's not going to work, so lets recognize that reality and move on.

The only real "stick" that the RIRs have to enforce their policies is to not
issue space, or in theory to revoke space already issued. But, RIR policy is
made by RIR members... the same people who receive the space. These people are
going to resist a policy that could cause themselves pain, unless the benefits
are clear.

Even if such a policy did get adopted, I think the best possible case would be
that the RIRs confirm working IN-ADDR before a delegation. In most cases this
would mean auto-generated names, like:

5.6.6.10.in-addr.arpa PTR system-665.myisp.nl.
6.6.6.10.in-addr.arpa PTR system-666.myisp.nl.

Not so useful really.

Also, entropy affects systems, and since these systems are not perceived as
being a benefit by customers, this information will not be maintained with the
same attention as 'real' data. Honestly, most end-users won't even notice when
their reverse delegation goes away.

So, I like the list of possible issues, and the recommendation to ISPs, but I
think recommending RIRs require people provide reverse delegation is a bad idea.

- --
Shane
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Sep 2006 09:49:52 -0400

Hi,

Thanks for the comments.  Some additional questions below.

> This phrasing strikes me as quite odd. :)

It is indeed.  This is what made me put it that way:

      Reverse delegations for IPv4 and IPv6 addresses allocated by
      the RIPE NCC are made to Local Internet Registries (LIRs) and
      further delegated by the LIRs to Internet Service Providers or
      End Users.  ([RIPE 302], section 1.0)

Now, that initially seems to say that LIRs have to delegate further,
because it makes the statement as though it were fact.  A bit of
digging around Google left me with the impression that at least some
people think this policy does require such further delegation.  Note
that there is no requirement for such delegation, though; the policy
does not actually state that LIRs must do the delegation.  Text to
make the paragraph less awkward would be appreciated.

> So, I like the list of possible issues, and the recommendation to
> ISPs, but I think recommending RIRs require people provide reverse
> delegation is a bad idea.

What about changing the "require[d]" to "encourage[d]"?  I've
received feedback from some operators, off-list, who have been really
emphatic about how important reverse mapping is to them.  Some ISPs
don't seem to be getting that message, and the recommendation above
was intended as a mechanism for getting the word out.

Thanks for your comments,

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

.