Re: [DNSOP] Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-02.txt
On Mar 26, 2007, at 7:33 AM, Robert Story wrote: On Fri, 23 Mar 2007 18:39:59 -0400 (EDT) Dean wrote: DA Real anti-spam groups at large ISPs don't use reverse DNS for spam DA filtering. There have been attempts to do so in the past, but those DA ended in (sometimes well-publicized) disasters. This is patently and provably false. AOL clearly states that AOL's mail servers will reject connections from any IP address that does not have reverse DNS (a PTR record). and AOL's mail servers will not accept connections from systems that use dynamically assigned or residential IP addresses. [1] (I don't know how they are determining 'dynamically assigned or residential IP addresses', so that may or may not be via reverse DNS.) While having a valid PTR record in the reverse address space might be used as one criteria for email acceptance, a test for the PTR record might be that it resolves to some IP address. However, this IP address will not necessarily relate to the SMTP client. A bad actor on a compromised a system can also easily assert a host-name matching that of a PTR record. Determination of acceptable IP address space is done with the aid of third-party lists often determined directly from network providers. When the network provider does not cooperate, there might be clues uncovered by the reverse PTR records. However this information is not reliable as it is often poorly maintained or fails to include all possible host-names. SpamHaus is a rather well know spam-fighting organization, and they clearly state that having reverse DNS is 'highly desirable.' [2] Forward and reverse DNS zones being properly configured helps in many ways. Often prior to block-listing, an attempt is made to contact network providers based upon BGP information. Reverse zones help confirm relationships discovered in this manner. The seventh paragraph in section 3.1 perhaps slightly overstates matching reliance placed upon the reverse DNS zone information or expectations of consistent conventions. Nevertheless, this information is often gleaned for rating clues. Clearly finding a match improves the likelihood of message acceptance. The reverse DNS space might be seen as a way for network providers to constrain the use of their IP address space. However, conventions for such reverse zone control are lacking. It also seems adoption of IPv6 may further frustrate reverse zone reliance and establishing consistent conventions. One might expect forward based authorizations in conjunction with cryptographic identification will approximate current abuse control strategies. At this point, it is not clear whether such authorization will be placed within DNS or perhaps found within something like OpenID structures. -Doug ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-02.txt
On 26-Mar-2007, at 14:48, Dean Anderson wrote: On Mon, 26 Mar 2007, Robert Story wrote: DA Assuming an 'apparent inability to update reverse tree' is a false DA assumption: But you can't dictate other peoples assumptions. Assumptions are often based on ones personal experiences, and it's perfectly reasonable for different people to make different assumptions. Sorry. Wrong. Its not 'perfectly reasonable' to make false assumptions. It's not at all reasonable to assume that when the assumptions of others don't match your own, they are necessarily false. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-02.txt
JINMEI Tatuya / wrote: At Mon, 26 Feb 2007 16:30:46 -0500, Andrew Sullivan [EMAIL PROTECTED] wrote: Title : Considerations for the use of DNS Reverse Mapping Author(s) : D. Senie, A. Sullivan Filename: draft-ietf-dnsop-reverse-mapping-considerations-02.txt Pages : 12 Date: 2007-2-26 (snip) I hope that these modifications address the remaining concerns of those who previously objected. In my opinion, this document says the same thing as the previous version did, but if these modifications make it clearer to some, then the goal of another round of work will have been met. I respect the authors' effort in the new version, and I see it has been improved since the previous version; however, it still does not address my fundamental concern: why *should* one provide reverse mappings for all IP addresses they manage? In this version, it reads: Unless there are strong counter-considerations, such as a high probability of forcing large numbers of queries to use TCP, all IP addresses in use within a range should have a reverse mapping. Perhaps the condition added to the main clause intended to soften the requirement level, but this still sounds pretty demanding to me due to the strong phrase of unless there are strong counter-considerations. We should not forget that providing and maintaining reverse mappings require operational costs (even though it's not very high). IMO, when we recommend one *should* provide something that comes with a cost, we should give a convincing reason why they should do it. The rationale is still missing in this version. As I commented on the previous version of the draft, none of the described issues or usages seems a convincing reason for such a strong requirement. I agree wholeheartedly with this comment. In the corporate environment, where I'm coming from, the point is to make money, and anything which costs money, manpower, increases complexity of the environment, presents possible information-disclosure-type security risks, etc., needs to have a demonstrable long-term *economic* benefit, or it is viewed as an unnecessary expense/risk, fails the business case test and won't get implemented, regardless of what the Internet Standards or BCPs say. If one of our many business partners is, for example, having trouble accepting mail from us because our gateways (hypothetically) have missing or incorrect reverse records, then obviously there is a business case, stated in terms of reliability, service levels, etc. for creating and maintaining reverse records for those gateways. (At least, unless and until that requirement can be removed by a subsequent upgrade to their mail software). But that's a case-by-case, episodic kind of thing, not the same as the document under discussion which makes a blanket recommendation for creation and maintenance of reverse records. I also question the scope of the term in use in the quoted draft text above. What does it mean, exactly, for an address to be in use? Pingable? ARPable? Sending and/or receiving packets? Specifically, by in use is it *assumed* that there is at least 1 A RR or RR referring to the address? What if there *isn't*? I.e. what if the device functioning at that address has no address record referring to it at all? The recommendation is that all addresses in use within a range should have a reverse mapping. That's very broad. On its face, it implies that even *unnamed* devices need reverse mappings. If, following the recommendation of the document, the reverse records are added _sans_ the A/ records, then we have a forward/reverse inconsistency, which seems to defeat the whole purpose of the document (because many of the cited mechanisms requiring the reverse records also need them to match up with forward records). If, on the other hand, the implication is that, following the recommendation, one should *fabricate* A/ records for every device in one's address range, that doesn't already have them, and the DNS information is publicly available, then the document indirectly recommends a *new* public information disclosure with regard to devices residing on one's network(s), which may not be the preference of many corporate and/or institutional Security Departments (whether that non-preference rises to the level of a strong counter-consideration[] is of course debatable). To put it more simply, if I want to have a stealth device on my network, which doesn't have either forward or reverse records pointing to it, why can't I do that? The text appears to preclude stealth devices. And no, I shouldn't have to come up with a strong counter-consideration for that. In this age of heightened security concerns and threats, the burden of proof should be on those recommending the information disclosure, to explain why the benefits outweigh the risks. Could I
Re: [DNSOP] Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-02.txt
On Mar 19, 2007, at 7:58 PM, Andrew Sullivan wrote: One thing that popped for me during your presentation today, Andrew, is that you say that the stupid things people are doing with the reverse zone have to work. This isn't true. Yikes. If that's the way I put it, my apologies; it certainly isn't true. What I think _is_ true (and what I was meaning to say) is that some people say that some uses of the reverse tree are useful for them. In order for those uses to work, the reverse lookups have to work. Or, to put this another way, for the reverse tree to be widely useful, it has to be fairly widely implemented; and to the extent people stop implementing reverse mappings, the reverse tree in general gradually becomes less useful. Interesting, I can see where the disconnect is happening. I see what I said and what you said you meant (rather than what I said) as the same thing. See, if it doesn't matter that the broken things people are doing with the reverse tree work, then you can't say that the reverse tree has to work for them to use their broken things, because we don't want them to use their broken things. So whether or not they need the reverse tree to work is irrelevant to us, the IETF. The obvious case is disagreement on using reverse mapping as a hint in spam-candidate scoring. Some users report that, based on the analysis of their own traffic, some sort of reverse mapping test is a useful indicator. Others correctly point out that such a rule runs the risk of false positives and also does not catch all spam. This is perfectly reasonable, because what you are doing is catching them in a lie. You don't know that the data in the reverse tree is correct just because the forward tree agrees with it, but if they do not agree, then you have detected a lie (or, to be charitable, a mistake), and that is information - it would be wrong to say that it is not. On the other hand, plenty of scoring systems that use the reverse tree can't be described so charitably. My (editorial) view on this is that, given there are uses where some people who understand the limitations of the facility nevertheless claim there is utility in their own case, in the absence either of numbers to show that the wrong empirical conclusion has been drawn or that the use case is implicitly broken, then such a use is not obviously stupid. Actually, there is one reason to consider it stupid: I might have control over my forward tree, but not over the reverse tree for the IP address I have. That doesn't mean I'm a spammer - it just means I have a lousy ISP. And, sad to say, that's most ISPs. So in this case, it is a broken configuration, for some value of broken, but it's not my fault that it's broken, and I can't fix it, so it's not really fair to score me as a liar. Fortunately, in a spam scoring system, as long as you don't use this as your exclusive score, it's probably okay - hopefully other indicators will tell you a different story. So, the intent of the text is precisely to say, on the one hand, that someone who is trying to use reverse mappings needs to understand the limitations of the implementations on the Internet; and on the other hand, that network operators should implement the reverse mappings in the absence of strong counter considerations, because the implementation is needed for these various use-cases to work. So how many of the examples you give are reasonable, in the sense of detecting a lie or misconfiguration and using it in a scoring system, and how many are unreasonable, like my ssh example? If the number of the latter is not zero, that might explain the pushback you've been seeing. Does that clarify my remark? It doesn't matter. What matters is whether your document is clear. And what I'm trying to point out is that what I've noticed may be a reason why it's not clear to some readers. The cure is for us to think about this and modify the document accordingly, not for you to explain here on the mailing list what you meant. ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-02.txt
On Mon, Mar 19, 2007 at 11:06:48PM +0100, Ted Lemon wrote: Fortunately, in a spam scoring system, as long as you don't use this as your exclusive score, it's probably okay - hopefully other indicators will tell you a different story. Right; this is why I think the security and utility questions can't be answered in a binary way. Sometimes the answer depends very much on what _else_ you know. It's clear to me, though (from your very helpful remarks as well as from some other comments that I've received) that such a message just isn't clear enough in the draft as it stands, which is why we need another round. and how many are unreasonable, like my ssh example? If the number of the latter is not zero, that might explain the pushback you've been seeing. Yes, I think you're right, and I appreciate the observation. (And certainly, the number of unreasonable uses is not zero, or we would have found consensus long ago.) The cure is for us to think about this and modify the document accordingly, not for you to explain here on the mailing list what you meant. No question. My point in explaining here what I meant is rather to see if a different expression of my meaning makes that meaning clearer to others, because that gives starting points for what text can improve the draft. I really appreciate the feedback, since it enables me to focus more carefully on the places where my own poor edits to the draft have obscured meaning or have sent the wrong message. In that spirit, let me ask whether including the following notions (not yet actual text for inclusion) would help: 1. An attempt to use reverse mappings as a single-source authentication or security mechanism is almost always a very bad idea, and may actually undermine better security or authentication practices. [How do we make the text say this more clearly? I thought it already says this plainly in some places, but I guess not.] 2. Some people report that using evaluation of the reverse mapping (either for existence or matching) is sometimes useful, especially in the presence of other data about the connecting host. [Also, does a DNSSEC-enabled reverse tree help here? Perhaps concrete examples would be more helpful? I'm leery of the latter, because the state of affairs in this area is liable to change.] 3. In most cases, a weaker reliance on reverse mapping tests will yield better results, because the risk of false positives (and the consequent failure modes) is lower. 4. The [potential?] utility of the reverse tree to all users of the Internet declines as fewer people implement reverse mappings. [I think this is implicit throughout the draft, but it maybe needs to be stated baldly?] 5. Maintaining reverse mappings (especially matching reverse mappings) is not free for operators of networks, and in some cases that cost may outweigh the benefit to anyone, such as is the case where the number of entries cause the query response to require truncation. Someone also hinted to me that a new section comprising a short survey of the history of some practices -- especially those that now fall into the category of obviously bad -- would help frame the discussion. Do people think that would be useful? (I worry it could be a rathole out of which the draft would never emerge, but I nevertheless see how it could clear up confusion for operators who don't care what an IETF is, but are looking for guidance on what to do and why something they heard about once as a good idea is no longer widely viewed as helpful.) Thank you very much for the comments and insights. A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, 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
Re: [DNSOP] Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-02.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dean Anderson wrote: FYI, I have submitted an alternate draft as an individual submission. It was submitted after the meeting cutoff and so will not be processed until Monday, March 19 at 9:00 AM ET, when Internet-Draft posting resumes. The draft can be found in the meantime at http://www.av8.net/IETF-watch/Drafts/draft-anderson-reverse-dns-status-00.txt As someone who thinks reverse is a lot of work considering the actual (almost nonexistent) benefit, I find this draft compelling. :) The report on the state of reverse DNS is almost identical in these drafts IMHO, but the recommendations (and tone of course) differ greatly. Is it possible to separate the findings of fact from the recommendations in both this and draft-ietf-dnsop-reverse-mapping-considerations-##.txt? If we do want a single document with facts *and* recommendations, then maybe we need to start from goals and say, if your goal is A, then we recommend *this*; if your goal is B, then we recommend *that*. Personally, as long as I don't have to wait for a timeout an a PTR lookup I'm happy. :) - -- Shane -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF7tuyMsfZxBO4kbQRAkC5AJ9ylsBUn4m+McqvIaxU7Gto7mff8gCfaM6K a7ftkYCgEvpL7/EzLjVFWng= =jcvE -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
