Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt

[Dean Anderson <dean@av8.com>]

I think you are misunderstanding the draft.

> I believe the wg should work on this, and I basically support the
> intention of the draft.

I think it could be turned into a useful report on how to use in-addr, and
how not to use it.  It will take some editing, though.

> The draft, however, will need several clarifications.
>
> As already pointed out, the title (and the filename) does not reflect
> the content well and will thus need to be revised.  Abstract and
> introduction may also need a revise from this point of view.
>
> Secondly, if I don't misunderstand the intention, the draft says two
> things:
>
> 1. we need to try to build correct reverse mapping as much as
>    possible.

This sounds benign, and even laudable on the surface. However, as you
point out, the definition of "correct" is vague. The people who want to
use reverse as tool to identify spammers, and drop connections have a
particular notion of what "correct" is. That notion requires a "1-to-1 and
onto mapping" between forward and reverse. In other words, "correct" means
that every domain name must map to an IP address. The PTR record for that
IP must map back to that domain name.

This is exceedingly simplistic view of the network. For example:

(This is a made up example, but we do use this method) custrelay1.av8.net
has several IP addresses 130.105.0.1, 130.105.0.2).  This is so that one
IP address can be used for outbound connections, and the second can be
used for inbound connections. Only customers are given the forward name.
This reduces spam attempts. However, it you look up the name,
custrelay1.av8.net, you will find only one ip address:

1.0.105.130.in-addr.arpa.  1H IN PTR  relay1.av8.net.
2.0.105.130.in-addr.arpa.  1H IN PTR  relay2.av8.net.

custrelay1.av8.net.       1H IN A         130.105.0.2
relay1.av8.net.           1H IN A         127.0.0.1
relay2.av8.net.           1H IN A         127.0.0.1

Outbound connections using 130.105.0.1 don't "match". Spammers or abusers
harvesting headers from mail messages won't get a mail relay. Incoming
connections to 130.105.0.1 get a lot of OOB data and automatic
blacklisting, because no one should be connecting on this address.  And if
the abusers get wise, we can change things around a bit, using the other
address for inbound, etc. It doesn't affect my customers in the least.
They aren't even aware of a changes.  Some people assert this is somehow
incorrect usage. However, it is correct, and becoming more and more
common.  Its tremendously effective at stopping relay abuse, and for
detecting and blocking relay scanners. (though it is odd that the people
most upset by this are the relay blacklists)

> 2. applications should not rely on reverse mapping for several
>    purposes as they currently do.  The discouraged purposes include:
>    - rejecting ftp/telnet connections just due to the lack of reverse
>      mapping or failure of reverse-forward-reverse match.
>    - filtering rule in TCP wrappers due to the lack of reverse mapping
>    - regarding e-mail messages as spam if the sender address does not
>      have a reverse mapping

This is where you misunderstand. Although it seems contradictory to some
of the other language in the draft, the proponents don't think these are
inappropriate uses.  The idea is to make everyone else change their usage
of reverse so that these kinds of uses won't deny large numbers regular,
ordinary users, as is the case now.

> I don't much care about bullet 1, but I think bullet 2 needs some
> clarification.
>
> First, I'd like to confirm if my understanding above is correct.  The
> draft basically just says:
>
>    Applications SHOULD NOT rely on IN-ADDR for proper operation.
>
> But it is not very clear what the "proper operation" means.  I picked
> up the examples of the discouraged usage from Section 3 based on my
> understanding of the draft.  If I read it correctly, however, then I'd
> wonder why people who seemed to want rely on such a usage
> (e.g. rejecting ftp connections) are supporting the draft.
>
> Also, I'm not sure if all the examples in Section 3 are discouraged
> based on the intention of the draft, which include:
>
>   - (to try) logging the result of reverse lookup of a web client in a
>     web server
>   - reverse lookup in traceroute
>
> Finally, Section 4 needs to be clearer.  The draft says
>
>    The use
>    of IN-ADDR, sometimes in conjunction with a lookup of the name
>    resulting from the PTR record provides no real security, ...
>                                           ^^^^^^^^^^^^^^^^
>
> but, as already pointed out in this list, "security" is a broad term.
> I believe the draft should be clear on what kind of "security" it is
> talking about.

This is a concession to the people like me who have pointed out that there
is no security whatsoever.  It does not matter how broadly one defines
security, there is no implication that a matching forward and reverse
response indicate some kind of trust relationship between anyone,
anywhere.

>
> In summary, I'd like the draft
>
> - to clarify the first paragraph of Section 4, and
> - to add a concrete list of discouraged usage in Section 4

I think if the draft were changed so that the uses listed in section 3
were really discouraged, then the proponents would find it "turned on its
head" so to speak.


#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.