At Mon, 26 Feb 2007 16:30:46 -0500,
Andrew Sullivan <andrew@ca.afilias.info> 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.
					jinmei@isl.rdc.toshiba.co.jp

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop