> On Oct 11, 2023, at 3:17 PM, Warren Kumari <[email protected]> wrote: > > > > > > On Tue, Oct 10, 2023 at 12:56 PM, Vodafone Gianpaolo Angelo Scalone > <[email protected] > <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/dnsop >> > > > _______________________________________________ > DNSOP mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
