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
