Re: [DNSOP] I-D Action: draft-ietf-dnsop-structured-dns-error-06.txt

> On Oct 11, 2023, at 3:17 PM, Warren Kumari <warren@kumari.net> wrote:
> 
> 
> 
> 
> 
> On Tue, Oct 10, 2023 at 12:56 PM, Vodafone Gianpaolo Angelo Scalone <Gianpaolo-Angelo.Scalone=40vodafone.com@dmarc.ietf.org <mailto:Gianpaolo-Angelo.Scalone=40vodafone.com@dmarc.ietf.org>> wrote:
>> I really love this draft and would like to see browser side implementation for the benefit of customers user experience. Today several services are implemented on top of DNS to filter malicious or unwanted traffic in an effective way, but customers cannot distinguish the blocking from a network error. This led to frustration or even worst put them in danger: a quick solution to the "network error" is to disable the protection and so be infected, or change browser. The server side implementation provides all the needed information to build a great user experience: in the example below I see at least 2 options
>> 
>> ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24987 flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 OPT PSEUDOSECTION: EDNS: version: 0, flags:; udp: 512
>> EDE: 17 (Filtered): ({ "c": [https://blocking.vodafone.com/blockpage?list=malwarecc], "s": 1,"j": "Malware C&C", "o": "Vodafone Internet Services" }) QUESTION SECTION: malw.scalone.eu <http://malw.scalone.eu/>. IN A
>> 
>> Option 1 - better user experience, some complexity to avoid security risks
>> 
>> if the contact URI is trusted it is possible to present in the GUI a real blocking page. The problem is that untrusted providers could use this method as an attack vector. Potential solutions could be:
>> Browsers accept Exte4nded DNS Errors only from DoH servers. URI domain has to be covered by DoH server certificate. There could potentially be a vetting process e.g. through IANA, whereby filtering providers would need to register. Only registered and approved providers would then be permitted to use this method
>> 
>> Option 2 - Sub-optimal user experience; however, a significant improvement over today's user experience. 
>> 
>> <Browser name> cannot open <filtered domain, not clickable> because it has been filtered by <name of the filtering service, "organization" field> Blocking reason: <blocking reason, " justification" field>
>> 
>> 
>> 
> 
> 
> Erm, can't a large amount of this already be accomplished using RFC8914 Extended Errors. E.g:
> https://www.rfc-editor.org/rfc/rfc8914.html#name-extended-dns-error-code-15-
> —-
> "4.16. Extended DNS Error Code 15 - Blocked
> The server is unable to respond to the request because the domain is on a blocklist due to an internal security policy imposed by the operator of the server resolving or forwarding the query.
> 
> 4.17. Extended DNS Error Code 16 - Censored
> The server is unable to respond to the request because the domain is on a blocklist due to an external requirement imposed by an entity other than the operator of the server resolving or forwarding the query. Note that how the imposed policy is applied is irrelevant (in-band DNS filtering, court order, etc.).
> 
> 4.18. Extended DNS Error Code 17 - Filtered
> The server is unable to respond to the request because the domain is on a blocklist as requested by the client. Functionally, this amounts to "you requested that we filter domains like this one."
> --- 
> 
> Yes, it doesn't give you the HTML page, but I personally view that as a feature, not a bug.
> You *know* that if my coffee-shop/hotel/car-dealer has the ability to respond to every N-th DNS query with:
> "({ "c": [https://subaru.example.com/buy-the-new-outback.html})" or "(({ "c": [https://www.example.com/free-donut-with-every-pumpkin-spice-latte.]})"
> they will.
> 
> Yes, I shouldn't be trusting my coffee-shop/hotel/car-dealer's resolvers, but with captive-portals and similar many people do…

Yeah, the existing error codes are quite good (and iOS and macOS natively support them now!), but having more details would allow this to replace more fully the cases where redirection occurs.

I also am concerned about someone just putting advertisements or worse in the contact information, so there should be some control on it.

Tommy

> 
> W
> 
> 
> 
>> Thank you
>> 
>> Gianpaolo
>> 
>> C2 General
>> 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnsop