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.
Specific comments on the draft follow: (some of which are irrelevant
to the main concern)
- 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".
- 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.3
In recent years, some sites have come to rely on reverse mapping as
part of their administrative policies even as other sites have
stopped maintaining useful reverse mappings of their addresses.
What are "useful" reverse mappings? I'd rather remove this word, then
it will be a mere fact and clear to read.
- Section 1.3
Moreover, some
protocols that store data in the DNS, such as those described in
[RFC4025], [RFC4255], and [RFC4322], could benefit from matching
reverse mapping data, particularly when combined with the use of the
DNS security extensions ([RFC4033],[RFC4034],[RFC4035]).
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.
- Section 3.1
Following are some examples of some of the uses to which reverse
mapping checks are put, and some of the difficulties that can be
encountered because of missing reverse tree records. It is important
to note that these strategies are at best often ineffective, and are
occasionally considered harmful. [...]
I think this note is too generic to make "informed decisions". I
suggest adding how these are ineffective or even harmful for each
case. For example,
+ as for spam checking, there are actually many spams sent from an
IP address that has reverse-forward matching, while many hams sent
from an IP address that doesn't have a reverse mapping or fails in
reverse-forward matching. In addition, since providing
reverse-forward matching is basically easy, spammers will simply use
a bot client that is located within an ISP that provides
reverse-forward matching for their customers.
+ the same point applies to the FTP/telnet examples.
+ regarding the detection of geopolitical entity, we should
explicitly note that a reverse mapping does not necessarily
indicate such info; an IP address whose reverse mapping is xxx.jp
does not necessarily mean it's located in Japan, etc.
+ we should also note that information provided via DNS can be
forged various ways unless DNSSEC is widely deployed. It should
also be noted that even if the integrity of the information is
confirmed via DNSSEC, it does not mean the owner of the host that
has the IP address is a good guy.
- Section 3.1
Poor or missing implementation of reverse mapping on dialup, CDPD and
other such client-oriented portions of the Internet results in higher
latency for queries (due to lack of negative caching), and higher
name server load and DNS traffic.
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.
- Section 3.1
Traceroute output with descriptive reverse mapping proves useful when
debugging problems spanning large areas. When this information is
missing, the traceroutes may take longer, and it may require
additional steps to determine what network is the cause of problems.
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.
- Section 3.3
There is a similar issue for IP6.ARPA,
although in practical terms it is less pressing.
I see what this means, but I'm not sure if this is obvious for those
who are not familiar with IPv6. I suggest adding some more text that
explains why it's less pressing in practical.
- Section 3.3
If such "hiding" is desirable, it is possible nevertheless 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.
I'm not sure if I buy this argument. In this context, the segment of
the network that has reverse mappings should be so large that it can
make address scanning ineffective. But naively adding those PTR
records to a DNS server may not be realistic due to the required data
size or memory footprint. We might add a plugin to the DNS server
that automatically generates a PTR record for a given address, but if
the generated host names follow some rule (e.g., embedding the address
into the host name) while other "active addresses" don't, the attacker
may exploit the difference. We could use such auto-generated
addresses even for active addresses, but the result may not be very
convenient (we'd prefer "mail.example.com" for a mail server rather
than 20010db81111...abcd.example.com). Overall, the effectiveness of
this approach should be discussed more carefully, and in a more
pragmatic way.
- Section 4.1
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.
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".
- Section 4.1
It is desirable that Regional Registries and any Local Registries to
whom they delegate encourage, or continue to encourage, reverse
mappings.
I'd like to see why. (As part of my main concern)
- Section 4.1
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.
I have a concern of this sentence, as stated above. If there is a
convincing reason that can support this strong recommendation, I
believe it should be explicitly described here. If we cannot provide
the reason, I suggest weakening the phrase like:
A network administrator is encouraged to provide a reverse mapping
for IP addresses in use within a range of the network if
administration cost is acceptable according to the local policy.
In some cases the administrator may rather want to avoid providing
reverse mapping; for example, when there is a high probability of
forcing large numbers of queries to use TCP.
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?
- Section 4.2
Applications should not rely on reverse mapping for proper operation,
although functions that depend on reverse mapping will obviously not
work in its absence.
I cannot be sure what "functions that depend on reverse mapping"
specifically indicates. An example might be helpful here.
Operators and users are reminded that the use
of the reverse tree, sometimes in conjunction with a lookup of the
name resulting from the PTR record, provides no real security, can
lead to erroneous results and generally just increases load on DNS
servers.
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:
Operators and users should not use reverse mapping, sometimes in
conjunction with a lookup of the name resulting from the PTR
record, as a security mechanism; it provides no real security, can
lead to erroneous results and generally just increases load on DNS
servers.
- Section 4.3
In the context of anti-spam efforts, administrators are reminded that
complete rejection of a connection (on the basis of missing or non-
matching reverse mapping) is extremely controversial. It may
interrupt or prevent the transmission of legitimate mail.
I'd also point out even the use of reverse mapping as a scoring system
can be controversial.
Some users continue to report difficulty in ensuring complete
population of the reverse tree by upstream providers. This situation
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. 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". So I'd rewrite it to, e.g.:
Some users continue to report difficulty in ensuring complete
population of the reverse tree by upstream providers. This
situation can be improved by the provision by those providers of
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.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
