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

From: [email-masked]
Date: Wed, 03 Jan 2007 15:50:01 -0500

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-01.txt
	Pages		: 10
	Date		: 2007-1-3
	
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
   outline what should be taken into account when deciding whether to
   implement reverse mappings of addresses to names.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reverse-mapping-considerations-01.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-01.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-01.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: Andrew Sullivan <[email-masked]>
Date: Wed, 3 Jan 2007 16:26:23 -0500

Dear colleagues,

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

This version of the draft is our attempt to address all the comments
we received on the list and in San Diego about the -00 draft.  The
text that I originally proposed on the list for issue 10 has been
mostly replaced by that which emerged from Ed Lewis's discussion of
the issue.  I hope it is better this way.

Any comments are, as always, welcome.  Thanks very much.

A

-- 
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: Wed, 3 Jan 2007 16:26:23 -0500

Dear colleagues,

A

---

From: Dean Anderson <[email-masked]>
Date: Thu, 4 Jan 2007 13:15:56 -0500 (EST)

This is nearly a straight rehash of the ill-fated in-addr draft.   As 
with that draft, there is a fundamental wrong assumption embedded in the 
draft, as exemplified in this sentence of Section 4.1:

   In general, the DNS response to a reverse map query for an address
   ought to reflect what is supposed to be seen at the address by the
   machine initiating the query.

There is no exact definition of "what is supposed to be seen at the
address by the machine initiating the query".  This incorrect assertion
is at the very heart of the mistaken uses of 'reverse DNS as security
mechanism'.  The correct answer to "what is supposed to be seen" is
_site_ dependent.  Those who think there is some "universally correct"
answer have no legitimate foundation for that belief. They are really
just trying to impose their _site's_ practices on everyone else in the
belief that if everyone else did what they did, they could use reverse
DNS for security or anti-spam or some such.  The ends, however, cannot
be achieved even if everyone were to adopt their practices. [ignoring
the fact that some sites cannot adopt those practices and have very good
reasons for their different practices.]

This draft merely uses different words to express the same wrong ideas
and assertions as did the previous in-addr draft. The same objections
that applied to the previous in-addr draft apply to this draft.

Is the working group seriously considering this draft? I must have
missed it on the agenda. (though I note the archive only goes back 
to 11/30/06)  I've been busy, recently.

		--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: Thu, 4 Jan 2007 13:15:56 -0500 (EST)

--Dean

---

From: Joe Abley <[email-masked]>
Date: Thu, 4 Jan 2007 14:01:57 -0500

On 4-Jan-2007, at 13:15, Dean Anderson wrote:

> address by the machine initiating the query".

I'm not sure I understand why you think this is a problem.

> The correct answer to "what is supposed to be seen" is
> _site_ dependent.

Assuming you mean the site responsible for the address concerned,  
then surely this presents no great problem.

If you mean that every other site on the Internet ought to be able to  
assert its own policy on the name associated with a remote address,  
then that seems like an unusual perspective.

Perhaps you could clarify.

> to 11/30/06)  I've been busy, recently.

You might like to review the minutes of the meeting in Montreal.

Joe

---

From: Joe Abley <[email-masked]>
Date: Thu, 4 Jan 2007 14:01:57 -0500

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Jan 2007 14:24:18 -0500

Hi Dean,

On Thu, Jan 04, 2007 at 01:15:56PM -0500, Dean Anderson wrote:
> This is nearly a straight rehash of the ill-fated in-addr draft.   

Since as a matter of history it's a revival of that draft under a
different filename (as some people objected to the "required"), that
shouldn't be too surprising.

> mechanism'.  The correct answer to "what is supposed to be seen" is

The point of the "supposed to" and "by the machine initiating the query"
language is precisely to capture that site dependency that you,
quite correctly, point out.  If you have another way to state that, a
patch to the text is welcome.  If you think it's unclear, please
suggest the language that will make that intention clearer.  

> Those who think there is some "universally correct" answer have no
> legitimate foundation for that belief.

Of course there is no universally correct answer; see above.  What I
claim is true, though, is this: since DNS is deterministic, there is
a right answer to every _particular_ query, when the particulars of
the query include its origin. 

> DNS for security or anti-spam or some such.  The ends, however, cannot

I think the draft says that you should not rely on reverse DNS for
security, and that more importantly, if you decide to, you'd better
be aware of the consequences.  If that isn't clear, please tell me
where I can make it clearer.

> reasons for their different practices.]

And I think the draft _also_ says that there may indeed be some cases
where those different practices are in fact a good idea.  We've
included some.  If you have some more examples, please send them
along so that we can include them.  Text is welcome and encouraged. 
The point of this draft is not to say, "Thou shalt provide reverse
mapping."  It _is_ to say that, on balance, the reverse tree is
potentially useful, and that therefore site administrators should
think very hard before they neglect its maintenance.  Similarly, it
is trying to say that, since some sites might make that determination
for good reasons, and that since other sites might just be careless,
one should think pretty hard about using the reverse tree as any sort
of guarantor of anything.

> to 11/30/06)  I've been busy, recently.

I did discuss this at the San Diego meeting, and I note the
discussion made it into the jabber notes and the minutes.  I also have
put all the issues into the tracker, so you could have a look at
them there if you'd like.  

Best regards,
A

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Jan 2007 14:24:18 -0500

Hi Dean,

Best regards,
A

---

From: Edward Lewis <[email-masked]>
Date: Thu, 4 Jan 2007 14:27:16 -0500

>reasons for their different practices.]

I can speak to the motivation of this because I think I was the one 
that suggested the words.

The motivation had nothing to do with security.  Your point is well 
taken and I agree that there is little value in the reverse map in 
providing security.  (Arguably, some value, not enough to justify the 
expense certainly.)  But the vagueness ot the text is borne from 
other observed uses of DNS, for example Akamization and what some 
call "directional DNS".  There are folks that purposefully answer 
differently based on where a query comes from.  It can be argued that 
these folks are violating coherency and they can retort that no, they 
are abusing dynamic update (with a wink).  Whatever, it happens, and 
we need to recognize reality and not try to argue theory.

The other scenario I had in mind was split-DNS, in which I answer 
with more detail to my own machines than the Internet. Such as -
Inside: 8.88.888.202.in-addr.arpa PTR amadeus.perl.example.
Outside: 8.88.888.202.in-addr.arpa PTR machine888888.perl.example.

The "outside" isn't always to hide the inside machine's true 
identity, but this makes transitions inside transparent to the 
outside.  Especially if the inside is using some kind of dynamic 
update via DHCP and I just don't want to deal with that headache 
outside my firewall.

I think you are right in discounting the notion of "universally 
correct" answers.  But if so, I would think you would even more agree 
with the words as stated.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 4 Jan 2007 14:27:16 -0500

---

From: Dean Anderson <[email-masked]>
Date: Fri, 5 Jan 2007 14:42:03 -0500 (EST)

> I'm not sure I understand why you think this is a problem.

I suggest you review the (or your personal) archives of the in-addr
discussion.  This was all discussed.  I think you participated, if
memory serves.

> then surely this presents no great problem.

That is exactly the problem.  To refresh and review:

The debate is over "the right answer" given for reverse DNS queries.  
The position of the "security/spam" crowd is that no reverse anwser is
wrong, and that if forward doesn't match reverse, that is also wrong.
They assert that matching forward/reverse imply security and
trustworthiness, at least for spam filtering.

The opposing position is that any PTR answer is optional, and that there
is no rule that says reverse and forward must match; that there are
cases where it is convenient and useful for forward and reverse not to
match.  There are also very good reasons for having no reverse DNS (cost
being only one), and there is no reason for considering the absence of
matching forward/reverse to be insecure or untrustworthy.  Further,
there is no inference of security when forward/reverse do match, and the
use of such an inference is itself a security _vulnerability_ that
should be highlighted as a _bad_ practice rather than encouraged.

PTR records are also more impractical in IPV6, certainly more expensive,
and there was some talk they may even be removed altogether in favor of
the HOSTINFO ICMP. [This is somewhat old, and I haven't checked this in
a while--there may be an update---I'll try to look into this next week.]
[NB: I rather favor the HOSTINFO ICMP approach, since the information is
always there and doesn't depend on DNS which may not be available during
a network outage. Network outages are when I find reverse DNS
information most helpful]

If I left out anything important in this short summary of a long
discussion, I apologize.  Hopefully, this jogs your memory.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 5 Jan 2007 14:42:03 -0500 (EST)

--Dean

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Jan 2007 15:10:39 -0500

> The debate is over "the right answer" given for reverse DNS queries.  

I don't think there is anywhere in the draft where anything says
there is "the right answer" for reverse DNS queries.  If you have
found text that says that in the current draft, please point out
exactly where it says that.  I responded yesterday to your claim
about this, pointing out that the text is at least supposed to say
something rather different to that, and that I would value
suggestions on how to make that intention clearer.

Moreover,

> wrong, 

> The opposing position is that any PTR answer is optional, 

I think you have a false dichotomy here.  The draft is intended to
say that on the whole, it is generally best if the reverse tree
works, because the reverse tree can be useful in a number of cases.
(I note that in your description, you have addressed not at all any
of the discussion, contributed by Paul Wouters, of key-publishing
cases, particularly in the presence of DNSSEC.)  That said, there are
nevertheless at least some cases where it is legitimate to decide
that a reverse mapping for a given case is a bad idea.  We have some
examples in the doc.  I would be happy to include more such examples
if someone provided me with an argument that they exist.

> PTR records are also more impractical in IPV6, certainly more expensive,

I believe the document includes some discussion of these differences,
and also points to some considerations about tools for reverse tree
management under IPv6.  If there is more you would like to add,
please send some text.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Jan 2007 15:10:39 -0500

Moreover,

A

---

From: Dean Anderson <[email-masked]>
Date: Fri, 5 Jan 2007 15:13:02 -0500 (EST)

> expense certainly.)  

Hmm. So, the word change had nothing to do with security. The draft and
its advocates _do_ still assert that there is security in matching
forward/reverse.  The IETF can't change their belief, but it can avoid
the use of vague language with dual interpretations that is designed to
support that belief.

> But the vagueness ot the text is borne from other observed uses of
> DNS, for example Akamization and what some call "directional DNS".  
> There are folks that purposefully answer differently based on where a
> query comes from.  It can be argued that these folks are violating
> coherency and they can retort that no, they are abusing dynamic update
> (with a wink).  Whatever, it happens, and we need to recognize reality
> and not try to argue theory.

Akamization or (directional DNS) has nothing to do with reverse DNS.  
They give out different A records depending on the query source.  
Frankly, I can see nothing wrong with this, either.  Some people object
to this practice, but their objection can't be founded in the text of
existing DNS RFCs.  The coherency argument is a red-herring, since a
long-cached record only "hurts" akamai, not anyone else. Akamai, etc can
give out 0 TTL records to avoid that, if they choose to.  It doesn't
seem that transforming the in-addr draft will provide text that makes
this behavior non-standard.  If that is the goal of this draft, then it
is really coming in "under the radar".  I don't read the text of this
draft as affecting directional DNS.

> update via DHCP and I just don't want to deal with that headache 

{suggestion: run two sets of nameservers, one set with public 
information, and another set with inside information}

Regarding the draft: Same as above for directional DNS. The split-dns
purpose seems to be "under the radar", and the text of this draft
doesn't seem to alter the issue of split-DNS.

> with the words as stated.

You are discussing issues of "universial consistency" of many/all types
of records. I am concerned about the definition of "correct PTR
response".

---

From: Dean Anderson <[email-masked]>
Date: Fri, 5 Jan 2007 15:13:02 -0500 (EST)

---

From: Edward Lewis <[email-masked]>
Date: Fri, 5 Jan 2007 15:44:57 -0500

>information, and another set with inside information}

Well that's one solution.  (Or using implementation-specific features 
that modify responses based on query ancillary data or other 
factors.)  If you drew that conclusion based on the draft and the 
thread here, I would think then that you are in support of the words.

>of records. I am concerned about the definition of "correct PTR

A protocol can't be specified to give out "correct" answers because 
it is impossible to know what is "correct."  What if the 
administrator has made a typographic error?  Is it up to the protocol 
to fix that?

The point is - the DNS ought to give out the answers that "make 
sense."  That's all.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Fri, 5 Jan 2007 15:44:57 -0500

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Jan 2007 16:05:35 -0500

Hi Dean,

On Fri, Jan 05, 2007 at 03:13:02PM -0500, Dean Anderson wrote:

> forward/reverse.  

As one of the editors of the draft, I would very much appreciate
quotes from the text to back up your claim of what it is asserting. 
I don't believe the draft says what you claim; indeed, I think
that statements in sections 3.2, 4.2, 4.3, and 5 are pretty clear.

If you are unwilling to provide evidence that the document says what
you claim it does, I can see no reason to take seriously your
objections: they appear to be based on either an incomplete reading
of the text, a complete misunderstanding of it, or a refusal to
address the complete text.  If, on the other hand, you provide such
evidence, I am more than happy to attempt to address your concerns.

Best regards,
A

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Jan 2007 16:05:35 -0500

Hi Dean,

Best regards,
A

---

From: Dean Anderson <[email-masked]>
Date: Fri, 5 Jan 2007 16:29:13 -0500 (EST)

> shouldn't be too surprising.

That's good the title has changed, then. I'm glad for that.  I thought
the draft was dropped, but I must have been mistaken.

> suggest the language that will make that intention clearer.  

Right. The disagreement is that your camp thinks there must be an
affirmative answer to a PTR query that must match a forward name, where
my camp asserts that NXdomain is proper response, and that no matching
forward is also correct.  Obviously, changing your words will not
resolve this disagreement. [I seem to recall a 10+message exchange where
different words expressing the same notion were proposed]

It is not the description of your notion that is disputed. It it the
notion itself.

Somewhat, over time your camp may have moderated the notion from "MUST"  
to "SHOULD", but "SHOULD" is still incorrect:  Reverse records are
entirely optional.  Matching reverse with forward is entirely optional.
It is perfectly valid to give (eg) the very same contents (eg "av8.com")
for every reverse record. Or not have any reverse records at all. No bad
things should result from any of these practices or any other reverse
practice.  

I've seen admins claim that PTR records of the form
"h-11-22-33-44.somedomain.com" are suspicious.  This is complete
nonsense---emphasize "complete", because there is no valid assumption
for what might or might not be "suspicious" or untrustworthy
_whatsoever_. This message needs to very clear and prominent in any
draft encouraging reverse DNS use.

> the query include its origin. 

Technically, DNS is not deterministic:  Caches can quite naturally give
out different answers to same query depending on when they queried the
authority and how long they have cached that response. [not only can the
principal answer change, but the TTL can also change] So the answer you
get depends on the cache chosen, and this may be done at random.
[indeed, I've found that a surprising number of caches don't respect
TTLs. Anycast'd caches are even more non-deterministic]

There are no definitely right answers.  There are only definitely wrong
answers: those that originate from somewhere other than the authority.

> where I can make it clearer.

How about this text in SECURITY CONSIDERATIONS

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

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.

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.

DNS records MUST NOT be used in logs in place of IP addresses.

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

> included some.  

The draft seems to say "if you don't do reverse mapping, bad things
happen and you should expect this".  That message is incorrect and needs
to be removed.  The unfounded expectations for reverse DNS records are
illegitimate, and should not be given legitimacy by description in the
draft.  There should be no cases of uses of reverse DNS (for forward/
reverse matching), but rather only cases of how people _provide_ reverse
DNS to illustrate the diversity of reverse DNS provisioning.

There are no valid assumptions for what should be found when one makes a
PTR query.  So many of the use cases you describe are based on invalid
assumptions. Drafts should not contain invalid assumptions.

"PTR records are like a box of chocolate. You never know what you'll 
get" --Dean Anderson (2007) [you can put that in the draft ;-)]

> them there if you'd like.  

Thanks.  I tried to connect to jabber at the montreal meeting, but I
couldn't get any of 3 different windows clients to work....I'm not a
jabber user.  Too bad there isn't an IRC gateway...

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 5 Jan 2007 16:29:13 -0500 (EST)

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

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

		--Dean

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Jan 2007 17:39:13 -0500

Hi Dean,

Thanks for your message.  Some additional questions and comments are
inline, below.

On Fri, Jan 05, 2007 at 04:29:13PM -0500, Dean Anderson wrote:

> resolve this disagreement. 

To be clear, I'm not in the camp you seem to think I am.  There is no
"must" language in the draft, as far as I know.  If there is, I'd
appreciate your pointing it out with a quote.  

> to "SHOULD", but "SHOULD" is still incorrect:  

The 2119 keywords were all (or should have been) removed from this
draft.  If you find one, it's a bug, and my fault.  Please point it
out.

> Reverse records are entirely optional.  Matching reverse with
> forward is entirely optional.

Would you be able to point to the text in the draft that says
otherwise, please?

> things should result from any of these practices or any other reverse

I think that your claim there depends entirely on what you mean by
"bad things".  Could you expand on that, please?

> "h-11-22-33-44.somedomain.com" are suspicious.  

I'd like to keep the discussion focussed on the actual draft, and not
what someone said somewhere, sometime.  While I believe the draft
points out that there are people who think this way, and act on it, I
don't believe it actually says that they are justified in their
actions.  If you think the draft says otherwise, would you please
tell me what text it is that says so?

> Technically, DNS is not deterministic:  

The entire DNS is not deterministic for the state of the entire DNS. 
I should have stated that more clearly: the response to a query from
some client to some server at any given moment is deterministic:
either you get an answer, or you don't.  I further claim that there
is a range of answers that any particular query should properly see;
that range of answers is, in fact, determined partly by the intent of
the administrator of the queried zone.  I'm attempting to say, I
believe, the same thing Ed is trying to say (if I understand him
correctly).

> get depends on the cache chosen, and this may be done at random.

Right.  But that doesn't mean that the answer you get from that cache
at that moment is random.  It isn't, surely?

> How about this text in SECURITY CONSIDERATIONS

Because this draft is not intended to be a standard of any kind, the
keywords cannot be there.  Moreover, I think your claims above are
(1) not security considerations and (2) none of anyone's business. 
Users can choose to do what they want on the basis of the existence
of reverse mapping.  That's just a part of the end to end principle.  
All this document is trying to do is capture the community's best
information on what people should take into consideration when
evaluating whether to use or support the reverse tree.

> do not have matching foward/reverse DNS.

The draft already says that it recommends avoiding such checks, and
that other security mechanisms are needed.  Aside from the 2119
language (which I addressed above), why do you think your formulation
is an improvement?

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

Even if we wanted to say that, who would enforce it -- the log
police?  It seems to me that people ought to do as they wish out
there on the Net with their applications.  It's merely our
responsibility to tell them what will happen if they act one way
instead of another.  Do you disagree with that?

> happen and you should expect this".  

Where does it say that?  What bad things?  I think it probably does
say that, if you don't do reverse mapping, a possibly useful feature
of the Internet is lost, and various people might decide they don't
want to talk to you.  That's their decision, just as it is yours to
elect whether to do reverse mapping in your part of the tree.  I
don't believe there's anything inconsistent with this formulation in
the draft, but if there is, I'd like to hear about it.

> illegitimate, and should not be given legitimacy by description in the

What expectations are there?  Who has them?  Where in the draft does
it say, "Expect reverse DNS records to work from every site"?

> DNS to illustrate the diversity of reverse DNS provisioning.

What way do people provide reverse DNS that is not reverse mapping?
And what case do you see in the draft that recommends or even
encourages doing this forward/reverse mapping?

> assumptions. Drafts should not contain invalid assumptions.

Really?  Ever?  It seems to me that one can make assumptions that one
likes about other people's systems, and act on those assumptions, as
long as you understand how those assumptions may be wrong.  That's
the nice thing about a network where the intelligence is out at the
edges.  Do you disagree?  If so, how, and why?

A

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Jan 2007 17:39:13 -0500

Hi Dean,

A

---

From: Dean Anderson <[email-masked]>
Date: Mon, 8 Jan 2007 11:01:06 -0500 (EST)

Inline, two messages

> works, because the reverse tree can be useful in a number of cases.

The phrase "best if the reverse tree works" implies that somehow the
reverse tree doesn't work.  That implication is false. The reverse tree
is entirely optional. The reverse tree works no matter what. It works if
there are no records.  It works of the records that are there don't meet
the spam/security forward/reverse test. Your implication that it somehow
doesn't work is wrong and misleading.

> > to "SHOULD", but "SHOULD" is still incorrect:  

As I said, the language has been softened from what it was in the first
version of the inaddr-required draft. However, your position has not
changed. All you have done is reword your document with ambiguous
statements, terms and phrases that have double meanings.

> draft.  If you find one, it's a bug, and my fault.  Please point it

This is a fault, not a benefit. Standards documents should be clear,
concise, and direct. RFC2119 defines terms for precision and 
clarity. Your document is ambiguous with few unambiguous
statements.  In lieu of proper 2119 terms, you have used ambiguous terms
such as "could" instead of the clear terms defined in RFC2119. (see 
below)

> Would you be able to point to the text in the draft that says

Certainly. 

   At the same time, some sites have attempted to use reverse mappings
   as a part of a security- or abuse-prevention policy.  Moreover, some
   protocols that store data in the DNS, such as those described in
   [RFC4025], [RFC4255], and [RFC4322], could benefit from accurate
   reverse mapping data.

   In light of the above conflicting pressures, this document attempts
   to outline some considerations for the maintenance and use of reverse
   mappings so that users and administrators can make informed
   decisions.

RFC4025 A Method for Storing IPsec Keying Material in DNS
RFC4255 Using DNS to Securely Publish Secure Shell (SSH) Key 
Fingerprints
RFC4322 Opportunistic Encryption using the Internet Key Exchange (IKE)

None of these RFCs utilize PTR records, and so cannot benefit from
"accurate reverse mapping data".  All of them involve DNSSEC or require
DNSSEC to be secure.  

The phrase "accurare reverse mapping data" has merely become a code
phrase or euphenism for matching forward and reverse.  This is known to
be a security weakness. It would offer no enhancement to a
crytographicly authenticated DNSSEC response.

Your assertion that these RFC's benefit depends on the wrong assumption
that matching forward and reverse improve security somehow.  Then you
include examples of "missing" reverse data and imply that this is a
problem to be fixed. Thus, you impute (incorrectly) that PTR records are
not entirely optional and that non-matching forward and reverse are
somehow inaccurate.

> "bad things".  Could you expand on that, please?

_You_ already have.  Section 3.1 "Examples of effects of missing reverse
mapping" is entire devoted to "bad things":

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

   Some popular FTP sites will simply reject user sessions, even for
   anonymous FTP, if the reverse mapping lookup fails or if the reverse
   mapping, when itself resolved, does not match.  Some Telnet servers
   also implement this check.
[...]

The examples you included in Section 3.1 are examples of
_mis-application_ of reverse DNS. Yet your positively phrased
description encourages these behaviors, rather than illuminates the
false assumptions on which they depend.

> what someone said somewhere, sometime.  

This is a specific example of wrong assumptions about PTR records. Your
draft is about PTR record usage.

> While I believe the draft points out that there are people who think
> this way, and act on it, I don't believe it actually says that they
> are justified in their actions.  If you think the draft says
> otherwise, would you please tell me what text it is that says so?

The draft strongly implies they are justified through positive
descriptions of unjustified behavior, negative connotations of
"inaccurate reverse data", and contains no text indicating that this is
unjustified behavior:

1) The complete absense of any text specifically saying this behavior is
bad.  

2) The biased tone that indicates the cause is "inaccurate reverse
data".  This phrase is prejudicially negative. It makes it seem that one
should maintain "accurate reverse mapping data", which though undefined
in your document, appears to mean matching forward and reverse.

Unless of course, you are willing to define "accurate reverse mapping
data" so to mean anything, including no PTR records, and records that do
not meet the "spam/security" forward/reverse match test.

The phrase "accurate reverse mapping data" strongly suggests "MUST" or
"SHOULD".  The absense of these terms in the document, given phrases
such as this, implys something other than the more correct "DNS PTR
records are completely optional". Or "DNS PTR records do not need to 
meet the spam/security forward/reverse match test".

> either you get an answer, or you don't.  

By that definition, random numbers are deterministic, too. That is a
frivolous definition of "deterministic". I'll ignore your mistake. 
"determinism" has nothing to do with the asserted. Lets stick with your 
claim:

> What I claim is true, though, is this: since DNS is deterministic,
> there is a right answer to every _particular_ query, when the
> particulars of the query include its origin.

> I further claim that there is a range of answers that any particular
> query should properly see; that range of answers is, in fact,
> determined partly by the intent of the administrator of the queried
> zone.  I'm attempting to say, I believe, the same thing Ed is trying
> to say (if I understand him correctly).

The "right" answer is determined fully by the intent of the
administrator and the form of the protocol.  There are only two issues:
1) did the administrator mean to enter that data? (only the 
administrator can answer that)
2) was the response properly formed per the DNS protocol? (this is the 
only issue of correctness that the client can determine.)

Neither of these imply your claim that the PTR records must meet the
spam/security forward/reverse match test.  Perhaps you could provide a
reference for that claim.

What I stated is true:  Nxdomain is a perfectly valid and correct
response to a PTR query. It is perfectly valid for all PTR records under
130.105/16 to have "av8.com" as the PTR record.  There is no valid
notion of "accurate reverse mapping data". Your notion is completely
unfounded.  But again, perhaps you could provide a reference for that 
claim.  I am certain it has nothing to do with the determinism of DNS.

> keywords cannot be there.  

If true, then this document should not be considered by the working
group.  However, my understanding is that this document is intended to
become a BCP.  A BCP is a standard of a certain kind.  RFC 2119 terms
are allowed in BCPs.  I know of no prohibition on RFC 2119 terms in
BCPs. Checking around, I see other BCPs with RFC 2119 terms in them (eg
3968, 4107, 4288, 4497, 4520, etc. Do you have a reference for this
prohibition?

> Moreover, I think your claims above are (1) not security
> considerations and 

Where do you propose placing this text?

I think the working group agrees that DNS PTR records are completely
optional, else you would not have had to change the title and much of
the content of the first draft of inaddr-required to its current name.

Violating the prescriptions in the statements or making contrary false
assumptions results in security vulnerability.  So it seems these
statements are properly security considerations.  However, I'm open to 
putting them elsewhere.

> (2) none of anyone's business.  Users can choose to
> do what they want on the basis of the existence of reverse mapping.  
> That's just a part of the end to end principle.  All this document is
> trying to do is capture the community's best information on what
> people should take into consideration when evaluating whether to use
> or support the reverse tree.

Indeed. Lets note in the draft that sites _can_ choose to do what they
want, and other sites must not (MUST NOT) depend on them doing something
in particular.

> language (which I addressed above), why do you think your formulation

My language is clear and specific, and it resolves the ambiguity in your
descriptions.

> instead of another.  Do you disagree with that?

RFC 2119 language is not about enforcement.  Its about stating the 
necessary requirements.

> want to talk to you.  

So you dispute my assertion of a message, and then agree that the draft
does say that message.  Nice.  You are in the wrong line of business. 
:-)

> That's their decision, just as it is yours to elect whether to do
> reverse mapping in your part of the tree.  I don't believe there's
> anything inconsistent with this formulation in the draft, but if there
> is, I'd like to hear about it.

That behavior is not a position the IETF should support or encourage.

> it say, "Expect reverse DNS records to work from every site"?

I've already covered that above.  

> What way do people provide reverse DNS that is not reverse mapping?

You misread my statement.  I said forward/reverse __matching__.  

> encourages doing this forward/reverse mapping?

This was previously discussed above. To summarize, the part that
discusses "accurate reverse mapping data" and the positive descriptions
of examples of incorrect behavior.

> Really?  Ever?  

That's right.

> It seems to me that one can make assumptions that one likes about
> other people's systems, and act on those assumptions, as long as you
> understand how those assumptions may be wrong.

The DNSOP and the IETF should not be __encouraging__ false assumptions.  
There is also something disquieting about your statement: People who
willfully act on assumptions they know to be false are at least
irrational.  I find it truly amazing that people can _knowingly_
advocate and act on false ideas and false assumptions, and do so while
admitting the assumptions false.  Such advocacy of known false
statements is in the realm of propoganda, not best practices.

But a key phrase is "understand how those assumptions may be wrong".  
Your draft omits information that explains how certain assumptions about
PTR records are wrong, and through biased terms, encourages people to
assume wrongly and act on invalid assumptions.

I hope this is clear enough.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 8 Jan 2007 11:01:06 -0500 (EST)

Inline, two messages

Certainly. 

[...]
   Failure to

That's right.

		--Dean

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 8 Jan 2007 11:48:14 -0500

Hi Dean,

Thanks for your response.  I'm still unclear about a few things, so
I'm replying here.

On Mon, Jan 08, 2007 at 11:01:06AM -0500, Dean Anderson wrote:
> 
> The phrase "best if the reverse tree works" implies that somehow
> the reverse tree doesn't work.  [. . .] The reverse tree works no
> matter what. It works if there are no records.  It works of the
> records that are there don't meet the spam/security forward/reverse
> test. Your implication that it somehow doesn't work is wrong and
> misleading.

Perhaps I should re-phrase that as "best if the reverse tree contains
usable data."  Some people apparently find that their decision making
is better if the reverse tree and the forward tree both contain data
for a given host.  Sometimes, those people find it useful to compare
the data and try to match it, and to make additional decisions on
that basis.  I don't know whether that decision on their part is a
good idea in their circumstances, because I'm not familiar with all
of their circumstances (and I claim that nobody except the admin in
question could be).  So, absent other overriding considerations, it
is best on the whole if such data is available.  But I think it's
clear that the draft _does_ suggest other considerations might be
overriding.  Do you think it doesn't?

> statements, terms and phrases that have double meanings.

I think gratuitious _ad hominems_ unsupported by any quotations can
probably be omitted from our conversation, no?  Thanks very much.

> This is a fault, not a benefit. Standards documents should be clear,

But as I've already pointed out, this is not a standards document. 
Therefore, it is not allowed to have prescriptive language.  This is
per the normal RFC process in the IETF, as far as I know.  I'm sure
the Chairs will correct me if I am mistaken.

>    as a part of a security- or abuse-prevention policy.  

Note that this part of the text does not in fact say that they
_should_ use such data; just that they do.  Moreover, since such
policies are developed at the site level, I can't imagine how anyone
could legitimately say that the local admins at that site are wrong. 
They may decide that draconian measures are useful to them, or that
they are so devoted to reverse mapping that they refuse to allow
anyone who doesn't provide it to connect.  Or, for that matter, that
they just are too lazy to revisit old decisions.  The point of this
doc is not to say whether they are correct or mistaken, but to
outline what _considerations_ one needs to take into account.

[RFC enumeration elided]

> "accurate reverse mapping data".  All of them involve DNSSEC or require

That the protocols do not use PTR records does not entail that no
admin could find such data useful.  Since at least one person has
suggested that, combined with DNSSEC, reverse data reflecting the
forward zone could be useful, it seems false to me that these cannot
so benefit.  I'm willing to add a reference to DNSSEC, and to change
the language to "reverse data in accordance with the forward data"
instead of "accurate reverse mapping data", if that will address your
concern about the potentially loaded term "accurate".

> problem to be fixed. Thus, you impute (incorrectly) that PTR records are

The draft does not imply that it is a problem to be fixed.  It
suggests that reverse data that is not there, or does not match, may
create some side effects of which some are not aware.  There is a
difference between that and "a problem to be fixed", and I think the
draft is pretty careful to stay on one side of that line.  If you
have counter-examples, please let me know.

> mapping" is entire devoted to "bad things":

No, it is not.  It is a listing of the effect when a site that has
decided to rely on the reverse tree is unable to find a reverse
mapping entry where it is expected (by the site in question).  That
does not entail "bad things".  It does entail "these are effects you
should be aware of if you elect not to maintain reverse mapping",
which is a different claim.  I think the document is clear about
this, but you apparently haven't understood it, so if you can tell me
how it is unclear on this topic, I'd be much relieved.

> false assumptions on which they depend.

These are neither positively nor negatively phrased descriptions.  I
think you will find, if you read a little farther, that the draft
also says that such applications are probably not serving the purpose
many admins think they are.  The point is merely to say, "Here is
something that people do, so if you do not provide reverse mapping,
their attempts will fail."

> draft is about PTR record usage.

Let's please stick to the text of the draft, and not some random
other thing.  Only the text of the draft is what will count in the
long run.

> 1) The complete absense of any text specifically saying this behavior is

This assertion is false, as I have already pointed out.  That you
keep repeating it makes me think that you haven't actually read the
entire text.

> in your document, appears to mean matching forward and reverse.

I suggested, above, a modified turn of phrase that might address this
issue.  Does it?

> only issue of correctness that the client can determine.)

Those are the two things I meant, yes.

> reference for that claim.

I haven't ever made such a claim.  I don't know why you think I have,
but I haven't.

> group.  

I think you are mistaken about how the RFC process works.  I defer to
the Chairs, however, on this matter.

> However, my understanding is that this document is intended to
> become a BCP. 

I've been led to believe the intended status is informational,
actually.

> Where do you propose placing this text?

I don't propse to put it anywhere, precisely because I don't think
the text is true, as I noted already.

> want, and other sites must not (MUST NOT) depend on them doing something

There's nothing in the document that says otherwise, as far as I can
tell.  

> My language is clear and specific, and it resolves the ambiguity in your

But you haven't pointed out any actual ambiguity, as far as I can
tell.  I'll ask the group, though: is there anyone who agrees with
Dean's diagnosis of ambiguity?

> RFC 2119 language is not about enforcement.  Its about stating the 

In which case, I claim your proposal is a fatuous requirement.  Given
the existence of the reverse tree, it seems perfectly legitimate to
me for some sites to try to use it for various purposes.  One of
those is logging.

> does say that message.  Nice.  You are in the wrong line of business. 

Where I come from "a possibly useful feature of the Internet is lost,
and various people might decide they don't want to talk to you" is
not equivalent to "bad things happen".  At least, not if you take
into consideration that the feature and communication might be lost. 
An informed decision to lose a feature is not a bad thing.

> That behavior is not a position the IETF should support or encourage.

Your view is noted.  I simply disagree with you about that.

> irrational.  

Bosh.  I won't bore the list with a recitation of the number of
thought experiments which proceed on such grounds, just to get
started.  Similarly, every time you use Newtonian physics to solve a
problem, you're willfully acting on such assumptions.  And
simplifying assumptions are often useful, even if they cause you
problems in some marginal areas.

> PTR records are wrong

Aside from the charged word "accurate", do you have any other
examples?  I don't see any you've provided.

Best regards,
A

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 8 Jan 2007 11:48:14 -0500

Hi Dean,

[RFC enumeration elided]

Best regards,
A

---

From: Brett Carr <[email-masked]>
Date: Tue, 9 Jan 2007 13:14:20 +0100 (CET)

>RIRs may delegate address space to Local Internet Registries (LIRs),
   >who may perform further delegation.  Reverse mapping only works if
   >all the intermediate delegations are correctly maintained.  As a
   >result, RIRs find they cannot enforce policies requiring reverse
   >mappings, because they sometimes do not have any relationship with
   >the intermediate party on whom some end-point reverse mapping
   >depends.  It may be supposed that IPv6 will make this "reachover
   >problem" worse, because of the likelihood of longer delegation chains
   >in IPv6.

I agree that RIR's cannot enforce policies requiring reverse mapping on
end users or maybe even endpoint ISP's but they could and in some
cases do have policies related to reverse delegations on the direct
relationship's they have with LIR's.

The RIPE NCC strongly encourage LIR's to insert the data for reverse
delegation. This is mentioned in the following policy:

http://www.ripe.net/ripe/docs/rev-del.html

The RIPE NCC will also be soon kicking off a project to check delegations
from RIPE>LIR's in the reverse tree. You can see the details here.

http://www.ripe.net/ripe/draft-documents/dns-lameness.html

I think similar work is being undertaken in APNIC which I'm sure George
may be able to comment on.

I think the fact that policies can and do exist to encourage reverse
delegations should be mentioned in this draft.

--
Brett Carr                              RIPE Network Coordination Centre
Manager -- DNS Services Group           Singel 258 Amsterdam NL
GPG Key fingerprint = F20D B2A7 C91D E370 44CF  F244 B6A1 EF48 E743 F7D8

---

From: Brett Carr <[email-masked]>
Date: Tue, 9 Jan 2007 13:14:20 +0100 (CET)

---

From: Joe Abley <[email-masked]>
Date: Tue, 9 Jan 2007 07:23:59 -0500

> may be able to comment on.

APNIC started their lame delegation trial some years ago (back when I  
used to show up for APNIC meetings, even); I believe all that stuff  
has been in production for quite a while, now.

> delegations should be mentioned in this draft.

I think the actions of a registry in detecting and acting upon lame  
delegations from the zones under their stewardship are relevant to  
the whole DNS, and not just to do with the in-addr.arpa or ip6.arpa  
domains. As such, if the issues are to be documented, I'd prefer to  
see them described in a separate draft.

Joe

---

From: Joe Abley <[email-masked]>
Date: Tue, 9 Jan 2007 07:23:59 -0500

Joe