Speaking as a large enterprise operator (over 100,000 employees and contractors at over 600 sites as well as a significant public Internet presence) that has DNSSEC signed all public zones, the majority of internal zones, and has DNSSEC validation enabled at all levels throughout our recursive DNS infrastructure (not just at our Internet access layer) and which also employs RPZ based protections, I don't see a lot of overlap in the threats against which each protect. The primary DNS based threats about which we are concerned when it comes to RPZ are the vectors that utilize malicious authoritative DNS zones for botnet command & control and data exfiltration. In those scenarios especially, we do not even want the query leaving the enterprise as the queries themselves are often the payload. (We are also planning to use our own RPZ zones in addition to our current subscription feeds to block malicious domains not in the feed when identified. And we are looking at mechanisms to perhaps automatically detect particular malicious query traffic patterns, especially those associated with data exfiltration.) If a malicious zone is DNSSEC signed, BOGUS validation of the RPZ responses by other internal validating recursive nameservers, stub resolvers, or applications is perfectly acceptable. Either way, the query is stopped from going out, which is a primary goal. There's nothing that stops an operator for a malicious authoritative zone from properly DNSSEC signing their authoritative zone. The traffic itself would still be malicious. RPZ is widely used because there isn't really another mechanism that effectively addresses that specific attack vector.
Virtually every protocol standardized by the IETF either has been abused by malicious actors or has the potential for abuse. Yes, if an authoritarian nation state has the ability to restrict its citizens to state operated recursive nameservers, then RPZ gives them another tool they can use to forge responses. But such nation states were forging responses long before RPZ existed. In such an environment, they have considerable ability to abuse any protocol. If the IETF has any ideas on ways to improve RPZ to better protect against those DNS attack vectors in particular while reducing the potential for abuse or if anyone has a proposal for an alternative standard, I doubt those of us in the community that actually rely on it now would object. It would be helpful if there were an agreed reference standard for interoperability, but absent anything else that addresses the need, we'll keep using the tool we have. As an operator, dnsop certainly looks like the appropriate IETF working group for this draft. I'm not sure I understand the rationale behind Informational as opposed to Proposed Standard, but if the IETF wishes to have any input on the mechanism, this would seem to be the place to discuss it. I'm in favor of adopting it as a working group draft. Scott Morizot On Wed, Dec 21, 2016 at 8:54 AM, Ted Lemon <mel...@fugue.com> wrote: > William, I think the exit strategy for RPZ is DNSSEC. We really need to > figure out how to get people to be able to reliably and safely set up > DNSSEC. Despite Olaf’s excellent documents, we don’t really have that > yet. I don’t think that operating DNSSEC should be as scary as it is, but > right now all the IETF advice on this topic is too general, requiring the > installer to make decisions about their setup that the average IT person > doesn’t know how to make. > > We should have a document that says "look, if you don’t know any better, > here is a way to set up DNSSEC that will make your users more secure than > they are without it, and that will not blow up in your face (assuming you > do it)." I’ve seen a few documents like that, but nothing out of the > IETF; they are generally on someone’s personal web site, and don’t see wide > distribution. > > I think we need to stop thinking that there will be some shining day when > the Internet is a safe place. The internet is an ecosystem, and ecosystems > have predators and parasites. We may not like it, it may violate our > ideals, but it is reality, and denying reality doesn’t make it go away. > What we should be doing is thinking like gardeners, not like machinists. > Gardeners sometimes have to use methods for dealing with pests that allow > us to have yummy food but aren’t so good for the pests. The same is true > with the Internet. > > (FWIW, I’m in favor of adoption, for precisely this reason.) > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
