On Jan 10, 2024, at 20:55, Paul Vixie <paul=40redbarn....@dmarc.ietf.org> wrote: > > i think you mean RPZ here.
Yes I did. Thank you. Paul > > Paul Wouters wrote on 2024-01-10 07: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) >> 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) >> 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 > > > -- > P Vixie > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
