Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Dear WG, This ends the WGLC for draft-ietf-dnsop-dns-error-reporting. The last call has been extended a bit longer than initially planned, but valuable feedback has been received from the WG on the the draft. Thank you very much. The authors published a -05 revision a week ago that incorporates the feedback. Some issues may need to be addressed in a subsequent revision before the document is sent to the IESG. We are coordinating this further with the authors. Best regards, -- Benno On 11/07/2023 00:35, Viktor Dukhovni wrote: On Mon, Jul 10, 2023 at 10:27:45PM +0100, Roy Arends wrote: Right, but surely the monitoring agent can decide whether to solicit such a prefix label or not. That is whether an "_er" prefix label is signalled is a *local matter* betweent the authoritative server signalling the option and the monitoring agent. I agree that a monitoring agent can specify a domain that may include a separator as the least significant label. However, it also requires the monitoring agent to understand that it should sometimes include this separator, and that it may be redundant at other times. If all the monitoring agent's "customers" (authoritative servers that return its "suffix" in the new option) are informed to signal an "_er.agent.example" name, there's no "sometimes". The agent, by mutual agreement with the nameservers it supports can choose whatever suffix format meets its needs, fixed across all customers, or customer-specific. I haven't yet seen a reason to insist on a fixed suffix pattern. The resolver just stutters back the suffix it was handed by the authoritative server's extension payload. What problem does mandating the least significant label of the suffix solve, that can't be solved by just signalling the desired suffix, special label and all? It assumes that those running the authoritative server that returns the agent domain and those that run the reporting agent are in sync. Those are a lot of assumptions. If they're not in sync, surely reporting will be broken, whether or not an "_er" suffix label is used. Why should resolvers have to be responsible for this? Because this separating label is trivial to include and avoids a lot of hassle. The hassle in question remains unclear. I see two relevant/likely deployment models: * Self-hosted reporting, directly by the authoritative server: - Error reports are special by virtue of a dedicated qname suffix and perhaps qtype. - No special coördination required, the server both publishes and consumes the error reporting suffix. * Outsourced/centralised reporting, via server IPs dedicated to error report processing. - Here again no need for "_er", because all queries are presumptively error reports, and if the signal from the "customer" auth server was wrong (whether or not an "_er" label is included) the error report will not be handled correctly. - If the signal has the correct (mutually agreed) suffix, again no problem. - And of course the monitoring agent can specify the use of "_er" (or whatever) if that's convenient. What use-case actually benefits from the "_er" LSL (least-significant label) in the signal? How is this benefit not obtained by mutual agreement between the monitoring agent and its customers? The sole purpose of the leading “least-significant” “_er” is to distinguish between qname-minimized queries (for lack of a better term) and “full” queries. I understand that you argue that a monitoring agent can determine this without the _er labels (as described below), but that seem suboptimal to me. The qname minimised query (whether or not a dedicated qtype is used) will be for "A" or "NS" records, not TXT or the dedicated qtype, so there's no need for "_er" in the first label, the qtype is sufficient. RFC9156 contains no hard requirement to use A/NS. So I’m not confident that all current and future qname-minimisation implementations use A/NS. This is where this document can specify that qname minimised error reports MUST use a qtype other than the qtype for the final error report. However, to avoid forwarding junk reports to the monitoring agent, a resolver may well sensibly choose to not forward such queries, and only source them internally. I’m not following. If the qtype is "TXT", then an open resolver is easily subject to proxying forged error reports purporting errors that the resolver did not observe. Some client of the open resolver sends an explicit query for: . IN TXT ? which then looks like an error report from *that* resolver to the monitoring agent. If instead we have a dedicated qtype for error reports, it becomes a simple matter of refusing to iterate queries for . IN ? Any resolver wanting to report an error must do so directly, not via a forwarder. Especially because the
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
On Mon, Jul 10, 2023 at 10:27:45PM +0100, Roy Arends wrote: > > Right, but surely the monitoring agent can decide whether to solicit > > such a prefix label or not. That is whether an "_er" prefix label is > > signalled is a *local matter* betweent the authoritative server > > signalling the option and the monitoring agent. > > I agree that a monitoring agent can specify a domain that may include > a separator as the least significant label. However, it also requires > the monitoring agent to understand that it should sometimes include > this separator, and that it may be redundant at other times. If all the monitoring agent's "customers" (authoritative servers that return its "suffix" in the new option) are informed to signal an "_er.agent.example" name, there's no "sometimes". The agent, by mutual agreement with the nameservers it supports can choose whatever suffix format meets its needs, fixed across all customers, or customer-specific. I haven't yet seen a reason to insist on a fixed suffix pattern. The resolver just stutters back the suffix it was handed by the authoritative server's extension payload. What problem does mandating the least significant label of the suffix solve, that can't be solved by just signalling the desired suffix, special label and all? > It assumes that those running the authoritative server that returns > the agent domain and those that run the reporting agent are in sync. > Those are a lot of assumptions. If they're not in sync, surely reporting will be broken, whether or not an "_er" suffix label is used. > > Why should resolvers have to be responsible for this? > > Because this separating label is trivial to include and avoids a lot of > hassle. The hassle in question remains unclear. I see two relevant/likely deployment models: * Self-hosted reporting, directly by the authoritative server: - Error reports are special by virtue of a dedicated qname suffix and perhaps qtype. - No special coördination required, the server both publishes and consumes the error reporting suffix. * Outsourced/centralised reporting, via server IPs dedicated to error report processing. - Here again no need for "_er", because all queries are presumptively error reports, and if the signal from the "customer" auth server was wrong (whether or not an "_er" label is included) the error report will not be handled correctly. - If the signal has the correct (mutually agreed) suffix, again no problem. - And of course the monitoring agent can specify the use of "_er" (or whatever) if that's convenient. What use-case actually benefits from the "_er" LSL (least-significant label) in the signal? How is this benefit not obtained by mutual agreement between the monitoring agent and its customers? > >> The sole purpose of the leading “least-significant” “_er” is to > >> distinguish between qname-minimized queries (for lack of a better > >> term) and “full” queries. I understand that you argue that a > >> monitoring agent can determine this without the _er labels (as > >> described below), but that seem suboptimal to me. > > > > The qname minimised query (whether or not a dedicated qtype is used) > > will be for "A" or "NS" records, not TXT or the dedicated qtype, so > > there's no need for "_er" in the first label, the qtype is sufficient. > > RFC9156 contains no hard requirement to use A/NS. So I’m not confident > that all current and future qname-minimisation implementations use > A/NS. This is where this document can specify that qname minimised error reports MUST use a qtype other than the qtype for the final error report. > > However, to avoid forwarding junk reports to the monitoring agent, a > > resolver may well sensibly choose to not forward such queries, and > > only source them internally. > > I’m not following. If the qtype is "TXT", then an open resolver is easily subject to proxying forged error reports purporting errors that the resolver did not observe. Some client of the open resolver sends an explicit query for: . IN TXT ? which then looks like an error report from *that* resolver to the monitoring agent. If instead we have a dedicated qtype for error reports, it becomes a simple matter of refusing to iterate queries for . IN ? Any resolver wanting to report an error must do so directly, not via a forwarder. Especially because the forwarders won't be passing the agent extension through to their clients! > > The specification might also recommend that "stub" resolvers that > > forward most queries to a "full service" resolver, should send error > > reports *directly* to the monitoring agent. And, of course, "full > > service" resolvers MUST NOT *forward* the monitoring agent OPTION to > > clients, if they send such an option, it should be locally generated > > to signal the monitoring agent for
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Hi Viktor, Again, thank you for your detailed, in-depth and insightful response. My comments are inline, and I’ve removed the parts in agreement. > On 10 Jul 2023, at 17:58, Viktor Dukhovni wrote: > > On Wed, Jul 05, 2023 at 12:17:34PM +0100, Roy Arends wrote: > >>> The proposed qname structure is suboptimal: >>> >>> - There is insufficient justification for the "_er" labels >>> at either end of the error report qname. >>> >>> o If the monitoring agent wants to see some particular prefix, >>> (perhaps even periodically rotated to quickly drop stale >>> junk) the authoritative server can vend the prefix with the >>> agent domain. So the "most-significant" parent "_er" is >>> IMNHSO redundant. >> >> The monitoring agent has to determine where the QNAME ends, and the >> agent domain starts. If you assume that a monitoring agent only uses a >> single agent domain for all its reports, then sure, the _er_ label >> between the strings is redundant. >> >> If however, the monitoring agent has domains in use, where the least >> significant labels collide with existing top level domains, it needs >> to determine heuristically where the agent domain starts. This is IMHO >> suboptimal. > > Right, but surely the monitoring agent can decide whether to solicit > such a prefix label or not. That is whether an "_er" prefix label is > signalled is a *local matter* betweent the authoritative server > signalling the option and the monitoring agent. I agree that a monitoring agent can specify a domain that may include a separator as the least significant label. However, it also requires the monitoring agent to understand that it should sometimes include this separator, and that it may be redundant at other times. It assumes that those running the authoritative server that returns the agent domain and those that run the reporting agent are in sync. Those are a lot of assumptions. > Why should resolvers > have to be responsible for this? Because this separating label is trivial to include and avoids a lot of hassle. > If a given monitoring agent does > not need such signalling, what value does it add? It may need this signalling in the future, when it adds new costumers (new domains to monitor) to its portfolio. If there is a collision, it needs to update its entire user-base to avoid it. >>> o The leading "least-significant" "_er" is likewise (see below) >>> not adequately justified. >> >> The sole purpose of the leading “least-significant” “_er” is to >> distinguish between qname-minimized queries (for lack of a better >> term) and “full” queries. I understand that you argue that a >> monitoring agent can determine this without the _er labels (as >> described below), but that seem suboptimal to me. > > The qname minimised query (whether or not a dedicated qtype is used) > will be for "A" or "NS" records, not TXT or the dedicated qtype, so > there's no need for "_er" in the first label, the qtype is sufficient. RFC9156 contains no hard requirement to use A/NS. So I’m not confident that all current and future qname-minimisation implementations use A/NS. >>> Also, qtypes are cheap, and I rather think that a dedicated qtype (one >>> that a supporting resolver might refuse to accept in queries from >>> clients for example) makes sense here. There's no need to overload >>> TXT here. >> >> This seems counter intuitive to me. A qtype that a supporting resolver >> might refuse to accept in queries from clients is either a temporary >> state (it may be accepted in the near future when this qtype will be >> implemented), or it needs to be specified that this qtype should not >> be accepted in queries from clients, which makes this qtype not cheap >> (that is, we won’t be able to simply use the template to request one, >> as it requires additional work). > > There's no need to require that it not be accepted from clients, but > it is easier to do that with a dedicated qtype. It can be added to: > >- RRSIG (semantically vacuous sans the associated RRset) >- NSEC3 (not part of the zone's qname namespace). >- ANY (if that's what the resolver chooses to do). > > However, to avoid forwarding junk reports to the monitoring agent, a > resolver may well sensibly choose to not forward such queries, and > only source them internally. I’m not following. > The specification might also recommend that "stub" resolvers that > forward most queries to a "full service" resolver, should send error > reports *directly* to the monitoring agent. And, of course, "full > service" resolvers MUST NOT *forward* the monitoring agent OPTION to > clients, if they send such an option, it should be locally generated > to signal the monitoring agent for the resolver itself. I’m not following. > >> Allocating a new QTYPE for this purpose just seems redundant. > > It is not. This is not a normal query, it is an error report. However, it is a
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Thanks! I think making it clear that auth servers are allowed to send TC to force TCP upgrade is a nice compromise. From: DNSOP on behalf of Roy Arends Sent: Monday, July 10, 2023 4:04 PM To: Ben Schwartz Cc: Benno Overeinder ; DNSOP Working Group ; DNSOP Chairs 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 > 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 on behalf of Benno > Overeinder > Sent: Thursday, June 8, 2023 5:59 AM > To: DNSOP Working Group > Cc: DNSOP Chairs > 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
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Ben, Thanks for this! Comments inline. > On 23 Jun 2023, at 02:27, Ben Schwartz > 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 on behalf of Benno > Overeinder > Sent: Thursday, June 8, 2023 5:59 AM > To: DNSOP Working Group > Cc: DNSOP Chairs > 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
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
On Wed, Jul 05, 2023 at 12:17:34PM +0100, Roy Arends wrote: > > I would prefer to require resolvers to be more tolerant of unexpected > > options, and would have servers report the channel without explicit > > solicitation. > > That is indeed the plan. I shall make that explicit in the new text. Thanks. That will be helpful. > > What is a "recipient"? Is it a monitoring agent "zone", or a monitoring > > agent transport endpoint? If we're concerned about DoS, perhaps it > > should be the latter, since many zones can resolve to the same set of > > underlying nameservers... > > I will deal with this text in the update. Appreciated. > > Requiring cookies would be great, but they have not yet seem broad > > adoption. Can we reasonably expect the monitoring agent zones to > > support them (and ensure consistent cookie keys across the server > > pool behind each server IP)? > > > > Requiring TCP, combined with per-IP rate limits is probably simpler. > > I will include a note to implementors that reports received over TCP > will be more reliable. The rate limiting you mentioned can be managed > by resolver caching, right? Yes. > > The proposed qname structure is suboptimal: > > > >- There is insufficient justification for the "_er" labels > > at either end of the error report qname. > > > >o If the monitoring agent wants to see some particular prefix, > > (perhaps even periodically rotated to quickly drop stale > > junk) the authoritative server can vend the prefix with the > > agent domain. So the "most-significant" parent "_er" is > > IMNHSO redundant. > > The monitoring agent has to determine where the QNAME ends, and the > agent domain starts. If you assume that a monitoring agent only uses a > single agent domain for all its reports, then sure, the _er_ label > between the strings is redundant. > > If however, the monitoring agent has domains in use, where the least > significant labels collide with existing top level domains, it needs > to determine heuristically where the agent domain starts. This is IMHO > suboptimal. Right, but surely the monitoring agent can decide whether to solicit such a prefix label or not. That is whether an "_er" prefix label is signalled is a *local matter* betweent the authoritative server signalling the option and the monitoring agent. Why should resolvers have to be responsible for this? If a given monitoring agent does not need such signalling, what value does it add? > >o The leading "least-significant" "_er" is likewise (see below) > > not adequately justified. > > The sole purpose of the leading “least-significant” “_er” is to > distinguish between qname-minimized queries (for lack of a better > term) and “full” queries. I understand that you argue that a > monitoring agent can determine this without the _er labels (as > described below), but that seem suboptimal to me. The qname minimised query (whether or not a dedicated qtype is used) will be for "A" or "NS" records, not TXT or the dedicated qtype, so there's no need for "_er" in the first label, the qtype is sufficient. > > Also, qtypes are cheap, and I rather think that a dedicated qtype (one > > that a supporting resolver might refuse to accept in queries from > > clients for example) makes sense here. There's no need to overload > > TXT here. > > This seems counter intuitive to me. A qtype that a supporting resolver > might refuse to accept in queries from clients is either a temporary > state (it may be accepted in the near future when this qtype will be > implemented), or it needs to be specified that this qtype should not > be accepted in queries from clients, which makes this qtype not cheap > (that is, we won’t be able to simply use the template to request one, > as it requires additional work). There's no need to require that it not be accepted from clients, but it is easier to do that with a dedicated qtype. It can be added to: - RRSIG (semantically vacuous sans the associated RRset) - NSEC3 (not part of the zone's qname namespace). - ANY (if that's what the resolver chooses to do). However, to avoid forwarding junk reports to the monitoring agent, a resolver may well sensibly choose to not forward such queries, and only source them internally. The specification might also recommend that "stub" resolvers that forward most queries to a "full service" resolver, should send error reports *directly* to the monitoring agent. And, of course, "full service" resolvers MUST NOT *forward* the monitoring agent OPTION to clients, if they send such an option, it should be locally generated to signal the monitoring agent for the resolver itself. > Allocating a new QTYPE for this purpose just seems redundant. It is not. This is not a normal query, it is an error report. > >> This document gives no guidance on the content of the TXT resource > >> record RDATA for this record. > > > > The
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Viktor, thanks for your feedback. Comments inline. > On 26 Jun 2023, at 22:13, Viktor Dukhovni wrote: > > On Thu, Jun 08, 2023 at 11:59:59AM +0200, Benno Overeinder wrote: > >> This starts a two week Working Group Last Call process, and ends on: >> June 22nd, 2023. > > I hope my feedback is not too late. There are a few important elements > of the draft that could use some changes. > > On Tue, Jun 20, 2023 at 01:14:02PM +0200, Willem Toorop wrote: >> >> I have one nit. >> >> In the Example in section 4.2., a request still "includes an empty ENDS0 >> report channel". The third paragraph of that same section states >> something similar: "As support for DNS error reporting was indicated by >> a empty EDNS0 report channel option in the request". But Section 6.1. >> Reporting Resolver Specification states: "The EDNS0 report channel >> option MUST NOT be included in queries." > > On Tue, Jun 20, 2023 at 12:20:51PM +0100, Roy Arends wrote: >> >> Ah, yes, I will remove that sentence completely! > > So, under what conditions is the authoritative server free to include > the error reporting channel extension in its reply? > >- Does the resolver have to explicitly solicit it? No. > The reason this is important, is that there is non-negligible population > of authoritative servers that (EDNS0 requirements notwithstanding) are > not tolerant of unrecognised EDNS0 options. Correct. > Therefore, soliciting the > error reporting channel information is (at least initially, while this > is not widely supported) more likely to lead to errors than to help to > resolver errors. Indeed. > This is then not attractive to implement! > > I would prefer to require resolvers to be more tolerant of unexpected > options, and would have servers report the channel without explicit > solicitation. That is indeed the plan. I shall make that explicit in the new text. > > On Tue, Jun 20, 2023 at 11:35:28PM +0100, Dick Franks wrote: >>> An authoritative server includes the option if configured to do so >>> AND if it has the a non-null domain name configured as the reporting >>> channel. It will then reply to each query. This is IMHO better than >>> having a resolver include the option each and every time. Note that >>> resolvers will ignore options that are unknown to them. >> >> 6.2. Authoritative server specification >> Contains not a shred of normative language saying any of that. >> >> The preliminary waffle in the overview could apply to either the >> solicited or unsolicited regime. >> I withdraw my earlier statement that the document is almost ready. Now, clearly it is not. >>> >>> I hear you. I do not agree though, and I hope you reconsider >> Not without further work > > I agree this needs to be made more explicit than just deleting the > conflicting text. > > On Thu, Jun 22, 2023 at 04:10:46PM -0700, Wes Hardaker wrote: >> Roy Arends writes: >> >>> That, IMHO is already captured by the last paragraph. I did not >>> explicitly write a recipe of how to do that, and which servers could >>> be used for that :-). Could you suggest text to improve the last >>> paragraph without naming services? >> >> Erg. I hate it when I have to come up with text :-P >> >> How about replacing the last sentence of security considerations with: >> >> This method can be abused by intentionally deploying broken zones with >> agent domains that are delegated to victims. This is particularly >> effective when DNS requests that trigger error messages are sent through >> open resolvers [RFC8499] or widely distributed network monitoring >> systems that perform distributed queries from around the globe. >> Implementations SHOULD rate-limit outgoing error messages to a >> recipient to no more than 1 a minute. > > What is a "recipient"? Is it a monitoring agent "zone", or a monitoring > agent transport endpoint? If we're concerned about DoS, perhaps it > should be the latter, since many zones can resolve to the same set of > underlying nameservers... I will deal with this text in the update. > > On Fri, Jun 23, 2023 at 01:27:21AM +, Ben Schwartz 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 >>
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
On Thu, Jun 08, 2023 at 11:59:59AM +0200, Benno Overeinder wrote: > This starts a two week Working Group Last Call process, and ends on: > June 22nd, 2023. I hope my feedback is not too late. There are a few important elements of the draft that could use some changes. On Tue, Jun 20, 2023 at 01:14:02PM +0200, Willem Toorop wrote: > > I have one nit. > > In the Example in section 4.2., a request still "includes an empty ENDS0 > report channel". The third paragraph of that same section states > something similar: "As support for DNS error reporting was indicated by > a empty EDNS0 report channel option in the request". But Section 6.1. > Reporting Resolver Specification states: "The EDNS0 report channel > option MUST NOT be included in queries." On Tue, Jun 20, 2023 at 12:20:51PM +0100, Roy Arends wrote: > > Ah, yes, I will remove that sentence completely! So, under what conditions is the authoritative server free to include the error reporting channel extension in its reply? - Does the resolver have to explicitly solicit it? The reason this is important, is that there is non-negligible population of authoritative servers that (EDNS0 requirements notwithstanding) are not tolerant of unrecognised EDNS0 options. Therefore, soliciting the error reporting channel information is (at least initially, while this is not widely supported) more likely to lead to errors than to help to resolver errors. This is then not attractive to implement! I would prefer to require resolvers to be more tolerant of unexpected options, and would have servers report the channel without explicit solicitation. On Tue, Jun 20, 2023 at 11:35:28PM +0100, Dick Franks wrote: > > An authoritative server includes the option if configured to do so > > AND if it has the a non-null domain name configured as the reporting > > channel. It will then reply to each query. This is IMHO better than > > having a resolver include the option each and every time. Note that > > resolvers will ignore options that are unknown to them. > > 6.2. Authoritative server specification > Contains not a shred of normative language saying any of that. > > The preliminary waffle in the overview could apply to either the > solicited or unsolicited regime. > > > > I withdraw my earlier statement that the document is almost ready. > > > Now, clearly it is not. > > > > I hear you. I do not agree though, and I hope you reconsider > Not without further work I agree this needs to be made more explicit than just deleting the conflicting text. On Thu, Jun 22, 2023 at 04:10:46PM -0700, Wes Hardaker wrote: > Roy Arends writes: > > > That, IMHO is already captured by the last paragraph. I did not > > explicitly write a recipe of how to do that, and which servers could > > be used for that :-). Could you suggest text to improve the last > > paragraph without naming services? > > Erg. I hate it when I have to come up with text :-P > > How about replacing the last sentence of security considerations with: > > This method can be abused by intentionally deploying broken zones with > agent domains that are delegated to victims. This is particularly > effective when DNS requests that trigger error messages are sent through > open resolvers [RFC8499] or widely distributed network monitoring > systems that perform distributed queries from around the globe. > Implementations SHOULD rate-limit outgoing error messages to a > recipient to no more than 1 a minute. What is a "recipient"? Is it a monitoring agent "zone", or a monitoring agent transport endpoint? If we're concerned about DoS, perhaps it should be the latter, since many zones can resolve to the same set of underlying nameservers... On Fri, Jun 23, 2023 at 01:27:21AM +, Ben Schwartz 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. > > 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." Requiring cookies would be great, but they have
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
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. 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." --Ben Schwartz From: DNSOP on behalf of Benno Overeinder Sent: Thursday, June 8, 2023 5:59 AM To: DNSOP Working Group Cc: DNSOP Chairs 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
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
On Jun 20, 2023, at 16:40, Dick Franks wrote: > > > WGLC is supposed to be a review, nit-picking and clarification process. A “review” can have results requiring major changes. But your use here seems to imply “only small changes”. This is incorrect. Documents in WGLC could be found to have problems requiring more work in the WG to resolve. It could be abandoned or largely changed but b response to comments and issues raised. Similar actions could happen during IETF LC and IESG review. Unfortunately, these days a lot of people in various WGs see the WGLC as a deadline to _start_ reading a document for the first time. This increases the risks of WGLC documents needing more work and having issues exposed later in the process than we would like. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
> On 20 Jun 2023, at 23:35, Dick Franks wrote: > > On Tue, 20 Jun 2023 at 22:20, Roy Arends wrote: >> 8 > >> >> The change was from -03 to -04 and discussed in the WG IIRC. The specific >> sentence your refer to was a lingering oversight in the changes from -03 to >> -04. I have consulted many developers on this, and so far I had no push back. >> >>> explicitly querying the authoritative server for the appropriate >>> report channel to a dependence on authoritatives attaching an >>> (unsolicited) EDNS0 report channel option to each and every query. >> >> No. >> >> An authoritative server includes the option if configured to do so AND if it >> has the a non-null domain name configured as the reporting channel. It will >> then reply to each query. This is IMHO better than having a resolver include >> the option each and every time. Note that resolvers will ignore options that >> are unknown to them. > > 6.2. Authoritative server specification > Contains not a shred of normative language saying any of that. > > The preliminary waffle in the overview could apply to either the > solicited or unsolicited regime. > >>> I withdraw my earlier statement that the document is almost ready. >>> Now, clearly it is not. >> >> I hear you. I do not agree though, and I hope you reconsider > Not without further work Please send text. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
On Tue, 20 Jun 2023 at 22:20, Roy Arends wrote: >8 > > The change was from -03 to -04 and discussed in the WG IIRC. The specific > sentence your refer to was a lingering oversight in the changes from -03 to > -04. I have consulted many developers on this, and so far I had no push back. > > > explicitly querying the authoritative server for the appropriate > > report channel to a dependence on authoritatives attaching an > > (unsolicited) EDNS0 report channel option to each and every query. > > No. > > An authoritative server includes the option if configured to do so AND if it > has the a non-null domain name configured as the reporting channel. It will > then reply to each query. This is IMHO better than having a resolver include > the option each and every time. Note that resolvers will ignore options that > are unknown to them. 6.2. Authoritative server specification Contains not a shred of normative language saying any of that. The preliminary waffle in the overview could apply to either the solicited or unsolicited regime. > > I withdraw my earlier statement that the document is almost ready. > > Now, clearly it is not. > > I hear you. I do not agree though, and I hope you reconsider Not without further work --rwf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Correction Deleting that one sentence changes the meaning of the proposal from explicitly querying the authoritative server for the appropriate report channel to a dependence on authoritatives attaching an -(unsolicited) EDNS0 report channel option to each and every query. +(unsolicited) EDNS0 report channel option to the reply for each and every query. --Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
> On 20 Jun 2023, at 21:39, Dick Franks wrote: > > On Tue, 20 Jun 2023 at 12:21, Roy Arends wrote: >> 8 > >>> On 20 Jun 2023, at 12:14, Willem Toorop wrote: >> 8 > >>> I have one nit. >>> >>> In the Example in section 4.2., a request still "includes an empty ENDS0 >>> report channel". The third paragraph of that same section states something >>> similar: "As support for DNS error reporting was indicated by a empty EDNS0 >>> report channel option in the request". But Section 6.1. Reporting Resolver >>> Specification states: "The EDNS0 report channel option MUST NOT be included >>> in queries." >>> >>> I believe the text in the Example section is a left over from an earlier >>> version and should be corrected. >> >> Ah, yes, I will remove that sentence completely! > > WGLC is supposed to be a review, nit-picking and clarification process. That is correct. > Deleting that one sentence changes the meaning of the proposal from No! The change was from -03 to -04 and discussed in the WG IIRC. The specific sentence your refer to was a lingering oversight in the changes from -03 to -04. I have consulted many developers on this, and so far I had no push back. > explicitly querying the authoritative server for the appropriate > report channel to a dependence on authoritatives attaching an > (unsolicited) EDNS0 report channel option to each and every query. No. An authoritative server includes the option if configured to do so AND if it has the a non-null domain name configured as the reporting channel. It will then reply to each query. This is IMHO better than having a resolver include the option each and every time. Note that resolvers will ignore options that are unknown to them. > That is a fundamental change to the document, and certainly not a nit-pick. This was an older change, though. It was indeed fundamental, but there was a thought behind this. > I withdraw my earlier statement that the document is almost ready. > Now, clearly it is not. I hear you. I do not agree though, and I hope you reconsider. Roy ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
On Tue, 20 Jun 2023 at 12:21, Roy Arends wrote: >8 > > On 20 Jun 2023, at 12:14, Willem Toorop wrote: >8 > > I have one nit. > > > > In the Example in section 4.2., a request still "includes an empty ENDS0 > > report channel". The third paragraph of that same section states something > > similar: "As support for DNS error reporting was indicated by a empty EDNS0 > > report channel option in the request". But Section 6.1. Reporting Resolver > > Specification states: "The EDNS0 report channel option MUST NOT be included > > in queries." > > > > I believe the text in the Example section is a left over from an earlier > > version and should be corrected. > > Ah, yes, I will remove that sentence completely! WGLC is supposed to be a review, nit-picking and clarification process. Deleting that one sentence changes the meaning of the proposal from explicitly querying the authoritative server for the appropriate report channel to a dependence on authoritatives attaching an (unsolicited) EDNS0 report channel option to each and every query. That is a fundamental change to the document, and certainly not a nit-pick. I withdraw my earlier statement that the document is almost ready. Now, clearly it is not. --rwf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
On Tue, 20 Jun 2023 at 12:14, Willem Toorop wrote: >8 > In the Example in section 4.2., a request still "includes an empty ENDS0 > report channel". The third paragraph of that same section states > something similar: "As support for DNS error reporting was indicated by > a empty EDNS0 report channel option in the request". The only way to discover the destination for the error report is to repeat the original failed query adding the empty EDNS0 report channel option. The subsequent error report relates to the original failed query and in no way depends upon the failure or otherwise of the second attempt. > ... But Section 6.1. > Reporting Resolver Specification states: "The EDNS0 report channel > option MUST NOT be included in queries." - The EDNS0 report channel option MUST NOT be included in queries. + The EDNS0 report channel option MUST NOT be included in report queries. --rwf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Thank Dick! > On 16 Jun 2023, at 18:33, Dick Franks wrote: > > All > > I have reviewed the document which appears to be almost ready for > submission to IESG. > > > Subsection 6.1.1 uses QNAME to refer to two different entities. > The opening sentence needs to say nothing more than that the report > query is a concatenation of the listed items. > The conflicting usage is easily resolved by rewording the third item. > > 6.1.1. Constructing the Report Query > >The QNAME for the report query is constructed by concatenating the > - following elements, appending each successive element in the list to > - the right-hand side of the QNAME: > + following elements: > >* A label containing the string "_er". > >* The QTYPE that was used in the query that resulted in the extended > DNS error, presented as a decimal value, in a single DNS label. > > - * The QNAME that was used in the query that resulted in the extended > - DNS error. The QNAME may consist of multiple labels and is > - concatenated as is, i.e. in DNS wire format. > + * The list of non-null labels representing the query which is the > + subject of the DNS error report. > >* The extended DNS error, presented as a decimal value, in a single > DNS label. > Much better, will update. Thanks for the review and implementation support! Roy > > Regards > > Dick Franks > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Hoi Willem, > On 20 Jun 2023, at 12:14, Willem Toorop wrote: > > Op 08-06-2023 om 11:59 schreef Benno Overeinder: >> 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. > > Dear all, > > I find this is a very valuable addition to the DNS protocol for zone owners > and authoritative operators. It also opens up potential for valuable future > extensions, such as for example dy-run DNSSEC example ;). > > I have spend a few IETF hackathons on Proof of Concept implementations, and I > can report that it is very straight-forward to implement. The draft PR for > Unbound that emerged from those hackathons, is already almost the finished > feature: https://github.com/NLnetLabs/unbound/pull/902 (still pending the > EDNS0 opcode though!) > > I have one nit. > > In the Example in section 4.2., a request still "includes an empty ENDS0 > report channel". The third paragraph of that same section states something > similar: "As support for DNS error reporting was indicated by a empty EDNS0 > report channel option in the request". But Section 6.1. Reporting Resolver > Specification states: "The EDNS0 report channel option MUST NOT be included > in queries." > > I believe the text in the Example section is a left over from an earlier > version and should be corrected. Ah, yes, I will remove that sentence completely! Thanks for the review and the work on the implementations. Roy > > > Thanks to Roy, and all the other people who worked on this! > > -- Willem > >> >> 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
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Op 08-06-2023 om 11:59 schreef Benno Overeinder: 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. Dear all, I find this is a very valuable addition to the DNS protocol for zone owners and authoritative operators. It also opens up potential for valuable future extensions, such as for example dy-run DNSSEC example ;). I have spend a few IETF hackathons on Proof of Concept implementations, and I can report that it is very straight-forward to implement. The draft PR for Unbound that emerged from those hackathons, is already almost the finished feature: https://github.com/NLnetLabs/unbound/pull/902 (still pending the EDNS0 opcode though!) I have one nit. In the Example in section 4.2., a request still "includes an empty ENDS0 report channel". The third paragraph of that same section states something similar: "As support for DNS error reporting was indicated by a empty EDNS0 report channel option in the request". But Section 6.1. Reporting Resolver Specification states: "The EDNS0 report channel option MUST NOT be included in queries." I believe the text in the Example section is a left over from an earlier version and should be corrected. Thanks to Roy, and all the other people who worked on this! -- Willem 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
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
All I have reviewed the document which appears to be almost ready for submission to IESG. Subsection 6.1.1 uses QNAME to refer to two different entities. The opening sentence needs to say nothing more than that the report query is a concatenation of the listed items. The conflicting usage is easily resolved by rewording the third item. 6.1.1. Constructing the Report Query The QNAME for the report query is constructed by concatenating the - following elements, appending each successive element in the list to - the right-hand side of the QNAME: + following elements: * A label containing the string "_er". * The QTYPE that was used in the query that resulted in the extended DNS error, presented as a decimal value, in a single DNS label. - * The QNAME that was used in the query that resulted in the extended - DNS error. The QNAME may consist of multiple labels and is - concatenated as is, i.e. in DNS wire format. + * The list of non-null labels representing the query which is the + subject of the DNS error report. * The extended DNS error, presented as a decimal value, in a single DNS label. Regards Dick Franks ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
All, The DNSOP WG chairs would like to see more feedback from the working group. We understand that there have been thorough reviews of previous drafts and implementation feedback has been provided to the authors, but even if there are no comments, we still appreciate supporting statements that the document is ready for submission to IESG for publication. Thanks! -- Benno On 08/06/2023 11:59, Benno Overeinder wrote: 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
Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
Thanks Benno! I have received a fix from Dick Franks. I forgot to update this field from: Value Name Status Reference - --- TBD Agent-Domain Standard [this document] To: Value Description Status Reference - --- TBD Report Channel Standard [this document] That is, the value does not have a name, but does have a description. For consistency with the rest of the document, the description should be “Report Channel” instead of “Agent Domain”). I have also received a report from DNSDIR review about a broken link in the references. I will update that too. Warmly, Roy > On 8 Jun 2023, at 10:59, Benno Overeinder wrote: > > 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] Working Group Last call for draft-ietf-dnsop-dns-error-reporting
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
