Dear colleagues, We have read draft-irtf-asrg-dnsbl-07. We have some comments on the draft in response to the last call. We wish to emphasise that, while we currently serve as the co-chairs of the DNS Extensions working group, these comments are merely our own, and are not representative of the views of the working group. We believe we understand the purpose of DNSxLs, and we think they can, in some circumstances, provide a useful service (even though they sometimes cause difficulty for users of Internet mail). We also think that describing current behaviour of DNSxLs is a good thing. That said, we are uncomfortable with the draft in its current form, and are strongly opposed to adopting it as a Proposed Standard. We believe that most, but not all, of the draft would be an excellent candidate for adoption as an Informational document. One problem with the document is its outline of the way that DNSxLs use A records to indicate reasons to accept or reject traffic from a given site. The trouble is that these A records are not host addresses, even though that's the definition of an A record. The A records merely _look_ like host addresses. In order to understand that they are not host addresses, you have to know what DNS server you are querying and interpret the owner name at the record. What this really does is use the context of the query, plus the content of the query and answer, as meta-data in order to add new semantics to A records: if you happen to query server dnsbl.example.org with just the right owner name, you get an A record that is not a host address. Note that merely knowing the DNS server name is not enough: the document points out that if you query the same server with a different owner name, you might get an A record that _is_ a host address. In addition, the context of the answer determines its use: the same server can use the same zone data to provide whitelist and blacklist services to two different groups of querying agents. Now, it is surely a service to the Internet community to document that there are DNS servers where the content of the answer determines the semantics of the record, but we don't really think this is something that we should plan to advance on the standards track. It seems plain to us that the reason DNS has RRTYPEs is so that the client doesn't need to guess what kind of record it has when it gets a resource record. In our view, the document really needs to make clear that DNSxLs are violating the semantics of A records when they make this use of them. One way to do that would be to modify the first paragraph in section 2 along the following lines: A DNSxL is a zone in the DNS[RFC1034][RFC1035]. The zone containing resource records identifies hosts present in a blacklist or whitelist. Hosts were originally encoded into DNSxL zones using a transformation of their IP addresses, but now host names are sometimes encoded as well. Most DNSxLs still use IP addresses. The zone accepts and responds to DNS queries in apparently standard ways. The zone data, however, is not DNS data, and has special semantics that can be understood only in the context of the DNSxL service. In particular, A records returned by the server usually do not contain a host address. Instead, they usually contain a 32 bit value to be interpreted as bitfields. For historical reasons, implementations used the DNS A RRTYPE to represent these values, rather than a distinct RRTYPE. As noted in section 5, some A records in a DNSxL zone MAY contain host records. How clients interpret different A records in the same DNSxL zone is implementation- and context-dependent. In addition, the document proposes to continue using the existing mechanism in order to support IPv6 hosts. There is little evidence of a widespread deployment of such use, and there is therefore still time to come up with a better solution that does not overload the meaning of RRTYPEs before we have widespread use of IPv6 mail infrastructure. Therefore, in our opinion, extending the current practice to IPv6 hosts is not a good idea. The current draft makes the best of a bad principle, but it should recommend an alternative approach as preferable. One simple solution would be to introduce one or, better, two new RRTYPE(s) that work(s) exactly the same way as the A RRTYPE, so that deployed software would need to be modified only to query for the new RRTYPE instead of an A record. We appreciate that a long, or maybe indefinite, transition period would be needed. Presumably, however, the widespread introduction of IPv6 in the mail infrastructure of organisations will occasion the installation of new software as well. Best regards, Olafur Gudmundsson ogud@xxxxxxxx Andrew Sullivan ajs@xxxxxxxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf