Re: [DNSOP] Filtering and DNSSEC

[Vladimír Čunát <[e-mail]>]

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