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 AAAA 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/AAAA 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/AAAA
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 get a clarification on whether or not this document is
recommending anything with respect to "forward" (A/AAAA) records? Or, if
it is simply a _presumption_ that every "in use" device in every address
range, has at least one A/AAAA record in DNS, then perhaps this
presumption should be spelled out clearly in the first part of the
document (if it is already, I apologize for missing it, even after a
couple of re-reads).
- Kevin
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
