[RPZ] RPZ behavior in the presence of DNSSEC signatures and DO=1 queries

[Vernon Schryver]

> From: Bill Owens <owens at nysernet.org>

>                                                             So my
> question is, speaking purely from a technical standpoint, whether
> that's the intended behavior of RPZ, or a bug, or a not-yet-implemented
> feature, or my misconfiguration.

As I've said, it's an unavoidable implication of the nature and goals
of RPZ.  RPZ filtering is done by a party other than the owner of the
DNS data, because the bad guy owners won't fix their evil DNS data.
So RPZ rewritten DNS data simply cannot have valid DNSSEC signatures.

A DNS resolver could turn off RPZ filtering when the DNS client
asks for DNSSEC records or validation, but that would be contrary
to the interests of the end user.  If the DNS client does not want
RPZ filtering, then it should use a DNS resolver that does not do
RPZ filtering.  Using a resolver other than the DHCP default is
trivial to do and common.


> I took that a bit further and said that if RPZ breaks DNSSEC, and
> SOPA breaks DNSSEC, it is difficult to argue *on that point* that one
> is good and the other evil. I'd rather see RPZ taking the high road,
> even if that means it will have limited effectiveness.

As Emanuele Balla pointed out, that argument is a layering violation
that confounds mechanisms in layer 7 with laws in layer 9.

It implies that "blackhole" and "view" DNS server configuration
statements and firewalls are evil, because in DNS software without RPZ
support, they (or equivalents) are how an ISP would respond to a
SOPA/IP-PROTECT order.  "Blackhole," a view with a local zone file,
RPZ, and a firewall ACL on IP addresses of targeted authoritative
servers all break DNSSEC and give DNS clients RRs other than those
offered by the authoritative DNS server.

It implies that a local hosts file is evil, because a UNIX or Windows
hosts file containing foreign names has the same effect as RPZ.


Vernon Schryver    vjs at rhyolite.com