Hi,
I still think that a mechanism to reach an HTTPS resource is needed.
Considering the security implications of rendering directly an HTTPS URI,
It could be an additional field, to be used by the client
* For out of band connection to retrieve the needed page info from
resolvers with high reputation that have agreements with the browser
* To connect to an high reputation service (to be created) having the only
purpose to host blocking pages on behalf of the various DNS filtering services
* This high reputation service would be defined in a separated RFC
* Access criteria and content to be defined
* Management criteria to be defined
Having such a service would allow to access high reputation information about
the eventual blocking reason and provide the end user modern methods to
understand the blocking or request an amendment in case of false positives.
The mechanism proposed in draft-ietf-dnsop-structured-dns-error-07.txt is a big
improvement respect the existing situation, but still requires some knowledge
that common users may not have and so limit the capability to require
amendments only to users well educated on the topic.
With a SIP contact or an EMAIL contact the end user should know what to ask
very well, with an HTTPS URI a request to amend the blocking could be populated
with the relevant information, empowering also less experienced users (here we
are sort of providing a pre internet solution to an internet problem).
Many countries request filtering of DNS traffic for CSAM or for Adult Content
Filtering reasons, so a good way to avoid false positives would provide the
population a better access to internet.
Gianpaolo
C2 General
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
