Hello, authentication of blocking decisions is an interesting idea to consider, though it's probably beyond the scope of this RFC draft. Most interesting cases can be already covered by securing the channels between the first resolver that does blocking and the final stub.
On 9/4/19 2:31 PM, Vittorio Bertola wrote: > There was also some discussion on whether these error codes could be > accompanied by a URL that the client device can use to display a > human-readable explanation to the user, which would be a cleaner solution > than the current practice of giving to the client a positive response, but > with the IP address of a local web server instead of the original one (a > practice that doesn't work well with HTTPS anyway). In Knot Resolver we've developed a habit of using additional TXT records (independently of EDNS), e.g. ; <<>> DiG 9.10.3-P4 <<>> -x 10.1.2.3 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16584 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;3.2.1.10.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 3.2.1.10.in-addr.arpa. 10800 IN SOA 3.2.1.10.in-addr.arpa. nobody.invalid. 1 3600 1200 604800 10800 ;; ADDITIONAL SECTION: explanation.invalid. 10800 IN TXT "Blocking is mandated by standards, see references on https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml";
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
