Vernon won't see this, since he has blocked my email, but here goes. I think it is a huge mistake to adopt this work within the IETF. Although the IEtF has, in the past, documented worst common practice, i suspect that this case is one where the WG chairs should tell the authors to take the work to an industry forum, like DNS-OARC. The authors (and others) suggest that RPZ is needed in todays hostile Internet, if only to protect oneself from abuse. This work does NOT decrease the hostility of the Internet, it raises the bar. Indeed, nearly every case of the [+1] for adoption comes with a caveat of "this is the worst thing ever."
While documenting common practice, this is clearly not "BEST COMMON PRACTICE", (or is it? :) It clearly is antithetical to ISOC's mission, "By connecting the world, working with others, and advocating for equal access to the Internet, the Internet Society strives to make the world a better place." ... No equal access here, not connecting the world, not making the DNS a better place. RPZ destroys trust in the DNS, which is DNSOPS "*Cutting off* the *nose to spite* the *face*". For those who have not heard this before, it is an expression used to describe a needlessly self-destructive over-reaction to a problem. So +1 if you feel you must. RPZ does not make for a robust, resilient, trustworthy Internet. It actively works to undermine and and fragment the Internet into insular walled gardens. I'd be happier if there was an exit strategy for RPZ, so we would know when to turn it off. /Wm On Mon, Dec 19, 2016 at 8:58 PM, william manning <chinese.apri...@gmail.com> wrote: > adding complexity in the middle of any system increases the size of an > attack surface. true for SMTP, Firewalls, and DNS. This draft formalizes > adding massive complexity throughout the DNS without a clear or crisp way > to debug and correct problems, particularly since resolution issues will > emerge that have are due to RPZ configurations multiple "hops" away from > the initial resolver and there is no business relationship in place that > would facilitate correcting errors. When it becomes easier to create and > operate "walled gardens" and have such tools encouraged and sanctioned by > the IETF and its architecture board than to work on a common, open > Internet, I would suggest that ISOC review its support of an organization > that is actively working on tools, protocols, and techniques to destroy the > basic creed of an open Internet. But hey, thats just my own opinion. > > /Wm > > https://www.linkedin.com/pulse/why-firewalls-do-work-open-expert? > > On Mon, Dec 19, 2016 at 7:35 AM, Vernon Schryver <v...@rhyolite.com> wrote: > >> ] From: Scott Schmit <i.g...@comcast.net> wrote: >> >> ] But it looks like the contents of this zone are intended to be kept >> ] secret from end-users. >> >> Depending on one's view of end users, that notion conflicts with >> the final paragraph of section 6 on page 18: >> >> If a policy rule matches and results in a modified answer, then that >> modified answer will include in its additional section the SOA RR of >> the policy zone whose rule was used to generate the modified answer. >> This SOA RR includes the name of the DNS RPZ and the serial number of >> the policy data which was connected to the DNS control plane when the >> answer was modified. >> >> ............. >> >> > From: Scott Schmit <i.g...@comcast.net> >> >> > If allowing the zone contents to be kept secret wasn't a goal of this >> > design, then it wouldn't be mentioned in the security considerations >> > twice. >> >> If that mistaken notion is matters, please point out the words in >> https://tools.ietf.org/html/draft-vixie-dns-rpz-04 that support it. >> I think trying to keep policy zone contents secret would be foolish >> and hopeless like trying to keep the contents of .com secret. >> >> Section 12.4 is intended to be about minimizing disclosure of whether >> RPZ is in use to the operators of authority servers of listed domains. >> Over the years, that goal has receded. RPZ subscribers tend to to >> care less about whether bad guys could in theory notice that they're >> being blocked than about the costs of recursing to their often slow >> or even broken servers. >> >> >> > It also wouldn't be a SHOULD that the list be access-controlled. >> >> None of the SHOULDs in section 12 mention "access control." There is >> a SHOULD for TSIG for authentication and integrity, but access control >> is neither. One might use TSIG for policy zone access control and I >> think RPZ publishers should, but that is not the intent of section 12.3. >> >> A RPZ publisher's interest in limiting timely access to paying subscribers >> differs from keeping secrets. It's like paying for access to current .com >> changes versus .com secrecy. Common DNS access controls including >> "allow-transfer" and "allow-recursion" are also not about keeping secrets. >> >> > Sure, an admin isn't required to keep it secret, but it's absolutely >> > built into the design. >> >> If it matters, please point out the words in the draft that prompt >> that mistaken notion. >> >> >> Vernon Schryver v...@rhyolite.com >> >> _______________________________________________ >> 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
