Thanks Paul. Paul Wouters <p...@nohats.ca> 于2024年1月10日周三 23:01写道：
> On Wed, 10 Jan 2024, Lanlan Pan wrote: > > > I have submitted a new draft to discuss the faked answer returned from > the recursive resolver. > > > > Your comments are appreciated. > > 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. > There should be no synthesizing of fake records as those cannot pass > DNSSEC validation. One has to assume the querier is DNSSEC enabled, > even if it is a stub. We already have extended error codes for > censorship (see > https://www.rfc-editor.org/rfc/rfc8914.html#name-iana-considerations > error codes 15-18) > The faked answer(A/CNAME RR): is at authority section now. Assume that the client is DNSSEC enable, if the target domain has deployed DNSSEC, then the client could make DNSSEC validation, and the faked answer cannot pass the validation. Format 1 could reuse the EDE error codes 15-18. > Paul > > > ---------- Forwarded message --------- > > 发件人： <internet-dra...@ietf.org> > > Date: 2024年1月10日周三 16:11 > > Subject: New Version Notification for > draft-pan-dnsop-explicit-forged-answer-signal-00.txt > > To: Lanlan Pan <abby...@gmail.com> > > > > > > A new version of Internet-Draft > > draft-pan-dnsop-explicit-forged-answer-signal-00.txt has been > successfully > > submitted by Lanlan Pan and posted to the > > IETF repository. > > > > Name: draft-pan-dnsop-explicit-forged-answer-signal > > Revision: 00 > > Title: Explicit Forged Answer Signal > > Date: 2024-01-10 > > Group: Individual Submission > > Pages: 6 > > URL: > https://www.ietf.org/archive/id/draft-pan-dnsop-explicit-forged-answer-signal-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-pan-dnsop-explicit-forged-answer-signal/ > > HTMLized: > https://datatracker.ietf.org/doc/html/draft-pan-dnsop-explicit-forged-answer-signal > > > > > > Abstract: > > > > This document describes that recursive resolver should give explict > > signal in the forged answer. > > > > Client could react more clearly based on the explict forged answer > > signal, to protect user on security and privacy. > > > > > > > > The IETF Secretariat > > > > > > > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
