On Tue, Dec 20, 2016 at 7:16 AM, tjw ietf <tjw.i...@gmail.com> wrote:
> The draft is being present as "Informational", and the point here is to > document current working behavior in the DNS (for the past several years). > It is obvious that some feel this draft is a large mistake, but like > edns-client-subnet, more operators are deploying this than one is aware of. > > This starts a Call for Adoption for draft-vixie-dns-rpz > > The draft is available here: > https://datatracker.ietf.org/doc/draft-vixie-dns-rpz/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. I'm still reading the 04 version of draft-vixie-dns-rpz and intending to make comments on it later, but I'd like to respond to the call first: I do not think it's suitable for dnsop to adopt the draft in its current form, with the intent of "just describing currently deployed practice", and (as I guess) with the intent of eventually publishing as an (Informational) RFC. But I think the document itself is very useful, so it would be nice if it's made more publicly available in other form, e.g., some white-paper kind or at a popular blog site. If the adoption means polishing the document for that goal (although I don't think it's the intent for this call), I'd support it. Also, if we're really willing to work on a "standard, interoperable DNS firewall specification" without worrying about substantially changing the current practice/implementation, and if the adoption means the first step for that goal (and so the final publication could be totally different and may not be compatible with the existing standard), then I'd support it. But, again, I suspect that's not the intent of this call. Some more specific rationale for this opinion below: - As I believe most people, and perhaps including the draft authors or RPZ implementations, agree, it's an ugly hack to use the standard DNS zone to represent the firewall rules. It might have been a convenient way to implement the idea initially (e.g, we can use the zone transfer behavior to distribute the rules), but I don't see an essential reason why these are represented as DNS RRs. And, (again as I believe everyone knows) it's not just ugly but also has some inherent flaws, such as that not all domain names can be represented due to length limitation. In fact, not all existing implementations of RPZ-like feature use this form as the primary way of rule configuration (unbound is one example I happen to know of, and from a quick look knot resolver also seems to adopt its own configuration syntax). Perhaps operators of these implementations use some conversion tools form the "standard" RPZ policies to its internal form, but that's obviously inconvenient. Standardizing the spec more officially eventually leads to unified configuration (at least in concept) to eliminate the need for such a tool, but it would require changes to other existing implementations anyway. Then it would be far better to develop a better form of policy representation from the beginning. - If this is to be published as an IETF standard (even if "informational") and especially as a product of the dnsop wg, I believe it should contain more DNSSEC-related considerations. The current situation is either + validly DNSSEC-signed responses bypass RPZ policies (when 'break-dnssec' is set to no), or + 'break-dnssec' is enabled, and it would currently confuse validating stub resolvers As long as this wg hopes to see more such stub resolvers deployed (I'm assuming so), any of its protocol work should IMO help such deployment rather than hinder it. - I know the above points are about to be dismissed with "these are out of scope of this doc; it just describes what is currently deployed". And that's exactly another big concern of mine, especially because I heard the adoption of this draft would be similar to that of edns-client-subnet. At that time several wg participants including myself raised unclear or ambiguous points of the spec, some of which were based on attempts of implementing it. Sadly, though, many of them were effectively silenced with the excuse of "not in scope". Another excuse at that time was that there would be another standard truck doc to fix these issues, but, as quite predictably, people seem to have lost interest/energy once the RFC was published and there doesn't seem to be any attempt of revising the spec. I've already sensed the same thing could happen for draft-vixie-dns-rpz from the adoption discussions on this list, and I don't like to see it actually happen. To be clear, "really just describing what is currently deployed" is fine for me. But my lesson from edns-client-subnet it can't well coexist with the intent of having more interoperable implementations. If the intent is purely former, then it's better to publish it somewhere else; if our intent is to promote interoperability starting with the spec and lessons of existing deployment, we should be willing to change the current spec. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
