ietf
[Top] [All Lists]

Re: IP-based reputation services vs. DNSBL (long)

2008-11-11 12:36:20
Tony Finch wrote:
On Sun, 9 Nov 2008, Keith Moore wrote:
It is worth repeating that just because the notion of a reputation
service has value, and such services are widely used, does not imply
that using IP addresses as identifiers or the DNS protocol as a means of
transmitting reputation are technically sound.  There is reason to doubt
both of these assumptions, and there is no evidence that these design
questions have been given due consideration and resolved - as our
process would normally require.

Could you give us a reference to an explanation of why the DNS might not
be a sound choice of protocol for reputation services?

My concerns are along the following lines:

1. suitability of the DNS data and query model.  right now this protocol
essentially communicates one bit of information to be used in a decision
- i.e. whether the address or domain name is good or bad.  I suspect
that more information is needed to really make a good reputation
service.  I have doubts about whether DNS lends itself to including that
much information.  (It also bugs me that multiple queries are required
to  get the information necessary to perform a bounce/relay decision and
to bounce a message... granted that this is a flaw in the DNS protocol
design but using DNS for unintended purposes exacerbates the problem)

2. this is a very different use case than DNS was intended to address,
and implicit and explicit assumptions in the DNS design might not hold
for this case.  e.g. assumptions about how long information remains
valid and how widely it should be replicated.

3. security.  it might be that mechanisms already defined or used with
DNS (DNSSEC, source port randomization) are adequate, but I'd like to
see more analysis done.

4. effects of DNS caching.  if a host is removed from a blacklist it
should arguably be removed from all caches instantly, but DNS isn't
designed to facilitate that.  again, blacklisting someone else's IP
address is a different use case from managing the addresses associated
with your own hosts.  If you manage your own hosts' DNS RRs then you can
 tailor your operations to accommodate changes in DNS records, and you
can (at least in theory) adjust your TTLs in advance of any changes to
minimize the potential for disruption when you do need to change things.

5. slippery slope.  DNS is a vital service, and one that is very
difficult to replace.  It needs to remain focused on a narrow goal.  The
more we overload DNS, the more we threaten to add complexity that will
make it more fragile.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf