Re: [DNSOP] Filtering and DNSSEC

I have repeatedly asked for RPZ draft publication so we can extend to a new version of RPZ that moves the censored dnssec answer to the additional section. This has the advantage that:

1) dnssec validation can still be done by clients that support this on the withheld answer RR
2) censorship is forced to be opt-in (the real answer can still be digged out of censored replies)
3) rogue censoring is still flagged as rogue censorship

Paul

Sent using a virtual keyboard on a phone

> On Nov 25, 2021, at 08:37, Vladimír Čunát <vladimir.cunat+ietf@nic.cz> wrote:
> 
> Hello,
> I realize this is tangential, but I believe it's important over the long term.
> 
> Any modification of DNS will break *later* DNSSEC validation.  As filtering seems almost always done by DNS modification (e.g. NXDOMAIN), and I see significant trends in doing filtering as a service, there's a problem that DNSSEC gets crippled from the filterer onwards.
> 
> I can't realistically see moving *all* filtering use cases into end clients, but I'd really hate for DNSSEC to meet the same fate and I don't think it's necessary at all.  In other words, we need a model where upstream DNS service is trusted with filtering but not with DNSSEC.  Now perhaps if validation was done directly in a browser, it might choose that only "positive" answers get validated and the rest is trusted (encrypted link etc), but generally I wouldn't do that, as it would surely create some holes in DANE or elsewhere.
> 
> What we already have is SERVFAIL.  That's what validators MUST return instead of the forged answer (since the beginning of DNSSEC).  And actually it does the filtering job, as the SERVFAILed services won't be accessible.
> 
> With EDE (RFC 8914) indicating a few kinds of filtering, servers and clients now could make some behavior better suited for these cases, around fallback to other servers, maybe caching, etc. (Say, only if it came over a trusted channel, based on local policy.)  I suspect there's currently still lots of room for improvement on implementation side here.  And orthogonally, structured-error-page or other mechanism could extend the available information in these *SERVFAIL* answers and perhaps get utilized in web browsers.
> 
> I do realize that SERVFAIL isn't ideal approach to blocking, but I can't really see anything better (or similar) that could reconcile DNSSEC with some of the common filtering use cases.
> 
> --Vladimir | knot-resolver.cz
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop