Thanks! I think making it clear that auth servers are allowed to send TC to force TCP upgrade is a nice compromise. ________________________________ From: DNSOP <dnsop-boun...@ietf.org> on behalf of Roy Arends <r...@dnss.ec> Sent: Monday, July 10, 2023 4:04 PM To: Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> Cc: Benno Overeinder <be...@nlnetlabs.nl>; DNSOP Working Group <dnsop@ietf.org>; DNSOP Chairs <dnsop-cha...@ietf.org> Subject: Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
!-------------------------------------------------------------------| This Message Is From an External Sender |-------------------------------------------------------------------! Ben, Thanks for this! Comments inline. > On 23 Jun 2023, at 02:27, Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> > wrote: > > I want this draft to move forward, but upon review I noted with concern the > security section text: > > DNS error reporting is done without any authentication between the > reporting resolver and the authoritative server of the agent domain. > Authentication significantly increases the burden on the reporting > resolver without any benefit to the monitoring agent, authoritative > server or reporting resolver. > > Strong authentication (e.g. to a zone identity with DNSSEC) is probably > excessive, but the current draft appears to have no defense against even > trivial IP spoofing. Anyone in the world who can spoof IP addresses can > impersonate a reputable resolver and pollute the error reports sent to > authoritative servers. As an authoritative server operator, I would place a > lot more trust in reports from reputable resolvers than from unrecognized > sources. Ack > I think the draft should probably say something like: "To defend against > spoofing of source IP addresses used for error reports, reporting resolvers > MUST use DNS over TCP [RFC 7766], DNS COOKIE [RFC 7873], or another procedure > that defeats IP address spoofing." I’ve added language to this extend. However, I’ll won’t go as far as MUST. I’ve made this is a SHOULD (for both TCP and cookie), while the authoritative server SHOULD respond with TC bit set to force a re-query over TCP. Hope this suffices. Warmly, Roy > --Ben SchwartzFrom: DNSOP <dnsop-boun...@ietf.org> on behalf of Benno > Overeinder <be...@nlnetlabs.nl> > Sent: Thursday, June 8, 2023 5:59 AM > To: DNSOP Working Group <dnsop@ietf.org> > Cc: DNSOP Chairs <dnsop-cha...@ietf.org> > Subject: [DNSOP] Working Group Last call for > draft-ietf-dnsop-dns-error-reporting > !-------------------------------------------------------------------| > This Message Is From an External Sender > > |-------------------------------------------------------------------! > > Dear DNSOP WG, > > The authors and the chairs feel this document has reached the stage > where it's ready for Working Group Last Call. > > This starts a Working Group Last Call for: > draft-ietf-dnsop-dns-error-reporting. > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/ . > > The Current Intended Status of this document is: Standards Track. > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, please > speak out with your reasons. > Supporting statements that the document is ready are also welcome. > > This starts a two week Working Group Last Call process, and ends on: > June 22nd, 2023. > > Thanks, > > -- Benno > > _______________________________________________ > 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 _______________________________________________ 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
