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

From: [email-masked]
Date: Mon, 04 Jun 2007 18: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-03.txt
	Pages		: 14
	Date		: 2007-6-4
	
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.  This document outlines what
   should be taken into account when deciding whether to implement
   reverse mappings of addresses to names, suggests that site
   administrators implement reverse mappings if there are no strong
   considerations against such mappings, and provides considerations to
   be taken into account when using reverse mappings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reverse-mapping-considerations-03.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-03.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-03.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.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Ralf Weber <[email-masked]>
Date: Tue, 5 Jun 2007 10:28:23 +0200

Moin!

As pointed out several times throughout the draft DNSSEC deployment  
would make reverse mappings more reliable. So wouldn't it be a good  
idea to put a paragraph in the draft to encourage LIRs and providers  
to sign there reverse zones? Key management for reverse zone probably  
isn't as political as for the root zone, and AFAIK RIPE already does  
this.

So long
-Ralf
---
Ralf Weber
Platform Infrastructure Manager
Colt Telecom GmbH
Herriotstrasse 4
60528 Frankfurt
Germany
DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780
Fax: +49 (0)69 56606 6280
Email: [email-masked]
http://www.colt.net/
Data | Voice | Managed Services

*****************************************
COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland *
Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 *
Geschäftsführer: Albertus Marinus Oosterom (Vors.), Rita Thies *
Amtsgericht Frankfurt/Main HRB 53898 * USt.-IdNr. DE 220 772 475

---

From: Ralf Weber <[email-masked]>
Date: Tue, 5 Jun 2007 10:28:23 +0200

Moin!

So long
-Ralf
---
Ralf Weber

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Jun 2007 08:23:52 -0400

Dear colleagues,

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

This version of the draft attempts to close all the known outstanding
issues _except_ for the expression "in use" for an address.  That
issue will need to be addressed in a -04 version.  Comments are
solicited on this version of the draft.

Best regards,

Andrew

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Jun 2007 08:23:52 -0400

Dear colleagues,

Best regards,

Andrew

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Jun 2007 11:15:25 -0400

> isn't as political as for the root zone, and AFAIK RIPE already does  

Would adding a note in the Security Considerations section to the following
effect address this issue for you:

       To the extent that the DNS Security Extensions make DNS results
       more reliable, deployment of the DNS Security Extensions in the
       reverse tree will also make the reverse mappings more reliable
?

A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 5 Jun 2007 11:15:25 -0400

A

---

From: Ralf Weber <[email-masked]>
Date: Wed, 6 Jun 2007 13:02:28 +0200

Moin!

>        reverse tree will also make the reverse mappings more reliable
Well the intent was more to have it under 4.2 to encourage LIR and  
network
operators to deploy DNSSEC in reverse mapping. But the notion in the
Security Considerations is also needed.

So long
-Ralf
---
Ralf Weber

---

From: Ralf Weber <[email-masked]>
Date: Wed, 6 Jun 2007 13:02:28 +0200

Moin!

So long
-Ralf
---
Ralf Weber

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Jun 2007 08:01:45 -0400

> >effect address this issue for you:

[. . .]

> operators to deploy DNSSEC in reverse mapping. 

I'm somewhat disinclined to add it there, just because the document is
about reverse mappings, and not about DNSSEC.  If we have to add to
every document about the DNS that people should use DNSSEC, every
document is going to get longer.  But I am open to persuasion: does
anybody else think we should add a note encouraging DNSSEC in section
4.2?

> But the notion in the

Ok, I'll add that, in any case.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Jun 2007 08:01:45 -0400

[. . .]

A

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Jun 2007 16:50:53 -0400

http://ietf.org/internet-drafts/draft-ietf-dnsop-reverse-mapping-considerations-03.txt

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

I would change the wording from this

#3.1  Examples of effects of missing reverse mapping
#
#   Following are some examples of some of the uses to which reverse

to this

#3.1  Examples of effects of missing reverse mapping
#
#   Following are some examples of uses to which reverse

That's the only comment I have on the draft.  The one change I have 
is only wording ("some" used twice in the same sentence) - nothing of 
substance and certainly a change I could live without seeing made.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 8 Jun 2007 16:50:53 -0400

to this

Sarcasm doesn't scale.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 8 Jun 2007 23:53:11 -0400 (EDT)

Ed, having reviewed the document, can you assure us that it doesn't
contain any language that might be understood as implying that reverse
DNS records are somehow required?

Can you assure us that it doesn't contain any language that might be
understood as implying that using reverse DNS for security is anything 
but a crock'? (as Ted Lemon wrote)

Can you assure us that Mr. Sullivan, despite his advocacy of making
in-addr required, despite his advocacy of using reverse DNS for
security, and despite his advocacy of irrational decision-making
processes (cf discussion on DNSOP February & March '07), hasn't used
this draft as a platform to obtain an the IETF RFC credential to promote
discredited practices and thereby mislead people about reverse DNS?

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Fri, 8 Jun 2007 23:53:11 -0400 (EDT)

--Dean

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 12 Jun 2007 19:10:27 +0900

At Tue, 5 Jun 2007 08:23:52 -0400,

> solicited on this version of the draft.

Thanks for the update.  I've read the 03 version, and found that most
of my previous comments
http://www1.ietf.org/mail-archive/web/dnsop/current/msg05418.html
were not actually addressed (or perhaps ignored or rejected?).  In
particular, I now more strongly wonder why this document still keeps
the strong recommendation:

   all IP addresses in use within a range should have a reverse mapping.
(I guess the above mentioned 'exception' is different from the
recommendation itself; I'd apologize if not)

I stated in my previous comments:

> We should not forget that providing and maintaining reverse mappings
> require operational costs (even though it's not very high).  IMO, when
> we recommend one *should* provide something that comes with a cost, we
> should give a convincing reason why they should do it.  The rationale
> is still missing in this version.  As I commented on the previous
> version of the draft, none of the described issues or usages seems a
> convincing reason for such a strong requirement.

I'm not sure if this point was missed or ignored or rejected, or
perhaps I misunderstood the 03 version, but I still cannot see a
convincing reason for the strong suggestion in this version.  Is there
any specific reason that we cannot make the statement more moderate
like this?

   it is encouraged for a network administrator to provide a reverse
   mapping for IP addresses in use within a range when the management
   cost is acceptable for the administrator.

For other specific comments shown in msg05418.html, I'll point out
which comments I don't think are addressed if necessary; please let me
know in that case.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 12 Jun 2007 19:10:27 +0900

Thanks,

					JINMEI, Tatuya

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Jun 2007 11:45:18 -0400

On Tue, Jun 12, 2007 at 07:10:27PM +0900, JINMEI Tatuya / 神明達哉 wrote:>

> were not actually addressed (or perhaps ignored or rejected?).  

Thanks for your review.  We considered each of your comments
carefully, and made changes to the text to address them where it
seemed correct to do so.  (At the bottom of this message, I'm
including a detailed outline of whether and how the document changed
in response to each of your comments.  Your comments have been
extremely valuable, and I'm distressed to learn that you think we are
silently ignoring them.  I apologise in advance that the responses
make this message a little long.)

> In

Note that, because someone has pointed out (and I missed) the
ambiguity in "in use", this sentence has to change anyway.  But I
observe three things here.  First, the sentence says "should" not
"SHOULD", so I'd argue that this is not as strong a requirement as you
seem to think.  Second, the sentence begins with, "Unless there are
strong counter-considerations. . . ," which rather softens the meaning
some more.  It strikes me that one could easily argue that "expense"
is a strong counter-consideration, in the event the expense is high
enough.  Finally, the paragraph also includes some entirely new text
at the end which was intended precisely to address your previous
comments:

        This principle is also not intended to impose undue burden on
        network operators.  It is nevertheless worth considering that
        not all benefit from an administration practice accrue to the
        administrator of a network.  The consumers of reverse mapping
        data are often not the operators of the network that provides
        the reverse mappings.  Users of reverse mapping data report
        that it is valuable to them.

In your comments before, you noted that we need a convincing reason why
a practice should be followed if it imposes any cost.  In the text
above, there is given a reason; if it is not convincing to you, and
you think the cost is too high, then it seems to me that you might
have a counter-consideration to implementing reverse mappings (that
would be the "undue burden"). 

>    cost is acceptable for the administrator.

The problem I have with that formulation is that management cost is
not the _only_ counter-consideration that ought to be in place.  The
document already lists another example -- where the cost is imposed on
the operation of the DNS as opposed to the pocketbook of the
operator.  Moreover, there is little to distinguish, "Do this if the
cost is acceptable to you," and, "Do this or not; it's up to you."  If
the document is really going to say that it makes no difference
whether you maintain reverse mappings, then I don't think we should
bother saying anything: we'll get the situation we have today anyway.  

In addition, after the -03 draft was posted, I received a comment from
another list pointing out that there is already an RFC that says you
should implement reverse mapping: RFC 1912.  In section 2.1, it says

    Make sure your PTR and A records match.  For every IP address,
    there should be a matching PTR record in the in-addr.arpa domain.
    If a host is multi-homed, (more than one IP address) make sure
    that all IP addresses have a corresponding PTR record (not just
    the first one).  Failure to have matching PTR and A records can
    cause loss of Internet services similar to not being registered in
    the DNS at all.  Also, PTR records must point back to a valid A
    record, not a alias defined by a CNAME.  It is highly recommended
    that you use some software which automates this checking, or
    generate your DNS data from a database which automatically creates
    consistent data.

I would argue, therefore, that the current draft is something of a
softening of the position taken in RFC 1912.  (It's also pretty clear
that the draft needs to be updated to take the above passage into
account.  Thanks to Bruce Gingery on spam-l for this.)

I hope the above addresses your concerns in this area.  

Below is my outline of how the draft changed between -02 and -03 to
try to address your other helpful comments.  

The bulk of your comments were in
http://www1.ietf.org/mail-archive/web/dnsop/current/msg05411.html, I
believe.  

> - Section 1.1
>   If the intent of this document is to recommend one *should* provide
>   reverse mappings, this section clearly says so instead of the vague
>   wording like "provide some guidelines".

In -03, this section was updated to include, "suggests that site
administrators implement reverse mappings in the absence of strong
counter-considerations. . .".  The use of the word "suggests" is
intentional, again to avoid any confusion with standards-words and to
ensure that the document is clearly not imposing a requirement on
operators.

> - Section 1.2
>   I guess the IESG will suggest not using "NXDOMAIN" since it's an
>   implementation specific term (actually I was told that when I
>   edited RFC4074).

Section 1.2 (and other mentions) changed from NXDOMAIN to Name Error.

> - Section 1.3
[. . .]
> What are "useful" reverse mappings?  I'd rather remove this word, then
> it will be a mere fact and clear to read.  

The word "useful" is unpacked to use the terminology already defined
in the document.

Also,

> I don't think it's very clear that [RFC4255] could benefit from
> matching reverse mapping.  In fact, it does not mention DNS reverse
> mapping at all (while the other two do).  If we want to include
> [RFC4255], I suggest adding some text that explains how it could
> benefit from reverse mapping.

I asked about the relevance of reverse mappings to RFC 4255, and it
was approximately as I thought: reverse mappings can be useful as one
more check that you are getting the data you think you are,
particularly in the presence of the DNS Security extensions.  I wasn't
able to convince myself that explicating every example in the document
would be a good idea; the document is already kind of fat for what it
is, and I was afraid that adding an explanation of the way this might
work would just be distracting.  I did try two or three times to write
it up in a compact but suitably clear way, and failed.  If you really
object strongly to the mention of RFC 4255, I can take it out in the
-04 draft, because the other two examples probably suffice.

> - Section 3.1
[. . .]
> I think this note is too generic to make "informed decisions".  I
> suggest adding how these are ineffective or even harmful for each
> case. 

In order to make the text in each case more focussed on the topic, we
broke apart the discussion of what happens and the discussion of
whether the check in question is actually effective.  The
effectiveness discussion does not address each use of reverse
mappings, but treats them as classes of use and then discusses whether
that class of use actually achieves its goal.  We hope this makes the
point more clearly that reverse mapping _alone_ offers at best a very
weak piece of positive evidence for a conclusion.  (Note that the
negative evidence case might be different.)

> - Section 3.1
[. . .]
> As I pointed out in my comments on the previous version, this is
> unfair or misleading.  I'd rather make a new section "Examples of
> effects of relying on reverse mapping", and put this example there,
> without being specific to the "missing" case.

We simply removed this section.  It seemed to be attracting too much
dissent for its importance in the discussion.

> - Section 3.1

>    Traceroute output 
[. . .]
> I commented for the previous version that this did not seem accurate.
> There are "may"s added in this version, but I don't think they address
> the concern.

The section is altered to say this:

   Traceroute output with descriptive reverse mapping proves useful when
   debugging problems spanning large areas.  When this information is
   missing, the traceroutes can take longer, and those performing
   troubleshooting are left without useful hints.

The "additional steps" section is here more concrete, and notes the
exact benefit that accrues to the user of the reverse mapping.

> - Section 3.3
[. . .]
> I suggest adding some more text that explains why it's less pressing
> in practical.

We added "because the number of addresses affected is different" to
the sentence, to spell out what the practical difference is.

[. . .]
> than 20010db81111...abcd.example.com).  Overall, the effectiveness
> of this approach [for hiding] should be discussed more carefully,
> and in a more pragmatic way.

The text as it is accords with the recommendation in
draft-ietf-v6ops-scanning-implications-03, which discusses the
"hiding" approach more thoroughly.  Do you think we should add a
reference to that draft?  I have resisted that because this document
has dragged on a long time, and I'd like not to hold it up with a
possible downref, but if you really think the reference is needed we
can add it.  

> - Section 4.1

>    In general, the DNS response 
[. . .]
> This sentence sounds indirect and vague to me.  In particular, I'm not
> sure if I understand the phrase of "what is supposed to be seen at the
> address".

This was text lifted directly from the list (contributed by Ed Lewis,
if memory serves).  It just means that, from any place on the
Internet, there is a right answer to every query _for that querier_.
That isn't to say that there is always one universally right answer to
every query at a given time.  (Note that this moved to section 4.2 in
-03, because of the addition of another subsection.)

> - Section 4.1

>    It is desirable that Regional 
[. . .]
> I'd like to see why. (As part of my main concern)

For the reasons noted in my main argument above as to why we want to
encourage reverse mappings.  Note that this is merely "encourage", not
"require".

> - Section 4.1
[. . .]
> In addition, it's not clear to me what "all IP addresses in use"
> means.  For example, if I manage an IPv6 subnet
> "2001:db8:1111:2222::/64", are "the all addresses in use" the
> addresses from 2001:db8:1111:2222:0000:0000:0000:0000 to
> 2001:db8:1111:2222:ffff:ffff:ffff:ffff?  Or does that only mean IPv6
> addresses assigned to existing hosts in that subnet?  If the latter,
> does that include IPv6 addresses configured via stateless
> autoconfiguration and often missing from the network?  What about IPv6
> temporary addresses?

I realise in retrospect that I didn't understand this comment properly
when reading it, on the basis of another message that I overlooked (I
misfiled it) when working on the revisions.  See my other message on
this topic.  I will send a proposed change to the text to the list.  I
apologise to you and the rest of the working group for being obtuse
on this point.

> - Section 4.2
[. . .]
> I cannot be sure what "functions that depend on reverse mapping"
> specifically indicates.  An example might be helpful here.

We are getting concerned about the length of the document, so didn't
include another example.  I suppose an obvious feature would be the
display of hostnames discovered by way of the reverse map.  Do you
really think an example is needed?

> I think this is too weak.  Comparing to the strong "recommendation" in
> the previous section that does not explain why, this part provides the
> reason, so I think the recommendation can/should be tightened
> accordingly.  Referring to the text in the Security Considerations
> section, my suggestion is:

I don't understand how "no real security" is too weak.  The Security
Considerations section already says that people should use better
forms of authentication, and it seemed to me that your proposed text
was a security consideration about the use of reverse mapping itself,
and not about the document or its application.  (Maybe I'm just
misunderstanding).  The -03 draft is intended to make the
"effectiveness" section clearer and cast in a greater light.

> I'd also point out even the use of reverse mapping as a scoring system
> can be controversial.

I was unable to find a controversy around reverse mapping used in
scoring systems, or even _any_ criterion used in scoring systems.  The
idea of scoring systems seems to be that you set the bases on which
you wish to score, and then evaluate according to those criteria.  The
draft as it is has a fairly extensive discussion of the ways in which
too great weight placed on non-matching or missing reverse mappings
can cause "false positives".  Every anti-spam person I talk to tells
me that using reverse mapping in scoring is a very good, but not
perfect, measure of spamminess.  I have never met anyone actually
operating a mail server who has given me a different opinion, but I'd
be happy to hear from such people if they are out there.

> I don't understand the logic of this sentence.  This sounds as if
> complete connection rejection on the basis of missing reverse mapping
> will be encouraged (or at least not discouraged) when reverse mapping
> is universal.  But in my understanding the essential problem of this
> approach is "the use of the reverse tree provides no real security,
> (and) can lead to erroneous results".  This should still apply even if
> "reverse mapping is universal".

It doesn't actually say what you suggest it does -- "Not X until Y"
means that Y is a necessary condition for X, but doesn't say Y is a
sufficient condition.  In any case, the point of the section is to
discourage very strongly complete connection rejection on the basis of
missing reverse mapping, until every host on the Internet has a
reverse mapping.  Since "heat death of the Universe prior to universal
reverse mapping" is probably a safe bet, we thought this was enough.
I didn't like the alternate text you provided because it seemed to
lean on the argument that, since reverse mappings are not positive
proof, therefore they're not useful negative proof.  I don't think
that's true in every case, and therefore we can't use it as a premise.

Thank you again for your detailed reviews and helpful comments.  I
hope the above demonstrates the ways in which your review has
strengthened the document; and explains, where your specific
suggestions were not incorporated, why another path was taken.  

Best regards,
Andrew

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Jun 2007 11:45:18 -0400

[. . .]

Also,

[. . .]

[. . .]

[. . .]

[. . .]

[. . .]

[. . .]

[. . .]

[. . .]

[. . .]

Best regards,
Andrew