On Wed, 21 Dec 2016, Vernon Schryver wrote:
As I wrote on Monday, the final paragraph of section 6 on page 18 of
https://tools.ietf.org/html/draft-vixie-dns-rpz-04
says:
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.
It's not signed, but perhaps it could be with look-asside trust anchors,
although an ever growing forest of DLVs doesn't sound good to me.
Browsers and other interested applications would have to do more than
gethostbyname() or a modern equivalent to see those SOAs. But if
browsers ever do any DANE, they'll need to do more than gethostbyname().
(perhaps that "will include" should be "MUST include")
If the goal is to block the query, I think this is fine. I would prefer
a signed response of any kind as a marker we can keep to hold the
resolver operator accountable for their blocking actions.
If the goal is to block the answer, I think it would be much better to
move the original Answer RRTYPE into the Authority Section and use an
ENDS0 bit to signal RPZ was applied. That way, clients that understand
RPZ can see the censored results and do smart things - including ignoring
or accepting the censor - and clients that do not support understanding
RPZ will still be prevented from seeing the censored results for their
security.
Possibly an additional RRTYPE with a URL to a page explaining the
censorship would be useful to standarize as well. Having a "serial
number" of a policy is not very helpful for a user to hold an operator
responsible. It is important that we know the reason, as we've seen
many filter software doing things like filtering out the EFF or ACLU as
"porn site".
The important issue here is that DNS filtering is done for many valid
and invalid reasons. It is important that we give the consumers the
tools to see the difference. I'm fine with non-updated software/users
that cannot tell the difference to be blocked as-is for their
protection.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
