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: 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? > 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? > 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. 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). > 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. 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. > 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? > 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? > 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. 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. > 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"? > 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? And what case do you see in the draft that recommends or even encourages doing this forward/reverse mapping? > 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? 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 -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 jabber: [EMAIL PROTECTED] +1 416 646 3304 x4110 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
