Hello, Thank you for your detailed comments. I have some additional questions and remarks below.
On Fri, Mar 28, 2008 at 03:28:17PM -0700, JINMEI Tatuya / 神明達哉 wrote: > As a meta (and most substantial) level, this version still doesn't > answer the fundamental question I asked a year ago: "why *should* one > provide reverse mappings for all IP addresses they manage? (despite > the cost of the provision)?". > (see http://www.ietf.org/mail-archive/web/dnsop/current/msg05411.html) In the current version, we have attempted to address this question in two ways. First, we do list a number of cases where people say they are using the reverse tree, and it's useful to them. As Brian Dickson says elswhere in this thread, the simple fact is that there is no way to tell whether there is existing or matching reverse without querying for it. To the extent that the reverse tree can be valuable, it requires that people populate it and keep it up to date. Second, the current version includes the following text in Section 4.2; it is intended to address your objection, at least in part. It is nevertheless worth considering that not all benefit from an administration practice accrues to the administrator of a network. The consumers of reverse mapping data are often not the operators of the network that provides the reverse mappings. Users of reverse mapping data report that it is valuable to them. (note that there's a typo in the published version: "accrue" rather than "accrues". I just fixed it in my local copy, now.) The idea here is to remind people that the reason you _should_ do this is because other people say they find the reverse map useful. It is true that there is an asymmetry of cost and benefit here; that's the reason that we need the draft at all, I think. > Since this document does not provide a convincing answer (at least to > me) for the question of "why I should", I, as an operator, will still > only provide reverse mappings as a best effort basis (i.e., I may not > provide them even if there is no "*strong* counter-considerations"). > For example I won't provide reverse mappings if I simply cannot (or > don't want to) afford the operational cost. And I'm afraid I'm not I tried to argue in <http://www.ietf.org/mail-archive/web/dnsop/current/msg05563.html> that the counter-consideration is ultimately one that operators are going to have to evaluate themselves. The same section 4.2 says explicitly that the principle is not intended to impose an undue burden on network operators. I agree, however, that > just one of very few lazy operators; rather, I think a non negligible > number of ordinary operators will take a similar action. many people may decide (unfortunately, in my opinion) that maintaining the reverse will be too burdensome. There's nothing anybody can do about that, but I still think we should say that it would be better overall if they would maintain the reverse mapping. > On the other hand, since this document only requires "thinking > carefully" about adopting (dubious) access control based on reverse > mappings, operators who are currently deploying it will simply > continue the operation, probably with quickly "thinking about it" as > an excuse. I'm also I think the document does condemn relying on the reverse mapping, particularly in section 4.3. > afraid the unbalanced level of recommendations (i.e., "should provide > reverse mappings" vs "are encouraged to think about it before using > it") will give an excuse for such operators (revmap users) to continue > it. The end result will be a (continued) poor interoperability, and > the "excuse" may even make it worse. I think the context of the "think carefully" remark also suggests that operators who don't want to maintain the reverse map need to think carefully: At the same time, site administrators are cautioned that administrators at other sites sometimes use reverse mapping as one of several pieces of evidence in evaluating connection traffic, particularly in the context of mail systems and anti-spam efforts. That section 4.4 is about usage and deployment, and the intent of that section is to say, "If you're going to use this data, be very careful, because the results may not mean what you think they mean; if you're not going to provide the data, be aware that others may be making decisions based on your non-provision of it." Would a general sentence of that sort at the beginning of that section help to clarify it? > My interpretation from the discussions so far is that the issues are > too subtle or controversial to provide a convincing reason for > declaring a specific requirement with such a strong word as "should". Please note that this is not an RFC2119 "SHOULD". The document as it is now does not refer to RFC2119 at all, because this document does not create new requirements of any sort. My understanding is that the way one communicates as much in an Internet Draft is by not citing RFC2119, but I'd be happy to be corrected. > convincing reason will be ignored anyway. Is there any reason we > cannot adopt this text? If this is something we can "live with", I > sincerely request adopting it. I attempted to reply to that request in <http://www.ietf.org/mail-archive/web/dnsop/current/msg05563.html>. The reason I have trouble with this is twfold. First, the "administration cost is acceptable according to the local policy" is, in my view, too narrow a condition. I don't think it is the only counter-consideration that should be in place: the reverse map is useful to some people, according to what they say, but it can only be useful if people maintain it. Since there are costs to the rest of the DNS (e.g. lookups that will never provide any data and will slow operations) when the data is not provided, I argue that the local cost is not enough. Second, I'm not sure what the difference is between, "Do this if the cost is acceptable to you," and, "Do this or don't; it's up to you." If that's what this document is going to say, then we should just keep quiet and let the thing die; we'll get the same state of affairs as actually obtains. (Speaking only personally, I'd rather have a document that says, "stop using the reverse tree; people can't be bothered to maintain it," than a document that makes it all up to local policy.) I note that the existing draft already says that there are cases where you should not provide a matching reverse for every forward map. In spite of my objections, however, I would like guidance from the Working Group: are there others who want to make the change as suggested? If there seems to be support, I will cheerfully make the change. The last time this was suggested, I did not hear many expressions of support for it, so I left the text alone. > One more possibly related thing: what does this document recommend > about "matching reverse data"? The idea is that, if you maintain the reverse mapping, the mappings will automatically match. This is implicit in section 4.2: Unless there are strong counter-considerations, such as a high probability of forcing large numbers of queries to use TCP, IP addresses in use within a range and referenced in a forward mapping should have a reverse mapping. But notice the caveat. That caveat is made more explicit in section 4.4: Administrators are advised to keep in mind the effects of adding a very large number of PTR records for a given reverse mapping. So, there should usually be matching reverse data. But the draft attempts to note that there will be at least some occasions in which it is impractical to maintain the data this way. > Section 3.2 > > Reports from operators suggest that scoring mail on the basis of > missing or non-matching reverse mapping remains an imperfect but > useful measure of the likelihood that a given message is spam, > particularly in combination with other measures. It is clear that > the presence of reverse mapping, and a match between the forward and > reverse zones, is neither a necessary nor sufficient condition for a > candidate message to be spam. > > I'm not very much comfortable with a statement based on "some people > say something" because it's difficult to assess its validity. If I understand this correctly, you mean, "Difficult to assess the validity of the thing the people say," and not, "Difficult to assess whether people actually have said that," (since people have made the claim during the discussion about this document). I don't know how to assess the validity of someone's claim that a strategy is useful _to them_. Would this be better if we altered it to "Some operators report that scoring mail on the basis. . ."? > I'd rather like to see a solid reference that describes how exactly > effective of this type of scoring is, both in terms of the ability of > identifying spams and of the ability of avoiding false positives. When I attempted to collect such references, all the spam-fighting people told me that every reference I made would be obsolete within months. I'm happy to attempt this again, though, if others in the working group also think it is a worthwhile thing to do. Anyone? > This is not related to DNS or reverse mapping specifically per se, but > I think it's useful to show people who naively believe the power of > reverse mappings that there are alternatives, which might be more > trustworthy, for their purposes. The draft already says, more than once, that you shouldn't rely too heavily on the reverse mapping, particularly by itself. I don't especially see the value of adding specific examples of how not to rely on the reverse mapping alone for every case, but I'm of course willing to reconsider that position depending upon expressions of WG support to say something different. > ... If such "hiding" is desirable, one possible alternative is to > provide reverse mapping for (a large segment of) the network in > question, and then use only a small number of the so-mapped hosts. > It should still be noted, however, that this approach may not > easily be realized with deployed implementations, and that > automatically generated host names that are often used in this > approach may make them useless. ... I'm not opposed to adding this text (thank you for it), if there are other expressions of support. I do note that there is already text in section 3.4 that makes a similar point: The much larger address space of IPv6 makes administration of reverse mapping somewhat daunting, in the absence of good tools to help administrators. Some discussion of this issue can be found in [RFC4472], particularly section 7. I also suggested previously that I'd be willing to put in a reference to draft-ietf-v6ops-scanning-implications; at the time I was somewhat uneasy with it, because I thought we were fairly close to WGLC. That didn't happen as quickly as I expected, in fact, and I note that draft-ietf-v6ops-scanning-implications is in the RFC Editor's queue. So there won't be any problems with the reference anyway. Would such a reference help? > Section 4.2 > > 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. > > Maybe I'm too dull, but I've never succeeded to understand the meaning > of this sentence (I asked the same question on a previous version of > the draft, but this point has never been clarified). In particular, I > don't understand what this means: "what is supposed to be seen at the > address by the machine initiating the query". Can't this be more > clarified? I know we've never clarified this; I'm not sure how to do it and still make readable text. (Note that Ed Lewis contributed the original text, and I don't want to put words in his mouth; any mistake here is my fault, not his.) The idea is this: when a query arrives at a DNS server, there is some right answer to it. This does not mean that there is one absolutely correct answer to a particular query; for instance, the answer to a query about 10.1.2.3 is going to depend on the network on which it happens. Similarly, in a split-brain deployment, the answer to a query might depend on which address receives the query. But there is a right answer, and it's what the administrator configured the server to give (or at least, what the administrator would have configured the server to answer in the event the administrator had done it correctly). This is true of forward queries, and it is also true of reverse-map queries. > Unless there are strong counter-considerations, such as a high > probability of forcing large numbers of queries to use TCP, IP > addresses in use within a range and referenced in a forward mapping > should have a reverse mapping. > > I failed to understand this sentence. Does this mean > > IP addresses that are > - in use within a range, and > - referenced in a forward mapping > should have a reverse mapping. This is the intended meaning. If there's a way to disambiguate it from the other case, I'd be happy to include it. > or something else? In either case, does this mean we don't have to > provide reverse mappings for addresses that are NOT referenced in a > forward mapping? No. We added this text exactly to address your previous objection that the text appeared to be requiring that every IP address anybody uses has to have a reverse map, which is absurd since every IP address in use doesn't need to have a forward map. > I also asked the precise definition of 'in use' (especially in the > context of IPv6 stateless address configuration) in my previous > comment, but it's still unclear in this version. I'm sorry. The point of the clarifiying remark was intended to make that plain. Probably, I've failed to grasp the complete context of IPv6 stateless address configuration. My impression is that, in a stateless configuration case, you're pretty unlikely to have a forward mapping. Is that wrong? I dealt with this as issue 17, and proposed text in <http://www.ietf.org/mail-archive/web/dnsop/current/msg05575.html>. I'm sorry we still haven't clarified the issue. > can be corrected by the provision by those providers of reverse > mapping; but until the day reverse mapping is universal, complete > connection rejection on the basis of missing reverse mapping should > be regarded as a last resort. > > I don't understand the logic of this sentence. This sounds as if > > complete connection rejection on the basis of missing reverse mapping > > will be encouraged (or at least not discouraged) when reverse mapping > > is universal. I think this is a reasonable objection, but I also suspect that "the day reverse mapping is universal" will never come. Nevertheless, let me see if we can do better. > > reverse mapping; but even if reverse mapping is more widely > > provided, complete connection rejection on the basis of missing > > reverse mapping should be generally discouraged, since the > > existence of a reverse mapping does not necessarily mean the owner > > of the address is legitimate. > > Perhaps my suggested text is too biased toward discouraging the > dubious use of reverse mappings, but at least I want to see something > that is logically more understandable. The reason I'm uncomfortable with your proposed text is that it seems to say this: the reverse mapping is an inadequate positive proof, therefore it cannot be used as evidence in a negative proof. I think that premise is false. What about this: Some users continue to report difficulty in ensuring complete population of the reverse tree by upstream providers. This situation could be corrected by the provision by those providers of reverse mapping; but even if that happened, because there is no way to be sure the reverse map is always complete, connection rejection on the basis of missing reverse mapping should be regarded as a last resort. This text stays with the current point (that you shouldn't reject connections because of missing reverse, because you can't be sure that you're reacting to the right information) without drawing into this paragraph other issues of the utility of the reverse mapping. Does it address your objection? Again, thank you very much for your detailed comments and careful review. Your editors appreciate it. Best regards, Andrew -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
