Subject: Re: [DNSOP] reverse-mapping-considerations: ambiguity?

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Feb 2007 09:43:18 -0500

Hi,

Thanks for your careful reading and measured comments.  Thanks also
for the suggested text.

Before I deal with some of the issues you raise in your posting, I
want to request some feedback from the wider group on what is clearly
the central question in this discussion.  I'd like to get a general
sense of what people think, because it is entirely possible that this
is a topic on which well-informed people just disagree.

On Wed, Jan 24, 2007 at 02:35:01AM +0900, JINMEI Tatuya / 神明達哉 wrote:

> let such admins do what doesn't really make sense and to recommend
> others to adapt themselves for the convenience of the stubborn admins,
> I don't see much importance in this effort; a stubborn admin will do
> whatever they want anyway regardless of "technically sound"
> recommendations from the IETF, 

It appears to me that there are two slightly different views about
security and utility in this discussion.  To be clear, I don't regard
these as "camps", but I do think they are subtly different views, and
that the difference makes a difference for this discussion.

The first view is that reverse mappings provide no information of any
utility whatsoever.  There is no reason ever to use them except for
convenience; certainly, one should never make any decisions on the
basis of information included in the reverse tree.  The idea here is
that, because the reverse tree itself does not offer much in the way
of security (and because it is relatively easy to hide bad behaviour
anyway), there is no real utility in reverse mappings.  Moreover, any
use of them at all in making decisions about how to proceed is in fact
a security hole that needs to be plugged with haste.

The second view is that the reverse tree sometimes contains
information that might be useful in making decisions about a host on
the Internet.  It is not to be regarded as canonical information, and
it should certainly never be used as a primary source of data.  That
said, the reverse tree can sometimes be useful.  Some site
administrators, under certain circumstances, might legitimately use
the (non-)maintenance of reverse mappings as a clue, on the basis of
which they do additional processing.  The general idea here is that,
while the additional information provides no security at all on its
own, it can sometimes be of use in _disqualifying_ a remote host from
connecting to one's service.  In addition, we have some cases where
the reverse tree might be useful for other purposes.  In the presence
of reports from some users that they find the facility useful, I'm
inclined to say that it should be maintained.  This is not to say that
it must be maintained in every situation; but that, on balance, unless
you have pretty good reasons not to maintain it, you should maintain a
reverse mapping.

I believe that the draft as it stands is consistent with the second
view, and that it expresses a view that is contrary to the first
view.  In other words, the draft as written says, I think, that
administrator of site A is perfectly entitled to make decisions about
site B on the basis of reverse mappings, _but_, the administrator of
site A is cautioned that there are plenty of pitfalls in that
strategy, and they ought to be taken into consideration.

I'd like to know whether people think that is a reasonable thing to
say.  If the answer is, "No," then I'm not sure what we can say about
reverse mappings at all.

Best regards,
A

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

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Feb 2007 09:43:18 -0500

Hi,

Best regards,
A

---

From: Robert Story <[email-masked]>
Date: Tue, 6 Feb 2007 10:50:13 -0500

On Tue, 6 Feb 2007 09:43:18 -0500 Andrew wrote:
AS> [...]  In other words, the draft as written says, I think, that
AS> administrator of site A is perfectly entitled to make decisions about
AS> site B on the basis of reverse mappings, _but_, the administrator of
AS> site A is cautioned that there are plenty of pitfalls in that
AS> strategy, and they ought to be taken into consideration.
AS> 
AS> I'd like to know whether people think that is a reasonable thing to
AS> say.  If the answer is, "No," then I'm not sure what we can say about
AS> reverse mappings at all.

I think it's a reasonable thing to say.

-- 
Robert Story
SPARTA

---

From: Robert Story <[email-masked]>
Date: Tue, 6 Feb 2007 10:50:13 -0500

---

From: Dean Anderson <[email-masked]>
Date: Tue, 6 Feb 2007 14:48:52 -0500 (EST)

> AS> reverse mappings at all.

It is never reasonable to describe unreasonable behavior as somehow 
reasonable.  

Everyone is entitled to be unreasonable in their personal decisions; its
a free society. So, in that sense, administrator A is _entitled_ to make
decisions based on the reverse mappings of site B.  Administrator A is
also _entitled_ to wear a tinfoil hat.  The entitlement to do an act
does not make that act reasonable.

However, it is quite another thing to say that those decisions are
"reasonable".  "Reasonable" decisions are well-founded on the basis of
actual facts and deductive logic.  Decisions that are not based on
actual facts and deductive logic are, by definition, "unreasonable".

There are no facts or deductions regarding security that can be properly
inferred by administrator A based on the reverse mapping entries of site
B. The decisions described in the draft's examples that administrator A
could take on the reverse mapping entries of site B are therefore
_unreasonable_.  There is no way around that.

You are merely confusing administrator A's _entitlement_ to make a
decision with administrator's A access to actually true facts and use of
deductive logic.  One is entitled to be irrational, but being irrational
is the opposite of being reasonable.  Being reasonable _requires_
actually true facts and deductive logic.

Reverse mapping entries do not provide one with actually true facts, nor
do they provide one with necessary and sufficient conditions on which to
base deductions about the security of site B.

		--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: Tue, 6 Feb 2007 14:48:52 -0500 (EST)

--Dean

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 06 Feb 2007 18:22:26 +0100

> say.  If the answer is, "No," then I'm not sure what we can say about

I think the draft is a good compromise between the two extremes, and that
it could very well form the basis for more sensible treatment of
(non-)existance of PTR data. 

I support the draft. 

-- 
Måns Nilsson                     Systems Specialist
+46 70 681 7204   cell                       KTHNOC
+46 8 790 6518  office                  MN1334-RIPE

... Now, it's time to "HAVE A NAGEELA"!!
_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 06 Feb 2007 18:22:26 +0100

I support the draft.

---

From: Robert Story <[email-masked]>
Date: Wed, 7 Feb 2007 10:14:00 -0500

On Tue, 6 Feb 2007 14:48:52 -0500 (EST) Dean wrote:
DA> It is never reasonable to describe unreasonable behavior as somehow 
DA> reasonable.  

But reason itself is subjective. What's perfectly reasonable to one is
utterly insane to another.

DA> "Reasonable" decisions are well-founded on the basis of
DA> actual facts and deductive logic.  Decisions that are not based on
DA> actual facts and deductive logic are, by definition, "unreasonable".

Baloney. It is possible to make reasonable decisions even with the
complete absence of facts. But that's besides the point.

So, if you want facts, here you go: many admins use reverse mappings
for various and sundry purposes. (You can scream and holler all you want
about how 'unreasonable' it is for those admins to do so, but it
doesn't change the fact that they do.) thus it is 'reasonable' to
suggest that other admins may want to consider provisioning reverse
mappings. Which is what this document does.

DA> Reverse mapping entries do not provide one with actually true facts, nor
DA> do they provide one with necessary and sufficient conditions on which to
DA> base deductions about the security of site B.

Regardless of whether or not you consider a reverse mapping a 'true
fact' or not, they certainly can provide sufficient information to make
decisions based on the site.

DA> There are no facts or deductions regarding security that can be properly
DA> inferred by administrator A based on the reverse mapping entries of site
DA> B.

If I get a connection to my mail server from an ip address that reverse
maps to dialup0937613.isp.example, it's perfectly reasonable for me to
decide to reject that connection based on the fact that most mail from
dialups is spam.

You are quite right, however, that I would be daft to have a firewall
rule to a control port of a router that looked like 'good-guy.* ALLOW'.
But that doesn't mean that the first use is unreasonable.

---

From: Robert Story <[email-masked]>
Date: Wed, 7 Feb 2007 10:14:00 -0500

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Feb 2007 13:13:19 -0700

> But that doesn't mean that the first use is unreasonable.

Actually, I would argue that the first use *is* unreasonable, absent  
any more information than that the reverse record contains the string  
"dialup."   For example, what if it contains "dialup-mailserver?"    
What is reasonable, and what is helpful to me about reverse zone  
data, is that it gives me a hint as to where to look to see who's  
talking to me.   I can check the forward to see if the reverse is a  
lie or not.   It's not secure, but it's fairly dependable, and it's  
very helpful for debugging.   OTOH, you'd be insane to put the  
contents of the reverse lookup in your logs without the IP address  
alongside it, because it's not trustworthy.

To me, that is the sole use of reverse lookups.   It is useful, and  
it's good if people populate the reverse tree as a habit because it  
helps in this way.   But it is entirely correct to say that using the  
contents of the reverse tree to make automatic decisions is a mistake.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Feb 2007 13:13:19 -0700

---

From: Paul Wouters <[email-masked]>
Date: Sat, 10 Feb 2007 21:53:56 +0100 (CET)

On Sat, 10 Feb 2007, Ted Lemon wrote:

> To me, that is the sole use of reverse lookups.   It is useful, and it's good
> if people populate the reverse tree as a habit because it helps in this way.
> But it is entirely correct to say that using the contents of the reverse tree
> to make automatic decisions is a mistake.

SSHFP or IPSECKEY records in a DNSSEC signed zone such as RIPE's reverse?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sat, 10 Feb 2007 21:53:56 +0100 (CET)

Paul

---

From: Brett Carr <[email-masked]>
Date: Tue, 13 Feb 2007 12:36:04 +0100

> say.  If the answer is, "No," then I'm not sure what we can say about

I think the draft is well written and provides a balanced opinion on  
which admins can base their decision on reverse mappings.
I support the current wording of the draft.

Brett
--
Brett Carr
Manager -- DNS Services Group
RIPE Network Coordination Centre
Amsterdam

---

From: Brett Carr <[email-masked]>
Date: Tue, 13 Feb 2007 12:36:04 +0100

Brett

---

From: Dean Anderson <[email-masked]>
Date: Tue, 13 Feb 2007 14:33:33 -0500 (EST)

> > a security hole that needs to be plugged with haste.

The reverse mapping tree doesn't have any bearing on whether behavior is 
bad. So, it can't 'hide bad behavior'.  

The reverse mapping tree of Site B is specifically of 'no utility', as
distinguished from 'no real utility', to administrator A for making
_decisions_ about Site B.  The mapping tree of Site B is only useful to
Site _B_.  Site B may use any reverse mapping scheme it pleases. There
are many mapping schemes besides the '1:1' scheme favored by
anti-spammers. Further, the '1:1' scheme isn't universally possible.  
The reverse mapping entry of Site B may be useful for Administrator A to
_document_, but only as a secondary source in addition to the IP
address, and the _documentation_ is only useful to improve subsequent
communication with Site B.  That's it.

> > it should certainly never be used as a primary source of data. 

But it IS regarded by the draft proponents as canonical. We just heard
Mr.  Story exclaim just that. I think most people on the Working Group
don't want to encourage persons with similar views. This draft will
encourage that view.  The draft wording in Section 4 is vague, but can
be read to encourage that view.  I've given text to disambiguate the 
draft, but that text was refused by the author. I think most people on 
the Working Group agree with the statements in my proposed text.

> > That said, the reverse tree can sometimes be useful.  Some site
> > which they do additional processing.  

Exactly wrong.  There is no legitimacy in such use;  Mr. Story
explicitly describes an example using "dialup". This practice should not
be encouraged or seemingly legitimized by this Working Group in the
approval of this draft.

> > In other words, the draft as written says, I think, that
> > administrator of site A is perfectly entitled to make decisions
> > about site B on the basis of reverse mappings, _but_, the
> > administrator of site A is cautioned that there are plenty of
> > pitfalls in that strategy, and they ought to be taken into
> > consideration.
> >

Administrator A is __entitled__ as I previously pointed out, to wear a
tinfoil hat and tell people it protects him from aliens.  However, there
is no rational basis for that belief.  There is a big difference between
what one is entitled to do, and what one is rationally justified in
doing. This working group should, per requirements of RFC2026, restrict
itself to statements in drafts that are true and rational, and should
reject statements that are neither true nor rational.

Dean Anderson
Av8 Internet, Inc

---

From: Dean Anderson <[email-masked]>
Date: Tue, 13 Feb 2007 14:33:33 -0500 (EST)

Dean Anderson
Av8 Internet, Inc

---

From: [email-masked]
Date: Tue, 13 Feb 2007 20:46:36 +0100 (CET)

> Site _B_.

You have claimed this many times before, and you can continue to claim
so until you're blue in the face. That doesn't change the fact that lots
of people find reverse mapping useful.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: [email-masked]
Date: Tue, 13 Feb 2007 20:46:36 +0100 (CET)

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 13 Feb 2007 16:35:48 -0500

> the Working Group agree with the statements in my proposed text.

I am merely an editor, and for that matter only one of them.  But to
be clear: I didn't refuse anything.  The question is still open; I've
asked for feedback from the group.  So far, one person has made
claims similar but, I think, rather more nuanced than your claims. 
Several other people have disagreed with you.  If people agree with
your proposed text, I'd like to hear from them.  (Group members: if
you have such agreement, now would be a good time to make it known.)

As always, I appreciate your feedback, as well as all of that from
the other members of this group, so that we can bring to a swift
conclusion the disposition of this draft.  (I should note, too, that
I have already proposed changes to deal with one of your objections
which seemed to me to be on the money.  I didn't hear from your,
AFAIR, what you thought of those proposals.)

A

-- 
----
                                        +1 416 646 3304 x4110

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 13 Feb 2007 16:35:48 -0500

A

---

From: Edward Lewis <[email-masked]>
Date: Tue, 13 Feb 2007 19:10:40 -0500

>the Working Group agree with the statements in my proposed text.

Dean,

How did you come to the conclusion that "most people on the Working 
Group agree with" you on this?  I point out that you say "most 
people."

You can claim anything you want and you can express your opinion, but 
I draw the line when I see someone (other than the chairs) claim they 
are speaking for the group.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"Two years ago you said we had 5-7 years, now you are saying 3-5.  What I
need from you is a consistent story..."

---

From: Edward Lewis <[email-masked]>
Date: Tue, 13 Feb 2007 19:10:40 -0500

Dean,

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Feb 2007 00:10:18 -0500 (EST)

I didn't say it wasn't useful. I said it was of no use for decision 
making about some other site.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Feb 2007 00:10:18 -0500 (EST)

--Dean

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Feb 2007 22:27:55 -0700

> making about some other site.

Excellent, then we're all in agreement, and the draft can advance as  
written.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Feb 2007 22:27:55 -0700

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Feb 2007 00:43:44 -0500 (EST)

> Group agree with" you on this?  I point out that you say "most 

The past history of this document shows that most people do not agree
with, say, Robert Story.  Mans Nielson etc have favored the very first 
draft, and every draft since for several years. 

I think its funny that Andrew Sullivan just said that he's seen only one
person agree with me.  I count in this __recent__ discussion a very few
people particpating, yet Ted Lemon and JINMEI Tatuya as posted comments
in general agreement with my views.

I think the history of discussion of this document shows that most
people here agree with the following three statements:

1   DNS PTR records are entirely optional, and MUST NOT be assumed to
   exist.  Software MUST NOT fail or incur delay as a result of the non-
   existance of PTR records.

2   Unauthenticated DNS MUST NOT be relied on for security or trust
   decisions.  Even when DNSSEC is used to verify the authenticity of
   DNS records, matching reverse and forward records do not imply either
   improved security or trustworthiness over sites that either do not
   have reverse DNS or that do not have matching foward/reverse DNS.

3   DNS records MUST NOT be used in logs instead of IP addresses.
   Logging only the PTR resource records instead of the IP address is  
   vulnerable, since attackers may have used long names that will either 
   become truncated by many logging systems, or require upto 255 bytes 
   to store.  Logging both IP address and DNS PTR records may be helpful
   but one must also consider that the 255 byte per record space 
   requirement does not become a DOS attack on the logging system.

If most people agreed with say, Robert Story's views, the first draft
would have been approved years ago.  I don't mean to unduly pick on Mr.
Story, but he is a sample representative of a certain camp that for
years has been trying to promote a certain notion of reverse DNS, and
that notion has been rejected in draft after draft for years and years.

Each successive draft has become more and more vague, from near to Mr.  
Story's example of "dialup" to the current description which is entirely
vague about whether these are rational uses or irrational uses. I think
Ted Lemon spoke the historical view of the group in his response to Mr.  
Story.  I think most people (in the group and in the world) think such
reverse filtering is a non-starter.

But if you think I'm wrong about what the group thinks, then I'd be more
than happy to have a vote on the 3 paragraphs above. Such a vote could
certainly promote some progress since then we might simply tell the
editors that their document must be consistent with these three
paragraphs or it won't be considered.  And if the Group votes that those
three paragraphs aren't true, then I would have to agree that there is
no point in objecting to this draft (or any of the previous drafts),
since the fundamental conditions for objection aren't supported by the
Group.

I have an alternative draft that I will submit shortly.  It will include
the 3 paragraphs above, plus additional material relevant to reverse
DNS.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Feb 2007 00:43:44 -0500 (EST)

--Dean

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Feb 2007 22:53:24 -0700

>    requirement does not become a DOS attack on the logging system.

This is a DNSOP draft, so I don't think we *can* use MUST NOT.   My  
main problem with this whole conversation is that I think the draft  
already says this - it just doesn't say "MUST NOT" because it  
*can't*.   If you feel the wording is too weak, and the editor is  
willing to incorporate your wording, minus the MUST NOTs, I have no  
objection to that.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 13 Feb 2007 22:53:24 -0700

---

From: [email-masked]
Date: Wed, 14 Feb 2007 12:01:37 +0000

>    existance of PTR records.

	I disagree with the second sentence.  With a one word change,
	I might agree with the first sentence, e.g. " DNS records are 
	entirely optional, and MUST NOT be assumed to exist. "   In other
	words, applications MUST support address literals.

>    have reverse DNS or that do not have matching foward/reverse DNS.

	I disagree with this statement.  It is false today and will be
	false when DNSSEC is used.

> 3   DNS records MUST NOT be used in logs instead of IP addresses.

	i disagree with this statement.  If one were to change the "MUST NOT"
	to a SHOULD NOT, then this might be a reasonable suggestion.

>    requirement does not become a DOS attack on the logging system.

	the example is a sad statement on the support of fully qualified
	domain names in syslog and its cousins, regardless of DNS RR used.
	A/AAAA/A6 lables are just as prone to length considerations as
	PTR lables.  Nothing inherently worse w/ PTR lables.

--bill

---

From: [email-masked]
Date: Wed, 14 Feb 2007 12:01:37 +0000

--bill

---

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Feb 2007 07:35:07 -0500

>in general agreement with my views.
...
>But if you think I'm wrong about what the group thinks, then I'd be more

I think you are misinterpreting the question.  Let me restate.

Based on what information are you concluding that "most people on the 
Working Group" are in agreement with what you have said/written?

I did not ask whether you were right or wrong on what the group 
thinks.  I asked for the reasons behind concluding that the group 
generally (most people anyway) agrees with you.

What I am objecting to is your declaration of a consensus.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Feb 2007 07:35:07 -0500

...

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Feb 2007 19:50:18 -0500 (EST)

On Wed, 14 Feb 2007, Edward Lewis wrote:

> thinks.  

Oh. That is what I answered. My mistake.

> I asked for the reasons behind concluding that the group generally
> (most people anyway) agrees with you.

> What I am objecting to is your declaration of a consensus.

I am not declaring a consensus. I am stating, based on the history of
discussion the various drafts, that most people agree with my views on
this topic in contrast to, for example, Mr. Story's views.  If anything,
I am asking for a consensus call on the 3 statements I proposed.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Feb 2007 19:50:18 -0500 (EST)

--Dean

---

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Feb 2007 20:06:13 -0500

>I am asking for a consensus call on the 3 statements I proposed.

I went to www.m-w.com and looked up consensus.  It reads:

1 a: general agreement : unanimity <the consensus 
of their opinion, based on reportsŠfrom the 
border - John Hersey> b: the judgment arrived at 
by most of those concerned <the consensus was to 
go ahead>

Note in 1b - "most of those concerned".  Through 
this meaning of the word, I take "most people 
agree with my views" to be you saying there is 
consensus on this issue.

I am asking, based on what evidence are you 
asserting "most people", therefore "consensus" 
has been achieved?

---

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Feb 2007 20:06:13 -0500

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Feb 2007 22:52:45 -0500 (EST)

On Tue, 13 Feb 2007, Ted Lemon wrote:

> This is a DNSOP draft, so I don't think we *can* use MUST NOT. 

I asked this before and got no answer. RFC2119 itself gives some
guidance:

"6. Guidance in the use of these Imperatives

   "Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

"7. Security Considerations

   "These terms are frequently used to specify behavior with security
   implications.  The effects on security of not implementing a MUST or
   SHOULD, or doing something the specification says MUST NOT or SHOULD
   NOT be done may be very subtle. Document authors should take the time
   to elaborate the security implications of not following
   recommendations or requirements as most implementors will not have
   had the benefit of the experience and discussion that produced the
   specification."

My purpose in using these terms is to limit behavior which has the
potential for causing harm.  Further, this text relates to security
issues. In the draft I'm writing, these three paragraphs are in the
"Security Considerations" section.

>  My main problem with this whole conversation is that I think the
> draft already says this - it just doesn't say "MUST NOT" because it
> *can't*.  

I think your are not looking hard enough for ambiguous language, and
considering how that language might be used in the future.  I'd ask that
you review our offline conversation between 3/28/2005 and 4/2/2005, if
you have it. Similar issues apply here as I drew your attention to then.

> If you feel the wording is too weak, and the editor is willing to
> incorporate your wording, minus the MUST NOTs, I have no objection to
> that.

And do you agre with the present wording if it is permissible to include 
the RFC2119 terms?

I do feel the wording is way too weak.  Basically, everyone should
consider that if this document is approved as is, and Administrator A
blocks your email because, e.g., it has the word "dialup" in the reverse
mapping entry, then Administrator A will refer to this document as proof
of the reasonableness of his actions.  Likewise, if the reverse mapping
doesn't exist, or doesn't "match" the forward mapping, etc, they will
also point to this document as justification for their behavior.  One
will be left trying to prove that the ambiguous statements don't mean
what Administrator A asserts they mean, a position that is very
difficult.

Consider the recent exchange between Robert Story and Ted Lemon,
supposing after this draft is approved.  As an exercise, try to show
that Administrator A, acting as Story described, has acted unreasonably
(as Lemon asserted)  when Administrator A can quote the text of this
draft in his defense.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Feb 2007 22:52:45 -0500 (EST)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 15 Feb 2007 00:17:36 -0500 (EST)

> >I am asking for a consensus call on the 3 statements I proposed.

[...]

> I am asking, based on what evidence are you asserting "most people",
> therefore "consensus"  has been achieved?

I've said History. You have access to the archives. Here are some:

Re: comment on draft-ietf-dnsop-inaddr-required-02.txt
by Kevin Darcy <[email-masked]>, Tue, 07 Aug 2001 
"But, why use reverse DNS at all? It leads to all sorts of bad security
practices, half-solutions to real problems (like the spam problem) and a
*false* sense of security."

At 10:01 PM 9/12/01, Kevin Darcy wrote:
>I oppose adoption/advancement of the draft. Not only are the security
>justifications null and void, I think they actually *detract* from the
>other justifications inasmuch as they promote/encourage bad security
>practices and/or risk creating a False Sense of Security.

Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt
by JINMEI Tatuya  Fri, 04 Apr 2003
"Secondly, if I don't misunderstand the intention, the draft says two
things:
[...]
"2. applications should not rely on reverse mapping for several
   purposes as they currently do.  The discouraged purposes include:
   - rejecting ftp/telnet connections just due to the lack of reverse
     mapping or failure of reverse-forward-reverse match.
   - filtering rule in TCP wrappers due to the lack of reverse mapping
   - regarding e-mail messages as spam if the sender address does not
     have a reverse mapping"

[JINMEI did misunderstand the draft's intention. It did not DIScourage
these things, it ENcouraged them. JINMEI agrees, as I do, that they
should be DIScouraged.]

Re: [dnsop] Tangible harm caused by in-addr-required draft
by Ted Lemon Fri, 1 Apr 2005 
"> Dean Anderson writes:
> Basically, this says its ok to use in-addr based security, and if they
> don't match, that's a "security concern".
>
> In other words, matching in-addr is required.

"This is a legitimate, specific criticism.   One that I haven't seen  
from you before on the mailing list.   I very much support fixing  
cases where the text can be misread in the way you suggest.   It  
would be disastrous if someone read the document the way you suggest,  
and I can see where someone could make that mistake, although it  
wasn't obvious to me until you pointed it out. [...]"

[Oddly, I had been saying that all along, but apparently Ted didn't see
it.]

There's more, but I've made the point.

Basically, many people have greatly misunderstood this document, and
when those misunderstandings are eventually illuminated for them, they
agree with me.  That is, except for those people who vehemently agree
with Robert Story's viewpoint, such as Mans Nielson and some others. The
proponents have gone from calling for 'in-addr required' in 2000
(document name and title), to assuring us they didn't mean that in-addr
was required despite the document name (but it really was required, they
just put it in the ambigous text), to where we are now (changing the
document name). I assert that these misunderstandings indicate ambiguity
in the text, and that the text must be very carefully examined to avoid
the 'disastrous results' (quoting Ted Lemon)  that would result from the
mistake.

The present authors have not eliminated the previous ambiguity, but have
merely changed the wording to different, but still ambiguous, statements
with the same disastrous effect as before---still supporting the notion
that in-addr is required for security, that it is reasonable to block
email based on 'dialup' in the name, or because there is no in-addr RR,
etc (see section 4 of the current draft).

This document has not achieved consensus for many years (7 years?)  
because no one agrees with (eg) Robert Story's views, and once it become
clear the document endorses that view, it is sent back for revision.  
Perhaps you've forgotton some things:

Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt
by Ed Lewis Fri, 4 Apr 2003
"I'd recommend only working on the document if the tone is of a report 
on the current state of affairs and not that of a mission statement 
to fix the ills of a broken reverse map.  The former is useful and 
closure can be reached, the latter a rat hole without bottom."

Seems Section 4 of the current draft are just such 'ills of a broken
reverse map'. Of course, its not really "broken", it just doesn't
conform to the 1:1 scheme that the anti-spammers want everyone to use
and want the DNSOP WG to approve and encourage.

I hope I've jogged your memory, and cleared up a few things.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 15 Feb 2007 00:17:36 -0500 (EST)

[...]

		--Dean

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Feb 2007 23:00:40 -0700

On Feb 14, 2007, at 10:17 PM, Dean Anderson wrote:
> Basically, many people have greatly misunderstood this document,

That people have misunderstood the document is your assertion, which  
may or may not be true.   That people agree that using in-addr for  
security is clearly true, as your quotations suggest.   However, your  
primary assertion - that people have misunderstood the document in  
the way that you assert - remains unproven.

I do not object to making the document clearer, if good replacement  
text is offered in a timely fashion.   But I don't agree with you  
that the document is unclear - it seems pretty clear to me.   Clearer  
is always better, and if you can help to make that happen I'm all in  
favor.   But there is a side of this about which you are not talking,  
and it's important.   My concern, and probably Ed's as well, is that  
these repeated amendments are simply wasting time, and not adding value.

So my position is that if you can quickly offer an amendment to the  
existing draft that clearly makes the text better than it already is,  
and then you will be happy, I would like for that to happen.   And if  
you can suggest text to cut that you think is unnecessary, and we can  
quickly agree that that is so, I'm okay with that too.   But if you  
want to submit and debate a whole new draft, or you want to continue  
the debate into 2009 (since you are referencing conversations from  
2005), and that's going to keep this in the hopper, I would like for  
that to not happen.   We have been discussing this draft for a long  
time.   It's a draft that I think adds value as it is.   We do not  
need to keep discussing it for another two years.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Feb 2007 23:00:40 -0700

---

From: Andras Salamon <[email-masked]>
Date: Thu, 15 Feb 2007 11:44:26 +0000

On Wed, Feb 14, 2007 at 11:00:40PM -0700, Ted Lemon wrote:
> We have been discussing this draft for a long  

Agreed.  Let's ship.

-- Andras Salamon                   [email-masked]

---

From: Andras Salamon <[email-masked]>
Date: Thu, 15 Feb 2007 11:44:26 +0000

Agreed.  Let's ship.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 15 Feb 2007 22:18:54 +0900

>>>>> On Tue, 6 Feb 2007 09:43:18 -0500, 
>>>>> Andrew Sullivan <[email-masked]> said:

> strategy, and they ought to be taken into consideration.

Okay, that was actually what I thought, while being confused, was the
intent of this document.  On top of the understanding that this
document actually supports the second view rather than being neutral,
I have next concern.  The problem of this stance is that this document
does not explain (at least not to me) why the following is justified:

> site B on the basis of reverse mappings,

> but that, on balance, unless

Perhaps the intent is to explain it in Section 3.3, but they are
basically just "there are applications that make decisions about site
X on the basis of reverse mappings".  In particular, it does not
answer the question of how the behavior of such applications is valid.

On the other hand, Section 4.2 (seems to) indicate such usage is
not really valid: 

   Operators and users are reminded that the use
   of the reverse tree, sometimes in conjunction with a lookup of the
   name resulting from the PTR record, provides no real security, can
   lead to erroneous results and generally just increases load on DNS
   servers.

It would be okay if this document took a neutral position describing
two controversial views.  But since it is going to support, even
mildly, one particular view, it should provide why it's justified in a
convincing way.

Perhaps the following part of the intent was expected to be used as an
excuse:

> _but_, the administrator of
> strategy,

but at least to me it's not enough; a "caution" can easily be ignored,
particularly when one is told "it is perfectly entitled to do it".

So...

> say.  If the answer is, "No," then I'm not sure what we can say about

sorry, but the answer is "No" to me.  And I tend to agree that it'll
be not really sure whether we can say anything (as I indicated my
previous message), but I can still see some options:

1. update the draft with the opposite (first) view.  This is basically
   what I proposed in my previous message, and I believe it can
   explain why one should do this although I admit I'm biased on this
   point.

2. keep the current position (i.e, support the second view), but
   explain why the recommendation is justified despite the description
   against it (which must be more than "because there are such
   applications").

   BTW: if we keep this view, the abstract and the Introduction should
   be clearer on this; currently, these read as if this document
   simply talks about issues regarding reverse mappings in a neutral
   position.  This is actually one of the reasons why I was confused
   about the purpose of this document.

3. update the draft without supporting any view, in a neutral
   position.  In that case, we'll probably simply make "cautions" of
   not-providing and relying on reverse mappings equally rather than
   making specific recommendations.  As you indicated above, this
   approach may weaken the value of this document, but since this
   seems to be a subtle, controversial issue, I think it's the most
   balanced compromise.

Not sure how many of others agree with me, but I'm happy to volunteer
to provide suggested text for option 1 or 3.

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 15 Feb 2007 22:18:54 +0900

So...

					JINMEI, Tatuya

---

From: Robert Story <[email-masked]>
Date: Thu, 15 Feb 2007 11:22:54 -0500

On Wed, 14 Feb 2007 22:52:45 -0500 (EST) Dean wrote:
DA> As an exercise, try to show
DA> that Administrator A, acting as Story described, has acted unreasonably
DA> (as Lemon asserted)  when Administrator A can quote the text of this
DA> draft in his defense.

Let's do two exercises. Given a document with the wording your
propose, try and convince Administrator A that he MUST NOT use a system
that he's already determined to effective.

I think saying apps SHOULD NOT depend on reverse mapping is ok; the
rfc 2119 definition still allows administrators to decide to use it in
their environment, however unreasonable that seems to others.

DA> I do feel the wording is way too weak.  Basically, everyone should
DA> consider that if this document is approved as is, and Administrator A
DA> blocks your email because, e.g., it has the word "dialup" in the reverse
DA> mapping entry, then Administrator A will refer to this document as proof
DA> of the reasonableness of his actions.

They don't need this document for that. All they need is their own
statistics on the percentage of dialup or dynamic host spewing SPAM.
You keep going on about how reverse DNS isn't proof of security and
pointing your finger at me. But the example I gave is not using it to
provide security - it is using it as proof of insecurity. 

DA> Likewise, if the reverse mapping doesn't exist,
DA> or doesn't "match" the forward mapping, etc, they will
DA> also point to this document as justification for their behavior.

Forward Confirmed reverse DNS is an entirely different beast. I would
be in favor of the document have strong wording against this type of
check, because there are very good reasons why an ip address might be
associated with multiple domains. Anyone who tries using this method
would quickly for email would quickly find out it's a bad idea (see
http://news.com.com/2100-1023-982118.html).

---

From: Robert Story <[email-masked]>
Date: Thu, 15 Feb 2007 11:22:54 -0500

---

From: Dean Anderson <[email-masked]>
Date: Fri, 16 Feb 2007 11:44:36 -0500 (EST)

> the way that you assert - remains unproven.

It certainly has been proven, repeatedly over the last 7 years that this
draft has been on the table. They have two issues that don't belong, and
which they keep trying to put in:

1  in-addr should be required.

2  forward/reverse checking is a legitimate security test.

Over the course of 7 years, The authors first said these things bluntly
in draft-in-addr-required, with a title that said in-addr was required.
That was rejected by the Working Group.  Since then, they have
alternately said that they aren't making these claims, and then when
called to task--'here are the claims again in your document'--they say,
as recently, that they want to encourage this viewpoint.  Rather that
giving a rational, logical reason for their views, they have argued that
one is __entitled__ to act without a rational basis. That is,
irrationally.   Of course, the IETF should not encourage irrational 
behavior by allowing it to be implied to be rational.

My point that a number of people (that includes Ted Lemon in particular)
have misunderstood the the document was proven (in particular to Ted
Lemon) in 2005. Apparently you (Ted) have no memory of our last
conversation on this subject in 2005:  You agreed in 2005 that people
misunderstood the document as I had said in 2005:

You said then:
==================

==================

You said 'This is a legitimate, specific criticism'.  I had been saying
that all along in 2005, but apparently you didn't understand that then,
as you apparently don't understand it now.  But I eventually did get the
point across to you in 2005. I hope to get it across again. If you need
more of the conversation to jog your memory, I'll be happy to give links
to the original messages.

But, maybe I've assumed to much. I'll try to make it more explicit:

The document _still_ seeks to make the in-addr map required, and _still_
seeks to describe in-addr mapping as useful for security purposes.  
Persons reading this document, especially those persons inexperienced
with the past history of these claims, will get the idea that these
practices are required, and that in-addr is useful for security
purposes.

I note this text from Section 4, 4th paragraph, 1st sentence:

  "All IP addresses in use within a block should have a reverse 
mapping."

This is the old in-addr-is-required claim.  If in-addr really is
required, why make them change the title and even the document name? 
This statement, in conjunction with the advocacy that missing reverse 
DNS is a legitimate security concern, implies that in-addr is required.

Take this example from Section 3.1, Second paragraph:

   Some applications use DNS lookups for security checks.  To ensure
   validity of claimed names, some applications will look up records in
   the reverse tree to get names, and then look up the resultant name to
   see if it maps back to the address originally known.  Failure to
   resolve matching names is interpreted as a potential security
   concern.

Most people would read this as an endorsement of the use of DNS for
security checks.  It implies there is some legitimacy to this practice.  
Further, it implies that operator has no choice. I know of no
applications which perform such a check without a configurable choice.  
The only example was TCP wrappers, which _can_be_ configured this way.  

Look at the last sentence: 

   "Failure to resolve matching names is interpreted as a potential
security concern".

Thats the same old thing as before.

How about the phrase "To ensure validity"?  How is validity ensured?  
If the first DNS query was faked [by a variety of methods, including
brute force or inline sniffing], how is it now the second one is
trustworthy? Obviously, it isn't, and just as obviously there is no 
validity or legitimacy to the claim.  Kevin Darcy had it right in 2001, 
this draft is no good.

This is the same notion of 'legitimate security concern' that
in-addr-required had in 2005, for which you then said was a legitimate
complaint about the draft.  The draft is __filled__ with this kind of
stuff.

This is a good point to note that the draft claims in Section 3.1:

   "Some anti-spam (anti junk email) systems use the reverse tree to
   verify the presence of a PTR record, or validate the PTR value points
   back to the same address as the system originating the mail.  Some
   mail servers have the ability to perform such checks at the time of
   negotiation, and to reject all mail from hosts that do not have
   matching reverse mappings for their hostnames.  These PTR checks
   sometimes include databases of well-known conventions for "generic
   naming" conventions (for example, PTR records for dynamically-
   assigned hostnames and IP addresses), and sometimes allow complicated
   rules for quarantining or filtering mail from unknown or suspect
   sources.  Even very large ISPs may reserve the right to refuse mail
   from hosts without a reverse mapping."

Note that the 'dialup' in the name (Robert Story's example, which you
noted was unreasonable) is a "generic naming" convention.  [I note that
not even the authors do this.**]

Note the last sentence:

  "Even very large ISPs may reserve the right to refuse mail from hosts
   without a reverse mapping."

Most people would read this as saying that large ISPs refuse mail from
hosts without a reverse mapping, which just isn't so.  [again, neither
of the authors' refuse mail based on missing reverse mapping.**]

A close parsing of the sentence, however, shows it to be entirely
meaningless: 'Even very large ISPs' _could_ reserve the right to do just
about anything--Indeed, any one can _reserve_ any right. Its the
exercise that may cause problems.  Such meaningless statements should be
removed, especially where they are very likely to be misread.  Have you
really read the draft to identify and remove such statements? [Btw, to
"critically read" a document, means you are supposed to search out
ambiguities in the document, identify for removal or rewording such
meaningless sentences that will be misparsed and misread;  Find things
that different people might take to mean different things;  To critique
the document.]

For the previous draft, I posted a list of such dubious claims, but
received no response justifying the claims. This new draft was posted
that contained basically the same dubious claims slightly reworded, but
with the same objected implications as before, on the assurance that
objections had been addressed.  Obviously, they keep trying to work in
the same two objectionable ideas. Those ideas don't belong in the
document.  

Just because the same dubious claims keep being resubmitted does not
mean this Working Group should just approve the draft. It could also
start refusing to consider new drafts from these authors. The authors 
obviously refuse to remove the objected notions.

I argued in 2003 that we shouldn't accept any more drafts on the
subject, but Ed Lewis stated then that there is an interest and a need
for a report on the current state of affairs. I can accept a report on
the current state of affairs, but I can't accept the two false premises
the authors keep trying to more or less sureptitiously work into the
document in various ways.

I think the onus is not on me to prove that each subsequent new document
contains similar statements as previously, but should be on the authors
to prove that it doesn't----that they actually removed objectionable
statements and claims. 

The reason I'm writing an alternate draft is that many people, myself
included, think there should be some statement about the current state
of affairs. My draft will omit the agenda of trying to legitimize
irrational reverse-mapping claims of zealots, and instead show why
commonly occuring irrational claims about reverse mapping are not
rational and should be discouraged.

		--Dean

** I took off the reverse mapping for cirrus, and did some testing:

[root@cirrus tmp]# dig mx senie.com 

; <<>> DiG 9.2.1 <<>> mx senie.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56611
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;senie.com.                     IN      MX

;; ANSWER SECTION:
senie.com.              3600    IN      MX      5 mxb.amaranth.net.

;; Query time: 211 msec
;; SERVER: 130.105.11.3#53(130.105.11.3)
;; WHEN: Fri Feb 16 11:19:30 2007
;; MSG SIZE  rcvd: 59

telnet mxb.amaranth.net. 25
Trying 204.10.1.19...
Connected to mxb.amaranth.net..
Escape character is '^]'.
220 mxb.amaranth.net ESMTP (44a2b828e188d015a20a7f64ac843dc6)
helo av8.net
250 mxb.amaranth.net
mail from: <[email-masked]>
250 Ok
rcpt to: <[email-masked]>
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
Hi Dan. Just testing.

  --Dean
.
250 Ok: queued as 24D2B53F3

dig mx ca.afilias.info

; <<>> DiG 9.2.1 <<>> mx ca.afilias.info
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23227
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ca.afilias.info.               IN      MX

;; ANSWER SECTION:
ca.afilias.info.        300     IN      MX      20 
antispam2.afilias.info.
ca.afilias.info.        300     IN      MX      10 
antispam.afilias.info.

;; Query time: 100 msec
;; SERVER: 198.3.136.10#53(198.3.136.10)
;; WHEN: Fri Feb 16 11:21:31 2007
;; MSG SIZE  rcvd: 84

[root@cirrus tmp]# telnet antispam.afilias.info 25
Trying 207.219.45.36...
Connected to antispam.afilias.info.
Escape character is '^]'.
220 antispam.ca.afilias.info ESMTP (89f05a796082cd6312c69e8fa318f08f)
helo av8.net
250 antispam.ca.afilias.info
mail from: <[email-masked]>
250 Ok
rcpt to: <[email-masked]>
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
Hi Andrew. Just testing.

  --Dean
.
250 Ok: queued as DCC3285DD
quit
221 Bye
Connection closed by foreign host.

[root@cirrus tmp]# dig cirrus.av8.net

; <<>> DiG 9.2.1 <<>> cirrus.av8.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36728
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cirrus.av8.net.                        IN      A

;; ANSWER SECTION:
cirrus.av8.net.         3600    IN      A       130.105.36.66

;; Query time: 8 msec
;; SERVER: 198.3.136.10#53(198.3.136.10)
;; WHEN: Fri Feb 16 11:24:30 2007
;; MSG SIZE  rcvd: 48

[root@cirrus tmp]# dig -x 130.105.36.66

; <<>> DiG 9.2.1 <<>> -x 130.105.36.66
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46245
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;66.36.105.130.in-addr.arpa.    IN      PTR

;; Query time: 9 msec
;; SERVER: 198.3.136.10#53(198.3.136.10)
;; WHEN: Fri Feb 16 11:24:42 2007
;; MSG SIZE  rcvd: 44

---

From: Dean Anderson <[email-masked]>
Date: Fri, 16 Feb 2007 11:44:36 -0500 (EST)

You said then:
==================

Note the last sentence:

		--Dean

;; QUESTION SECTION:
;senie.com.                     IN      MX

;; ANSWER SECTION:

;; Query time: 211 msec

  --Dean
.

dig mx ca.afilias.info

;; QUESTION SECTION:
;ca.afilias.info.               IN      MX

;; ANSWER SECTION:

;; Query time: 100 msec

  --Dean
.

;; QUESTION SECTION:
;cirrus.av8.net.                        IN      A

;; ANSWER SECTION:

;; Query time: 8 msec

;; QUESTION SECTION:

;; Query time: 9 msec

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 16 Feb 2007 17:30:58 -0500

> I asked this before and got no answer. RFC2119 itself gives some

I don't think that's exactly true.  I pointed out that, as far as I
know, this document is intended to be an informational document, which
means that it will not specify any standards.  I asked for advice (or
dissent) from our colleagues on this list, and received nothing, so I
assume that others agree.  The relevant bits of [RFC2119] are ones you

> potential for causing harm.  

So far as I can see, you haven't demonstrated that the "harm" you are
talking about is the same as the "harm" that 2119 is talking about.
That is, you might think it a foolish thing to draw any conclusions
from reverse tree data; that does not mean that others, with different
experiences or situations, would in their cases reach the same
conclusion.  I believe the draft allows both cases to be considered.
Therefore, this is not "harm to the Internet" in the way that the
example "limiting retransmissions" suggests.  If you can provide an
argument that reaches that threshold, I'm willing to reconsider my
view.  But so far, I haven't seen one.

By the way, I apologise to all that I haven't sent the updated draft
this week; I got waylaid by another task.  I hope I'll be able to
redress this either this weekend or early next week.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 16 Feb 2007 17:30:58 -0500

A

---

From: Dean Anderson <[email-masked]>
Date: Sun, 18 Feb 2007 01:11:15 -0500 (EST)

On Fri, 16 Feb 2007, Andrew Sullivan wrote:

> means that it will not specify any standards.  

While this fact is true, this fact isn't relevant to the question posed.

On January 8, 2007, I posted a list of examples of published
informational RFCs that include this language. That demonstrates that
RFC2119 language is allowed in informational RFC's.

> I asked for advice (or dissent) from our colleagues on this list, and
> received nothing, so I assume that others agree.  The relevant bits of
> [RFC2119] are ones you actually quote:

Silence is agreement? Perhaps silence means they agree with me.  I take
silence to mean that no one claims to know the authoritative answer.  
But the chairs did not respond, and it was their guidance I was
expecting.

> talking about is the same as the "harm" that 2119 is talking about.

Security vulnerabilities are included as harms that 2119 is talking
about. You haven't refuted the statements I proposed putting in the
Security Considerations section.  I suggest you also review the thread
entitled "Tangible harm caused by in-addr-required ". Rather than repeat
that thread in its entirety, I think this comment by Kevin Darcy is
still quite pertinent:

> conclusion.  

Indeed, logic does mean that other rational persons would reach the same
logical conclusions.  Mathematical logic doesn't change due to
experience or situation which are irrelevant to the assertions. The only
relevant issue here is that Administrator A has no authority over Site
B, and that doesn't change due to the experience or situation of
Administrator A.

This is exactly the distinction between rational and irrational. Others,
as I have recited, have proved that such conclusions aren't logically
grounded.  There are no experiences or situations where security
conclusions can be logically drawn from the reverse mapping of another
site.

You haven't proved such conclusions are logically grounded in any
situation involving other sites. You haven't cited any flaws in the
logic.  Your defense is to assert that one is _entitled_ to act
irrationally.  One may be entitled, as a free person, to act
irrationally, but one is not entitled to describe irrational acts as
being rational in a professional document.  Doing so makes the document
a fiction--a charade rather than truth.

> I believe the draft allows both cases to be considered.

Every case can be considered. However, the irrational cases have to be
described as being irrational, using terms that would imply or
specifically state the irrationality. You describe them as rational,
which is misleading and confusing.  

I think your choice is to either drop them altogether (as Ed Lewis
suggested in 2003), or describe them accurately as being irrational and
unjustified by any facts or logic.  I think history has shown you will
willfully refuse to do either of these alternatives.  Including
misleading descriptions will lead to well-justified objections.  Of
course, the third option is to drop the draft in favor of another draft.
I support that approach, and will shortly be submitting an alternate
document for consideration.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sun, 18 Feb 2007 01:11:15 -0500 (EST)

--Dean

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Feb 2007 18:23:53 -0500

Hi Dean,

> RFC2119 language is allowed in informational RFC's.

In my view, it is not completely relevant what has been tolerated
historically.  The only question in my opinion is what RFC 2119 says
it is intended to do.  Since it says that it is intended to be used
for standards, and since this draft does not propose any standard for
the Internet community, I can't see how RFC 2119 language ought to be
used.

> Security Considerations section.  

I didn't see anything to refute.  I said so, I think, especially in
<http://www1.ietf.org/mail-archive/web/dnsop/current/msg00056.html>.
I know that I asked why you thought your formulation was better than
what is in the draft, and you said that the draft is ambiguous.  I
asked the community whether they agreed, which is how we got this
thread.

For what it's worth, I think you have used the word "ambiguous" to
mean "does not say something I agree with".  It is probably true that
the draft does not say unequivocally, "You should do _X_."  I think
that is correct: I don't believe that there is one right answer for
all cases with respect to reverse mappings.  I think that there are
cases where adding more PTRs will do more harm than good.  That said,
in most cases I think it is possibly useful for other users on the
Internet if people maintain matching reverse mappings for their hosts;
and, to the extent interoperation is aided by possibly useful things,
we should therefore come down mildly in favour of such things.

> experience or situation which are irrelevant to the assertions. 

[. . .]

> This is exactly the distinction between rational and irrational. 

I'm afraid that you have fallen into equating "rational" and
"logical".  They are not the same thing, as we can see by considering
the difference between deductive and inductive reasoning.  The current
discussion cannot be resolved exclusively with deductive reasoning,
because we are discussing individual administrators' decisions about
how to respond to traffic arriving at their networks, on the basis of
an admittedly poor metric.  That poor metric's results are to be
evaluated in light of other evidence; I think the draft already says
as much.  (I have made some edits that will appear in the -02 draft --
to be uploaded as soon as Daniel and I have agreed on the final words
-- to strengthen that message, because of the feedback the group has
provided, but -02 will not say anything substantively different than
it already says, I think.  These edits are in addition to the changes
I already committed to.)

It is not irrational to make decisions on the basis of imperfect
evidence.  Nearly every empirical conclusion works the same way.  (Try
using mathematical logic against Berkelian idealism.  For that matter,
we have plenty of reason to believe that the data Kepler was working
with was not terribly good; he was nevertheless right.)  And in our
world, where different people are trying to solve different problems
on the basis of the same poor evidence, I think it not at all
surprising that rational people reach different conclusions even in
light of the same evidence.

You seem to believe that using the reverse tree in decision making in
some of these cases is always wrong.  Other users with relevant
experience &c. have reached a different conclusion, presumably on the
basis of their experience and the evidence at their disposal.  This
difference is why the draft generally tries to argue both that people
should provide reverse mappings all else being equal, and also that
people shouldn't put too much stock in the non-existence or
non-matching of the reverse data.

I hope this makes it clearer to you why the draft takes the approach
it does.  

Best regards,
A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Feb 2007 18:23:53 -0500

Hi Dean,

[. . .]

Best regards,
A