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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf