On Fri, Jul 9, 2021 at 7:43 AM Dan Wing <[email protected]> wrote: > We just published Structured Data for DNS Access Denied Error Page which > defines computer-parsable error information for DNS filtering: > > DNS clients using services which perform filtering may wish to > receive more information about such filtering and the reason for that > filtering. To this end, Extended DNS Error Codes [RFC8914] provide > information about when different types of filtering have occurred, > and DNS Access Denied Error Page [I-D.reddy-dnsop-error-page] > provides a URI to give further information to the end-user about the > reasons for the filtering. However, the latter draft assumes a > client with a user-interface that can display a web page to the end- > user, whereas many clients may in fact be "headless", i.e., acting on > behalf of other network elements; such clients can include DNS > forwarders and proxies. Such clients cannot make use of a web-page > designed for presentation to an end-user, but may instead be able to > make use of structured data. This draft provides a mechanism for > such clients to request and receive structured data from the URI > returned by the DNS Access Denied Error Page mechanism. >
Thanks for posting this, Dan. Just as a matter of UX, this seems more likely to be usable than a web page because the client will want to ensure that the user is not confused into thinking that the error page contents are where they wanted to go. Structured data like this allows the client to provide the error in its own UI. -Ekr > When a third party provides DNS filtering, there are deployments > where disclosing that third party to the host (which originated the > DNS query) is desirable but other deployments where such disclosure > is not desired. For example, the IT organization might contract > filtering to a third party but want trouble-tickets from employees to > be handled by IT, rather than having employees interact directly with > the third party. As another example, all the employees at a small > business or all the members of a household might be informed of the > third party so they can troubleshoot filtering with that third party > directly. > > > Full document is at: > > https://datatracker.ietf.org/doc/html/draft-wing-dnsop-structured-dns-error-page-00.html > > -d > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
