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
