> Il 10 agosto 2019 20:57 Wes Hardaker <wjh...@hardakers.net> ha scritto:
>
> 4) Now that this has had multiple implementations (though they'll need
> to change after the packet format and code changes [that they
> requested]), this is likely ready for last call after passing through
> the document for nits and addressing any last comments raised.
Given some recent discussions on the ADD list, I think that it could make sense
to add a third error code for DNS filtering. Currently, the draft has these two:
4.16. Extended DNS Error Code 15 - Blocked
The resolver attempted to perfom a DNS query but the domain is
blacklisted due to a security policy implemented on the server being
directly talked to.
4.17. Extended DNS Error Code 16 - Censored
The resolver attempted to perfom a DNS query but the domain was
blacklisted by a security policy imposed upon the server being talked
to. Note that how the imposed policy is applied is irrelevant (in-
band DNS somehow, court order, etc).
There is however a third case, which is "blocked by user request". The three
cases differ on who made the decision to filter, i.e.:
- code 15 is for when the recursor blocks stuff that its own operator dislikes;
- code 16 is for when the recursor blocks stuff that public authorities dislike;
- the third code would be for when the recursor blocks stuff that the user (the
entity that acquired the service) dislikes, e.g. for parental control,
destinations not suitable for work, etc.
There was also some discussion on whether these error codes could be
accompanied by a URL that the client device can use to display a human-readable
explanation to the user, which would be a cleaner solution than the current
practice of giving to the client a positive response, but with the IP address
of a local web server instead of the original one (a practice that doesn't work
well with HTTPS anyway).
This has many security caveats, and could only work with an authenticated,
trusted resolver (which is anyway true of the above error codes in themselves,
since an adversarial recursor could just lie on the reason for blocking or even
on the fact that it is actually blocking something). It is really too early to
say whether this could work or whether it would actually be implemented, and
also, on transports other than DoH, I'm not sure if applications could ever
access this information. Still, perhaps a note on whether EXTRA-TEXT could bear
structured information for certain error codes, and how this mechanism could be
later defined, could be useful.
(Happy to propose text if this makes sense.)
--
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
