Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting

[Ben Schwartz <[e-mail]>]

Thanks!  I think making it clear that auth servers are allowed to send TC to force TCP upgrade is a nice compromise.
________________________________
From: DNSOP <[e-mail]> on behalf of Roy Arends <[e-mail]>
Sent: Monday, July 10, 2023 4:04 PM
To: Ben Schwartz <bemasc=[e-mail]>
Cc: Benno Overeinder <[e-mail]>; DNSOP Working Group <[e-mail]>; DNSOP Chairs <[e-mail]>
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=[e-mail]> 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 <[e-mail]> on behalf of Benno Overeinder <[e-mail]>
> Sent: Thursday, June 8, 2023 5:59 AM
> To: DNSOP Working Group <[e-mail]>
> Cc: DNSOP Chairs <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop


_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop