Il 29 novembre 2019 01:40 Kenji Baheux <[email protected]> ha scritto:
On Thu, Nov 28, 2019 at 8:05 PM Konda, Tirumaleswar Reddy < [email protected]> wrote:
In addition, with the extended error codes defined in https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-08, client would know the reason for blocking access to a domain, solves the user experience problem and, DoT/DoH ensures the error response is not spoofed.
Spot on.
A big part of the problem is that the DNS modifications for legit use cases or legal reasons are done in a non-transparent way, with potential security/privacy side-effects (e.g. application left in the dark, forced custom page), and without strong guarantees that this was indeed the original intent. That said, I understand the need for ISP or service operators to explain what happened to the user and how to act on it (e.g. request whitelisting in a parental control situation).
So, I'd love to hear feedback from ISPs in particular, on the extended DNS error draft in conjunction with DoH.An alternative would be to use/repurpose HTTP status code such as 451 or 450 in DoH, and also define something for the explanation needs.
I was the one that asked for the addition to the draft of a specific error code for "filtered per user request", because I wholeheartedly share the view that the UX of current DNS filtering platforms, especially when applied to HTTPS destinations, is terrible and lacks the transparency, security and information necessary to reassure the user that this is indeed what was intended to happen and explain why. It would be great if we could find reliable ways to redirect the user to an explanation/configuration page without the need to circumvent or forge the HTTPS connection, while authenticating the origin of the DNS modification and of the message, and as a DNS vendor we would be happy to cooperate on that.
--
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email protected]
Office @ Via Treviso 12, 10144 Torino, Italy
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
