> Il 11/01/2024 03:50 CET Lanlan Pan <abby...@gmail.com> ha scritto: > > > Thanks Paul. > > Paul Wouters <p...@nohats.ca> 于2024年1月10日周三 23:01写道： > > As I've said during the discussions on RBL and an updated version for > > RBL, if these things are done "for the user", the best thing is to put > > the censored answer in the authority section. This way ignorant clients > > keep working with the censor, but knowledgable clients can DNSSEC validate > > the censorship using the original answer and optionally present a choice > > to the enduser. It also prevents censorship forced against the user's > > interest. eg it makes this properly optin (eg compliant with RFC 8890) > > The explicit faked answer signal: > - In Format 1, it follows EDE, in additional section. > - In Format 2 , it is an TXT RR, in authority section (same as faked answer). > I will revise it. > > Knowledgable client can make its own reaction, if it gets a explicit signal > that it has received a faked answer. > This can mitigate the HTTP cookies leak, especially on NXDOMAIN redirection > case.
I'm not against this, but I don't see which kind of resolver operator would want to use it. There are only two possibilities: 1. the forging is made cooperatively, to protect the user themself, so the user actually asked the resolver to block certain destinations and send back a pointer to an error page; in this case, the client has no reason to try any of the circumvention strategies you describe in section 5, and doing this could actually endanger the user; 2. the forging is made adversarially, to protect other users from whatever this particular user is trying to do with the Internet; in this case, the server has no reason to tell the client that something special is happening, as it needs to prevent the client from circumventing the block; so it will not add any signal to the answer. Even in case 2, resolvers who want to be more transparent and don't want to forge any answer could just say no + EDE 15-18, at least when that will be supported by browsers. Can you see a use case that would motivate people to implement this new mechanism? -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
