Re: [DNSOP] WGLC: "Considerations for the use of DNS Reverse Mapping"

JINMEI Tatuya / 神明達哉 wrote:
> At Fri, 14 Mar 2008 04:45:00 +0100,
> Peter Koch <pk@DENIC.DE> wrote:
>
>   
>> in accordance with the roadmap posted the other day, this is to initiate
>> a working group last call on
>>
>> 	"Considerations for the use of DNS Reverse Mapping"
>> 	draft-ietf-dnsop-reverse-mapping-considerations-06.txt
>>
>> ending Friday, 2008-04-04, 18:00 UTC.
>>
>> The document is aimed at a status of "BCP".
> As a meta (and most substantial) level, this version still doesn't
> answer the fundamental question I asked a year ago: "why *should* one
> provide reverse mappings for all IP addresses they manage? (despite
> the cost of the provision)?".

I'd like to get a better understanding of your concern.
Is it that you don't understand why one should, or that the document 
doesn't include the answer itself?

In other words, if someone on the list answers the question, without 
that changing the document,
would you then support it based on your new-found understanding?

>
> Since this document does not provide a convincing answer (at least to
> me) for the question of "why I should", I, as an operator, will still
> only provide reverse mappings as a best effort basis (i.e., I may not
> provide them even if there is no "*strong* counter-considerations").
>   

What you are saying, then, is that as a BCP, the guidance provided would 
be something you would
ignore.

The *point* of the language, is to gently nudge those who may otherwise 
not have a strong opinion
on the matter, to adopt the practice which results in the greatest level 
of interoperation and cooperation.

Presuming it is adopted and reaches BCP status, operators wishing to be 
considered within their
community as "responsible" operators, would take its advice at face value.

Which is to say, absent *strong* counter-considerations, to provider 
reverse mappings.

What I don't understand about your question is, if you don't *have* any 
strong counter-considerations,
then why would you oppose doing reverse mappings? And likewise, why 
would you oppose adoption
of this language - again, if there are no strong counter-considerations?

Basically, the best way to describe the choice of language is, that 
doing reverse-mappings won't hurt
anything or anyone, in general, and achieves some benefit. However, the 
benefit is lost, and the use
of the reverse-mappings becomes a hindrance, if they are not applied 
nearly universally - i.e. where
IP addresses are in use, and occur in a forward mapping somewhere in the 
DNS.

This is because,
absent omniscient awareness of the complete population of the DNS 
system, a host cannot know
in advance whether a reverse entry exists without querying for it. And 
if querying for it does not
produce either a fast positive (answer) or fast negative (some kind of 
response), then the act
of checking *if* a reverse entry exists, causes problems for the 
host/application.

It's a question of utility. If you believe anyone benefits from reverse 
mappings, then you support
the existence of in-addr.arpa and ip6.arpa. And from there, it only is 
useful if it is populated.

Conversely, arguing against populating it, is to argue against its 
existence at all.

> For example I won't provide reverse mappings if I simply cannot (or
> don't want to) afford the operational cost.  And I'm afraid I'm not
> just one of very few lazy operators; rather, I think a non negligible
> number of ordinary operators will take a similar action.  On the other
> hand, since this document only requires "thinking carefully" about
> adopting (dubious) access control based on reverse mappings, operators
> who are currently deploying it will simply continue the operation,
> probably with quickly "thinking about it" as an excuse.  I'm also
> afraid the unbalanced level of recommendations (i.e., "should provide
> reverse mappings" vs "are encouraged to think about it before using
> it") will give an excuse for such operators (revmap users) to continue
> it.  The end result will be a (continued) poor interoperability, and
> the "excuse" may even make it worse.
>
> My interpretation from the discussions so far is that the issues are
> too subtle or controversial to provide a convincing reason for
> declaring a specific requirement with such a strong word as "should".
> Maybe future changes in operation like wider deployment of IPv6 and/or
> DNSSEC, or changes in the relationship between the existence of reverse
> mappings and SPAM, may change the practice more clearly and we can
> revisit it.  But, in my understanding, the "best current practice" we
> can agree today is to simply state issues without a strong
> recommendation.
>
> I proposed one specific change to Section 4.4 a year ago along with
> this point:
>
> From
>
>    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.
>
> To
>
>    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.
>
> I believe this is more fair compared to the counterpart for the users
> (i.e., "encourage to think about it carefully") and is more realistic
> with the understanding (of mine) that a strong requirement with no
> convincing reason will be ignored anyway.  Is there any reason we
> cannot adopt this text?  If this is something we can "live with", I
> sincerely request adopting it.
>
>   

I do not believe this is something we can "live with" at all.

Providing an "easy out" to anyone who wants one, defeats the purpose of 
the document.

And consider this, when bring up "cost":

IP addresses are not property. They are provided by central assigning 
authorities, for use, and
with the expectation that they be managed, and managed properly.

Part of the expectation in assigning IP address blocks, is that the 
assignee will receive the delegation
for that block, within in-addr.arpa.

So, there is already a large expectation on managing the address space, 
and for having DNS servers
for the in-addr.arpa zones that correspond to the space. The 
*incremental* cost in populating the
zone accurately, is negligible.

And generally, the receipt of IP addresses has with it, a cost of 
maintenance on a yearly basis already,
so the idea that an IP address shouldn't have an operation cost 
associated with it, is already a falacy.

How an operator minimizes the operational cost, is just a part of doing 
business, and left as an exercise
for the operator.

> One more possibly related thing: what does this document recommend
> about "matching reverse data"?  While I still haven't understood why
> we are required to provide reverse mappings, if it's something related
> to that "administrators at other sites sometimes use reverse mapping
> as one of several pieces of evidence in evaluating connection traffic,
> particularly in the context of mail systems and anti-spam efforts."
> (from Section 4.4), then the recommendation without also requiring the
> provision of matching reverse data would be incomplete.
>
> The following are specific comments on the text more or less along
> with this major point.  I also have a trivial/less controversial
> comments; I'll send them in a separate message so that they won't be
> buried in the controversy.
>
> Section 3.2
>
>    Reports from operators suggest that scoring mail on the basis of
>    missing or non-matching reverse mapping remains an imperfect but
>    useful measure of the likelihood that a given message is spam,
>    particularly in combination with other measures.  It is clear that
>    the presence of reverse mapping, and a match between the forward and
>    reverse zones, is neither a necessary nor sufficient condition for a
>    candidate message to be spam.
>
> I'm not very much comfortable with a statement based on "some people
> say something" because it's difficult to assess its validity.  In
> fact, I cannot really be sure that reverse mapping-based approach is
> that effective, considering the fact that most of today's spams are
> sent from botnets and the reverse mappings are often provided (when
> provided) by the ISP, rather than the end users who host the bots.
>   

It does not matter  *how* effective it is, nor in what way it is used.

The point is, it *is* used, and thus, is a strong justification for 
preserving and enhancing the population
of reverse mappings. The fact that reverse mappings *alone* aren't a 
good way of doing things,
doesn't mean that they aren't of value in a complex mechanism that uses 
them.

> I'd rather like to see a solid reference that describes how exactly
> effective of this type of scoring is, both in terms of the ability of
> identifying spams and of the ability of avoiding false positives.
>
> I'd also like to add a reference to research work in this area that
> doesn't rely on reverse mapping, such as a SIGCOM '07 paper:
> http://www.sigcomm.org/ccr/drupal/?q=node/267
> This is not related to DNS or reverse mapping specifically per se, but
> I think it's useful to show people who naively believe the power of
> reverse mappings that there are alternatives, which might be more
> trustworthy, for their purposes.
>
> Section 3.4
>
>    The larger address space of IPv6 also makes possible "hiding" active
>    hosts within a large address block: the impracticability of scanning
>    an entire IPv6 network for running network services means that an
>    administrator could effectively conceal running services in an IPv6
>    network in a way not possible in an IPv4 network.  Such hiding would
>    be prevented by a reverse mapping that revealed only existing hosts.
>    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.  This approach
>    is consistent with the suggestion outlined in section 4.2, below.
>
> I pointed out the suggested alternative might be too optimistic in
> terms of reality in my previous comment:
> http://www.ietf.org/mail-archive/web/dnsop/current/msg05411.html
> this version still doesn't address the concern.  I'd like to propose
> the following change, which I believe is more realistic.
>
>    ... If such "hiding" is desirable, one possible alternative is 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.
>    It should still be noted, however, that this approach may not
>    easily be realized with deployed implementations, and that
>    automatically generated host names that are often used in this
>    approach may make them useless. ...
>
>   

If you don't know how to do this, then please ask for help in doing it, 
rather than making the
above suggestion. I'm sure there are folks who would be happy to help 
you, or to explain
some of the subtleties of steganography that this represents.

> Section 4.2
>
>    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.
>
> Maybe I'm too dull, but I've never succeeded to understand the meaning
> of this sentence (I asked the same question on a previous version of
> the draft, but this point has never been clarified).  In particular, I
> don't understand what this means: "what is supposed to be seen at the
> address by the machine initiating the query".  Can't this be more
> clarified?
>   

It is very plain language.

What it means is, if the machine thinks its name is "fred", and will provide
a login prompt of "fred", and speak SMTP using the name "fred", then the 
reverse map should
in some way include "fred", and not "george".

> Also Section 4.2
>
>    Unless there are strong counter-considerations, such as a high
>    probability of forcing large numbers of queries to use TCP, IP
>    addresses in use within a range and referenced in a forward mapping
>    should have a reverse mapping.
>
> I failed to understand this sentence.  Does this mean
>
>    IP addresses that are
>       - in use within a range, and
>       - referenced in a forward mapping
>    should have a reverse mapping.
>
>   
This one - if *both* conditions are met.

A secondary means of doing forward/reverse population is to set up 
unique dummy names, for those IP addresses
not in use, or for which no forward map exists (other than the dummy). 
This may in some cases be preferable
to not populating reverse mappings if no forward mappings exist.
> or
>
>    - IP addresses that are in use within a range, and
>    - IP addresses that are referenced in a forward mapping
>    should have a reverse mapping.
>
> or something else?  In either case, does this mean we don't have to
> provide reverse mappings for addresses that are NOT referenced in a
> forward mapping?
>
> I also asked the precise definition of 'in use' (especially in the
> context of IPv6 stateless address configuration) in my previous
> comment, but it's still unclear in this version.
>
>   

For example - if an address is in use, *and* has a forward mapping, then 
likely it is doing dynamic dns.
In such an instance, it would be advisable to have the dynamic dns 
system handling the forward mapping, also update
the reverse mapping.

> Section 4.4
>
>    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.
>
> (Again, I commented on this before) I don't follow the logic here.
> Repeating my previous comment:
>
>   
>> 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.:
>>     
>
>   

No.

It does not presuppose that any particular policy regarding connection 
rejections will be adopted,
nor does it encourage such.

It merely embodies the syllogistic logic of "A implies B", also means 
"NOT B implies NOT A".

It says, in order to rely on reverse mappings for connection rejection, 
the reverse mappings must be universal.
They are not universal, therefore they should not be relied on 
completely for connection rejection.
And, should the status of their non-universality change, this issue 
becomes moot.

>>   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.
>>     
>
> Perhaps my suggested text is too biased toward discouraging the
> dubious use of reverse mappings, but at least I want to see something
> that is logically more understandable.
>   

While your text may be more understandable, it embodies much that was 
deliberately excluded, so it won't likely
be seen as acceptable by the authors or by the majority here, I would 
expect.

If you re-read the text, after reading my explanation, does it seem 
clearer now?

Sincerely,

Brian Dickson
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop