] 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