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. 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>
Thank you
Gianpaolo
C2 General
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
