Subject: Re: [DNSOP] Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-02.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 20 Mar 2007 00:58:38 +0900

At Mon, 26 Feb 2007 16:30:46 -0500,
Andrew Sullivan <[email-masked]> 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-masked]

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 20 Mar 2007 00:58:38 +0900

(snip)

- Section 1.1

- Section 1.2

- Section 1.3

- Section 1.3

     Moreover, some

- Section 3.1

- Section 3.1

- Section 3.1

- Section 3.3

- Section 3.3

- Section 4.1

- Section 4.1

- Section 4.1

- Section 4.2

- Section 4.3

					JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Mar 2007 18:25:54 +0100

One thing that popped for me during your presentation today, Andrew,  
is that you say that the stupid things people are doing with the  
reverse zone have to work.   This isn't true.   They don't have to  
work.   If they are stupid, they oughtn't to work.   E.g., if your  
ssh server is checking your reverse record to make sure you are who  
you claim to be, it's kind of missing the point - it should be  
checking your public key.

For me, the sole function of the reverse zone is as a hint for  
figuring out who I'm talking to.   There are two specific cases where  
I find this particularly viable:

1. I want to find the forward pointer for a specific host so that I  
can find additional information attached to it, in cases where I've  
already decided the host I'm talking to is worth talking to based on  
non-DNS mechanisms.
2. I am trying to figure out why and how something is broken, and  
want a hint as to who is talking to me.

These are both very important uses to me, particularly the second.    
In cases where there is no reverse entry, debugging gets a lot  
harder.   This is why I'm in favor of documenting and encouraging the  
population of the reverse tree.   I do not think that supporting  
peoples' broken "authentication" schemes is a reason.    I haven't  
objected strenuously to the language in the document because I don't  
think it actually encourages these schemes, and I think for  
historical reasons it's useful to mention that such schemes are extant.

But they do not "have to work."   And if you think that they do, you  
may be unintentionally saying things based on that belief that are  
setting off some of the people who are objecting to this document.    
So it might be profitable to actively stop thinking that these  
applications have to work - they really, really don't.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Mar 2007 18:25:54 +0100

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Mar 2007 14:58:07 -0400

On Mon, Mar 19, 2007 at 06:25:54PM +0100, Ted Lemon wrote:
> reverse zone have to work.   This isn't true.   

Yikes.  If that's the way I put it, my apologies; it certainly isn't
true.  

What I think _is_ true (and what I was meaning to say) is that some
people say that some uses of the reverse tree are useful for them.  In
order for those uses to work, the reverse lookups have to work.  Or,
to put this another way, for the reverse tree to be widely useful, it
has to be fairly widely implemented; and to the extent people stop
implementing reverse mappings, the reverse tree in general gradually
becomes less useful.

> They don't have to work.  If they are stupid, they oughtn't to work.
> E.g., if your ssh server is checking your reverse record to make
> sure you are who you claim to be, it's kind of missing the point -
> it should be checking your public key.

I believe that there are cases where people apparently believe they
are getting authentication via reverse mappings.  Your example of
using the matching reverse to authenticate an ssh connection would be
an absurd but clear example of this.  Some of those uses are, of
course a historical accident.  Some such uses are, I agree, also
stupid, and they indeed need not work.

But there are some controversial uses where some people claim checking
for matching or existing reverse mappings is useful even as others say
emphatically that the check is bad, evil, wrong, or just silly.  The
obvious case is disagreement on using reverse mapping as a hint in
spam-candidate scoring.  Some users report that, based on the analysis
of their own traffic, some sort of reverse mapping test is a useful
indicator.  Others correctly point out that such a rule runs the risk
of false positives and also does not catch all spam.

My (editorial) view on this is that, given there are uses where some
people who understand the limitations of the facility nevertheless
claim there is utility in their own case, in the absence either of
numbers to show that the wrong empirical conclusion has been drawn or
that the use case is implicitly broken, then such a use is not
obviously stupid.  (It is also my personal, non-editor opinion that
part of the strength of the Internet comes from the way that such
decisions can be made on a case by case basis at the edges, according
to the uses that network administrators find for themlselves, assuming
those administrators are correctly informed about the consequences of
those decisions.)

So, the intent of the text is precisely to say, on the one hand, that
someone who is trying to use reverse mappings needs to understand the
limitations of the implementations on the Internet; and on the other
hand, that network operators should implement the reverse mappings in
the absence of strong counter considerations, because the
implementation is needed for these various use-cases to work.

Does that clarify my remark?

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Mar 2007 14:58:07 -0400

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Mar 2007 23:06:48 +0100

> implementing reverse mappings, the reverse tree in general gradually

Interesting, I can see where the disconnect is happening.   I see  
what I said and what you said you meant (rather than what I said) as  
the same thing.   See, if it doesn't matter that the broken things  
people are doing with the reverse tree work, then you can't say that  
the reverse tree has to work for them to use their broken things,  
because we don't want them to use their broken things.   So whether  
or not they need the reverse tree to work is irrelevant to us, the IETF.

>  The obvious case is disagreement on using reverse mapping as a  
> hint in

This is perfectly reasonable, because what you are doing is catching  
them in a lie.   You don't know that the data in the reverse tree is  
correct just because the forward tree agrees with it, but if they do  
not agree, then you have detected a lie (or, to be charitable, a  
mistake), and that is information - it would be wrong to say that it  
is not.   On the other hand, plenty of scoring systems that use the  
reverse tree can't be described so charitably.

> obviously stupid.

Actually, there is one reason to consider it stupid: I might have  
control over my forward tree, but not over the reverse tree for the  
IP address I have.   That doesn't mean I'm a spammer - it just means  
I have a lousy ISP.   And, sad to say, that's most ISPs.  So in this  
case, it is a broken configuration, for some value of broken, but  
it's not my fault that it's broken, and I can't fix it, so it's not  
really fair to score me as a liar.   Fortunately, in a spam scoring  
system, as long as you don't use this as your exclusive score, it's  
probably okay - hopefully other indicators will tell you a different  
story.

> implementation is needed for these various use-cases to work.

So how many of the examples you give are reasonable, in the sense of  
detecting a lie or misconfiguration and using it in a scoring system,  
and how many are unreasonable, like my ssh example?   If the number  
of the latter is not zero, that might explain the pushback you've  
been seeing.

> Does that clarify my remark?

It doesn't matter.   What matters is whether your document is  
clear.   And what I'm trying to point out is that what I've noticed  
may be a reason why it's not clear to some readers.   The cure is for  
us to think about this and modify the document accordingly, not for  
you to explain here on the mailing list what you meant.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Mar 2007 23:06:48 +0100

---

From: Evan Hunt <[email-masked]>
Date: Tue, 20 Mar 2007 01:04:44 +0000

> IP address I have.

But, as I understand it, that is *exactly* the datum that people who use
the reverse tree for spam detection are interested in.  They want to know
whether or not you have control over your reverse tree.  If you don't,
then the odds that you're a fly-by-night operator are somewhat higher
than if you do.

> That doesn't mean I'm a spammer - it just means I have a lousy ISP.

Spam mitigation is obviously an uncertain business.  But if something is
empirically found to be a useful clue (amid a constellation of other
clues), then it'd be foolish to ignore it.

I'm not an expert on spam mitigation, but I've talked to people who are,
and been told that reverse DNS is one of the two or three most useful tools
in their toolboxes.  That's not just made up out of nothing (as Dean
Anderson seems to be alleging in his draft); it's based on real empirical
analyses of spam trends, and rates of success and failure at filtering.

Now, clearly, there are no immutable laws of nature here.  Sources of spam
change over time; perhaps by 2009 or 2010 it will no longer be useful to
test whether a reverse tree is populated.  (Indeed, the more useful a test
*is* at rejecting spam, the stronger the pressure for spammers to find a
way to pass the test.  The half-life of useful tests is probably pretty
short.)  All I know is, right now in 2007, people I consider both
trustworthy and knowledgeable tell me it's useful, and quote statistics
to back the claim.

(There are high-traffic mailing lists on this very subject: have any of
them been consulted about this?  I'd be interested in their take on the
matter.)

--
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 20 Mar 2007 01:04:44 +0000

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Mar 2007 21:23:59 -0400

On Mon, Mar 19, 2007 at 11:06:48PM +0100, Ted Lemon wrote:

> Fortunately, in a spam scoring system, as long as you don't use this
> as your exclusive score, it's probably okay - hopefully other
> indicators will tell you a different story.

Right; this is why I think the "security" and "utility" questions
can't be answered in a binary way.  Sometimes the answer depends very
much on what _else_ you know.  It's clear to me, though (from your
very helpful remarks as well as from some other comments that I've
received) that such a message just isn't clear enough in the draft as
it stands, which is why we need another round.

> of the latter is not zero, that might explain the pushback you've  

Yes, I think you're right, and I appreciate the observation.  (And
certainly, the number of unreasonable uses is not zero, or we would
have found consensus long ago.)

> The cure is for us to think about this and modify the document
> accordingly, not for you to explain here on the mailing list what
> you meant.

No question.  My point in explaining here what I meant is rather to
see if a different expression of my meaning makes that meaning clearer
to others, because that gives starting points for what text can
improve the draft.  I really appreciate the feedback, since it enables
me to focus more carefully on the places where my own poor edits to
the draft have obscured meaning or have sent the wrong message.

In that spirit, let me ask whether including the following 
notions (not yet actual text for inclusion) would help:

1.  An attempt to use reverse mappings as a single-source authentication
    or security mechanism is almost always a very bad idea, and may
    actually undermine better security or authentication
    practices. [How do we make the text say this more clearly?  I
    thought it already says this plainly in some places, but I guess
    not.]

2.  Some people report that using evaluation of the reverse mapping
    (either for existence or matching) is sometimes useful, especially
    in the presence of other data about the connecting host.  [Also,
    does a DNSSEC-enabled reverse tree help here?  Perhaps concrete
    examples would be more helpful?  I'm leery of the latter, because
    the state of affairs in this area is liable to change.]

3.  In most cases, a weaker reliance on reverse mapping tests will
    yield better results, because the risk of false positives (and the
    consequent failure modes) is lower.

4.  The [potential?] utility of the reverse tree to all users of the
    Internet declines as fewer people implement reverse mappings.  [I
    think this is implicit throughout the draft, but it maybe needs to
    be stated baldly?]

5.  Maintaining reverse mappings (especially matching reverse
    mappings) is not free for operators of networks, and in some cases
    that cost may outweigh the benefit to anyone, such as is the case
    where the number of entries cause the query response to require
    truncation.

Someone also hinted to me that a new section comprising a short survey
of the history of some practices -- especially those that now fall
into the category of "obviously bad" -- would help frame the
discussion.  Do people think that would be useful?  (I worry it could
be a rathole out of which the draft would never emerge, but I
nevertheless see how it could clear up confusion for operators who
don't care what an IETF is, but are looking for guidance on what to
do and why something they heard about once as a good idea is no longer
widely viewed as helpful.)

Thank you very much for the comments and insights.  

A

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Mar 2007 21:23:59 -0400

A

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Mar 2007 10:52:33 +0100

> then the odds that you're a fly-by-night operator are somewhat higher

This is not germane to the discussion, but it would be a great issue  
to waste mailing list bandwidth on.   So please let's not.   We  
really don't need to discuss the vagaries of spam assassination here.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Mar 2007 10:52:33 +0100

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 20 Mar 2007 20:09:39 +0900

At Mon, 19 Mar 2007 14:58:07 -0400,

> of false positives and also does not catch all spam.

Actually, the current draft has the same subtle nuance as the above
paragraphs, and I believe that leads to the vagueness I'm seeing.
Let's count the number of "some"s in the above text; in general, the
current draft seems to state: "some people think some use cases of
reverse mapping are useful (and some people think some other use cases
are harmful).  So you should provide reverse mapping for all IP
addresses you are managing".  The problem is that different people may
have different definitions of the "some".  I guess the discussion in
this thread proves that's the case.

As I mentioned earlier, if the objective of the document is to just
list various views and issues regarding reverse mapping without
judging they are good or bad, such "vagueness" might be justified.
But since we now know the goal is to recommend that people *should"
provide reverse mapping, I believe leaving the large room of
interpretation is just dangerous.

> that the use case is implicitly broken, then such a use is not

I'd accept this view itself.  But if we are then going to recommend
people should provide reverse mapping based on it, I'd not be
convinced because, at least to me, the use "that is not obviously
stupid" does not outweigh the operational cost at the provider side.
IMO, the requiring side is responsible for providing numbers to show
that the wrong empirical conclusion has NOT been drawn and that the
use case is NOT implicitly broken.  The current draft does not show
the evidence while putting all the burden to the required side.

Seeing the controversy and varied opinions, I'm now feeling the best
thing we can do is to simply list the issues and controversy regarding
the use of reverse mappings without any specific recommendation (at
least about whether an IP address holder should provide reverse
mappings).

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 20 Mar 2007 20:09:39 +0900

JINMEI, Tatuya

---

From: Evan Hunt <[email-masked]>
Date: Tue, 20 Mar 2007 19:05:58 +0000

> really don't need to discuss the vagaries of spam assassination here.

I wholeheartedly agree that the vagaries of spam assassination aren't
relevant to this list, and I'd prefer not to read a lengthy debate about
them, especially among people who aren't well-versed in the subject (a
category that includes myself).  But spam fighters are a real constituency,
who (so I'm told) get real and useful information from reverse DNS, and
they don't seem to be very well-represented here.

Bottom line, I'm fairly comfortable with vagueness in this case.
Reverse DNS is reportedly an effective tool for spam detection in 2007,
so we shouldn't make the assertion that it *isn't* useful for that.  But
that test isn't entirely reliable now, and may become less so over time, so
we don't want to assert it *is* useful, either.  The vague middle way seems
like the only real option to me:  it has been found to be useful in some
circumstances, and is commonly used; however, it produces false positives
and is controversial.  That's more or less what's in the draft now.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 20 Mar 2007 19:05:58 +0000

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 26 Mar 2007 21:16:09 -0500

> 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

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 26 Mar 2007 21:16:09 -0500

- Kevin