On Tue, Jun 12, 2007 at 07:10:27PM +0900, JINMEI Tatuya / 神明達哉 wrote:>
> Thanks for the update. I've read the 03 version, and found that most > of my previous comments > http://www1.ietf.org/mail-archive/web/dnsop/current/msg05418.html > were not actually addressed (or perhaps ignored or rejected?). Thanks for your review. We considered each of your comments carefully, and made changes to the text to address them where it seemed correct to do so. (At the bottom of this message, I'm including a detailed outline of whether and how the document changed in response to each of your comments. Your comments have been extremely valuable, and I'm distressed to learn that you think we are silently ignoring them. I apologise in advance that the responses make this message a little long.) > In > particular, I now more strongly wonder why this document still keeps > the strong recommendation: > > all IP addresses in use within a range should have a reverse mapping. Note that, because someone has pointed out (and I missed) the ambiguity in "in use", this sentence has to change anyway. But I observe three things here. First, the sentence says "should" not "SHOULD", so I'd argue that this is not as strong a requirement as you seem to think. Second, the sentence begins with, "Unless there are strong counter-considerations. . . ," which rather softens the meaning some more. It strikes me that one could easily argue that "expense" is a strong counter-consideration, in the event the expense is high enough. Finally, the paragraph also includes some entirely new text at the end which was intended precisely to address your previous comments: This principle is also not intended to impose undue burden on network operators. It is nevertheless worth considering that not all benefit from an administration practice accrue 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. In your comments before, you noted that we need a convincing reason why a practice should be followed if it imposes any cost. In the text above, there is given a reason; if it is not convincing to you, and you think the cost is too high, then it seems to me that you might have a counter-consideration to implementing reverse mappings (that would be the "undue burden"). > convincing reason for the strong suggestion in this version. Is there > any specific reason that we cannot make the statement more moderate > like this? > > it is encouraged for a network administrator to provide a reverse > mapping for IP addresses in use within a range when the management > cost is acceptable for the administrator. The problem I have with that formulation is that management cost is not the _only_ counter-consideration that ought to be in place. The document already lists another example -- where the cost is imposed on the operation of the DNS as opposed to the pocketbook of the operator. Moreover, there is little to distinguish, "Do this if the cost is acceptable to you," and, "Do this or not; it's up to you." If the document is really going to say that it makes no difference whether you maintain reverse mappings, then I don't think we should bother saying anything: we'll get the situation we have today anyway. In addition, after the -03 draft was posted, I received a comment from another list pointing out that there is already an RFC that says you should implement reverse mapping: RFC 1912. In section 2.1, it says Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data. I would argue, therefore, that the current draft is something of a softening of the position taken in RFC 1912. (It's also pretty clear that the draft needs to be updated to take the above passage into account. Thanks to Bruce Gingery on spam-l for this.) I hope the above addresses your concerns in this area. Below is my outline of how the draft changed between -02 and -03 to try to address your other helpful comments. The bulk of your comments were in http://www1.ietf.org/mail-archive/web/dnsop/current/msg05411.html, I believe. > - Section 1.1 > If the intent of this document is to recommend one *should* provide > reverse mappings, this section clearly says so instead of the vague > wording like "provide some guidelines". In -03, this section was updated to include, "suggests that site administrators implement reverse mappings in the absence of strong counter-considerations. . .". The use of the word "suggests" is intentional, again to avoid any confusion with standards-words and to ensure that the document is clearly not imposing a requirement on operators. > - Section 1.2 > I guess the IESG will suggest not using "NXDOMAIN" since it's an > implementation specific term (actually I was told that when I > edited RFC4074). Section 1.2 (and other mentions) changed from NXDOMAIN to Name Error. > - Section 1.3 [. . .] > What are "useful" reverse mappings? I'd rather remove this word, then > it will be a mere fact and clear to read. The word "useful" is unpacked to use the terminology already defined in the document. Also, > I don't think it's very clear that [RFC4255] could benefit from > matching reverse mapping. In fact, it does not mention DNS reverse > mapping at all (while the other two do). If we want to include > [RFC4255], I suggest adding some text that explains how it could > benefit from reverse mapping. I asked about the relevance of reverse mappings to RFC 4255, and it was approximately as I thought: reverse mappings can be useful as one more check that you are getting the data you think you are, particularly in the presence of the DNS Security extensions. I wasn't able to convince myself that explicating every example in the document would be a good idea; the document is already kind of fat for what it is, and I was afraid that adding an explanation of the way this might work would just be distracting. I did try two or three times to write it up in a compact but suitably clear way, and failed. If you really object strongly to the mention of RFC 4255, I can take it out in the -04 draft, because the other two examples probably suffice. > - Section 3.1 [. . .] > I think this note is too generic to make "informed decisions". I > suggest adding how these are ineffective or even harmful for each > case. In order to make the text in each case more focussed on the topic, we broke apart the discussion of what happens and the discussion of whether the check in question is actually effective. The effectiveness discussion does not address each use of reverse mappings, but treats them as classes of use and then discusses whether that class of use actually achieves its goal. We hope this makes the point more clearly that reverse mapping _alone_ offers at best a very weak piece of positive evidence for a conclusion. (Note that the negative evidence case might be different.) > - Section 3.1 [. . .] > As I pointed out in my comments on the previous version, this is > unfair or misleading. I'd rather make a new section "Examples of > effects of relying on reverse mapping", and put this example there, > without being specific to the "missing" case. We simply removed this section. It seemed to be attracting too much dissent for its importance in the discussion. > - Section 3.1 > Traceroute output [. . .] > I commented for the previous version that this did not seem accurate. > There are "may"s added in this version, but I don't think they address > the concern. The section is altered to say this: Traceroute output with descriptive reverse mapping proves useful when debugging problems spanning large areas. When this information is missing, the traceroutes can take longer, and those performing troubleshooting are left without useful hints. The "additional steps" section is here more concrete, and notes the exact benefit that accrues to the user of the reverse mapping. > - Section 3.3 [. . .] > I suggest adding some more text that explains why it's less pressing > in practical. We added "because the number of addresses affected is different" to the sentence, to spell out what the practical difference is. [. . .] > than 20010db81111...abcd.example.com). Overall, the effectiveness > of this approach [for hiding] should be discussed more carefully, > and in a more pragmatic way. The text as it is accords with the recommendation in draft-ietf-v6ops-scanning-implications-03, which discusses the "hiding" approach more thoroughly. Do you think we should add a reference to that draft? I have resisted that because this document has dragged on a long time, and I'd like not to hold it up with a possible downref, but if you really think the reference is needed we can add it. > - Section 4.1 > In general, the DNS response [. . .] > This sentence sounds indirect and vague to me. In particular, I'm not > sure if I understand the phrase of "what is supposed to be seen at the > address". This was text lifted directly from the list (contributed by Ed Lewis, if memory serves). It just means that, from any place on the Internet, there is a right answer to every query _for that querier_. That isn't to say that there is always one universally right answer to every query at a given time. (Note that this moved to section 4.2 in -03, because of the addition of another subsection.) > - Section 4.1 > It is desirable that Regional [. . .] > I'd like to see why. (As part of my main concern) For the reasons noted in my main argument above as to why we want to encourage reverse mappings. Note that this is merely "encourage", not "require". > - Section 4.1 [. . .] > In addition, it's not clear to me what "all IP addresses in use" > means. For example, if I manage an IPv6 subnet > "2001:db8:1111:2222::/64", are "the all addresses in use" the > addresses from 2001:db8:1111:2222:0000:0000:0000:0000 to > 2001:db8:1111:2222:ffff:ffff:ffff:ffff? Or does that only mean IPv6 > addresses assigned to existing hosts in that subnet? If the latter, > does that include IPv6 addresses configured via stateless > autoconfiguration and often missing from the network? What about IPv6 > temporary addresses? I realise in retrospect that I didn't understand this comment properly when reading it, on the basis of another message that I overlooked (I misfiled it) when working on the revisions. See my other message on this topic. I will send a proposed change to the text to the list. I apologise to you and the rest of the working group for being obtuse on this point. > - Section 4.2 [. . .] > I cannot be sure what "functions that depend on reverse mapping" > specifically indicates. An example might be helpful here. We are getting concerned about the length of the document, so didn't include another example. I suppose an obvious feature would be the display of hostnames discovered by way of the reverse map. Do you really think an example is needed? > I think this is too weak. Comparing to the strong "recommendation" in > the previous section that does not explain why, this part provides the > reason, so I think the recommendation can/should be tightened > accordingly. Referring to the text in the Security Considerations > section, my suggestion is: I don't understand how "no real security" is too weak. The Security Considerations section already says that people should use better forms of authentication, and it seemed to me that your proposed text was a security consideration about the use of reverse mapping itself, and not about the document or its application. (Maybe I'm just misunderstanding). The -03 draft is intended to make the "effectiveness" section clearer and cast in a greater light. > I'd also point out even the use of reverse mapping as a scoring system > can be controversial. I was unable to find a controversy around reverse mapping used in scoring systems, or even _any_ criterion used in scoring systems. The idea of scoring systems seems to be that you set the bases on which you wish to score, and then evaluate according to those criteria. The draft as it is has a fairly extensive discussion of the ways in which too great weight placed on non-matching or missing reverse mappings can cause "false positives". Every anti-spam person I talk to tells me that using reverse mapping in scoring is a very good, but not perfect, measure of spamminess. I have never met anyone actually operating a mail server who has given me a different opinion, but I'd be happy to hear from such people if they are out there. > 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. But in my understanding the essential problem of this > approach is "the use of the reverse tree provides no real security, > (and) can lead to erroneous results". This should still apply even if > "reverse mapping is universal". It doesn't actually say what you suggest it does -- "Not X until Y" means that Y is a necessary condition for X, but doesn't say Y is a sufficient condition. In any case, the point of the section is to discourage very strongly complete connection rejection on the basis of missing reverse mapping, until every host on the Internet has a reverse mapping. Since "heat death of the Universe prior to universal reverse mapping" is probably a safe bet, we thought this was enough. I didn't like the alternate text you provided because it seemed to lean on the argument that, since reverse mappings are not positive proof, therefore they're not useful negative proof. I don't think that's true in every case, and therefore we can't use it as a premise. Thank you again for your detailed reviews and helpful comments. I hope the above demonstrates the ways in which your review has strengthened the document; and explains, where your specific suggestions were not incorporated, why another path was taken. Best regards, Andrew -- 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
