Inline, two messages
On Fri, 5 Jan 2007, Andrew Sullivan wrote:
> > The position of the "security/spam" crowd is that no reverse anwser
is
> > 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.
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.
On Fri, 5 Jan 2007, Andrew Sullivan wrote:
> 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:
>
> > 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.
>
> 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.
>
> > Somewhat, over time your camp may have moderated the notion from "MUST"
> > 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.
> 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.
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)
> > 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?
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.
> > 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 think that your claim there depends entirely on what you mean by
> "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.
> > I've seen admins claim that PTR records of the form
> > "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.
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".
> > 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.
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.
> > 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.
>
> 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
> >
> > ===============
> >
> > 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.
>
> Because this draft is not intended to be a standard of any kind, the
> 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.
> > 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.
>
> 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?
My language is clear and specific, and it resolves the ambiguity in your
descriptions.
> > 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?
RFC 2119 language is not about enforcement. Its about stating the
necessary requirements.
> > The draft seems to say "if you don't do reverse mapping, bad things
> > 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.
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.
> > to be removed. The unfounded expectations for reverse DNS records are
> > 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"?
I've already covered that above.
> > 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.
>
> What way do people provide reverse DNS that is not reverse mapping?
You misread my statement. I said forward/reverse __matching__.
> And what case do you see in the draft that recommends or even
> 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.
> > 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.
>
> 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
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
