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+i...@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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
