Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dns-error-reporting-00.txt

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Oct 2021 01:07:23 +0000

Just noting that no one has said anything about this draft since it was published almost 6 months ago, and it is the topic of next week's interim meeting. 

--Paul Hoffman, maybe making trouble for my co-worker and my boss

On Apr 27, 2021, at 7:47 AM, [email-masked] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>        Title           : DNS Error Reporting
>        Authors         : Roy Arends
>                          Matt Larson
> 	Filename        : draft-ietf-dnsop-dns-error-reporting-00.txt
> 	Pages           : 12
> 	Date            : 2021-04-27
> 
> Abstract:
>   DNS Error Reporting is a lightweight error reporting mechanism that
>   provides the operator of an authoritative server with reports on DNS
>   resource records that fail to resolve or validate, that a Domain
>   Owner or DNS Hosting organization can use to improve domain hosting.
>   The reports are based on Extended DNS Errors [RFC8914].
> 
>   When a domain name fails to resolve or validate due to a
>   misconfiguration or an attack, the operator of the authoritative
>   server may be unaware of this.  To mitigate this lack of feedback,
>   this document describes a method for a validating recursive resolver
>   to automatically signal an error to an agent specified by the
>   authoritative server.  DNS Error Reporting uses the DNS to report
>   errors.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-error-reporting-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-00

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 20 Oct 2021 03:19:44 +0200

> On Oct 20, 2021, at 3:07 AM, Paul Hoffman <[email-masked]> wrote:
> 

We like it, will implement it when it becomes a thing, and believe it should move forward.

                                -Bill

---

From: "libor.peltan" <[email-masked]>
Date: Wed, 20 Oct 2021 15:14:40 +0200

Hi all,

although for me, as an implementer of an auth server, it's not too 
important, I'd like to ask for clarification regarding the foreseen 
reporting domain(s) setup in the (usual) case of many secondary auth 
servers.

The draft says: "Each authoritative server SHOULD be configured with a 
unique reporting agent domain."

I see two possible error situations:

1) the zone itself is wrongly signed, so all secondaries share the same 
error
2) some of the secondaries respond wrongly from correctly signed zone, 
so the error is slave-specific

IMHO the case (2) is far less common. And the case (1) doesn't require 
per-secondary reporting domain, just per-zone.

Is it really recommended (in capitals) that the zone operator prepares 
extra reporting domain for each secondary around the world (it can be 
hundreds)?

If so, it can cause a disclosure about which secondary the answer is 
comming from, dunno if some zone operators are not willing to conceal this.

Thanks!

Libor

Dne 27. 04. 21 v 16:47 [email-masked] napsal(a):
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Roy Arends <[email-masked]>
Date: Wed, 20 Oct 2021 18:48:11 +0100

Hi Paul,

> On 20 Oct 2021, at 02:07, Paul Hoffman <[email-masked]> wrote:
> 

Thanks for that! The current version is a DNSOP working group adopted version of the original personal submission. The original version did have some comments, both on the list and during a DNSOP meeting.

The authors have had various discussions with developers of resolver and authoritative server software, which has brought some good insights. This will be reflected in the upcoming version of the draft, and we will highlight and discuss those during the interim meeting and subsequently on the list.

The draft strongly relies on RFC8914, and we already see adoption of this by various developers, but not yet in all implementations.

Hope this helps!

Roy

---

From: Brian Dickson <[email-masked]>
Date: Wed, 20 Oct 2021 19:37:37 -0700

FYI, I too like it and believe it should progress.
(We will likely implement it once it is published, too.)

Brian

On Tue, Oct 19, 2021 at 6:20 PM Bill Woodcock <[email-masked]> wrote:

> > Just noting that no one has said anything about this draft since it was
> published almost 6 months ago, and it is the topic of next week's interim
> meeting.
>

---

From: Roy Arends <[email-masked]>
Date: Tue, 26 Oct 2021 00:56:53 +0100

> On 20 Oct 2021, at 14:14, libor.peltan <[email-masked]> wrote:
> 
> Hi all,
> 
> although for me, as an implementer of an auth server, it's not too important, I'd like to ask for clarification regarding the foreseen reporting domain(s) setup in the (usual) case of many secondary auth servers.
> 
> The draft says: "Each authoritative server SHOULD be configured with a unique reporting agent domain."
> 
> 1) the zone itself is wrongly signed, so all secondaries share the same error
> 2) some of the secondaries respond wrongly from correctly signed zone, so the error is slave-specific
> 
> IMHO the case (2) is far less common. And the case (1) doesn't require per-secondary reporting domain, just per-zone.
> 
> Is it really recommended (in capitals) that the zone operator prepares extra reporting domain for each secondary around the world (it can be hundreds)?

The domain owner may have contracts with more than one operator. The operator may operate many authoritative servers, which not all serve the same set of zones.

If the reporting agent domain is unique, the erroneous server can be pinpointed faster. If all auth servers for a domain have the same reporting agent domain, the reporting agent knows there is an error, just doesn’t know where.

> If so, it can cause a disclosure about which secondary the answer is comming from, dunno if some zone operators are not willing to conceal this.

In that case, the zone operator doesn’t have to deploy EDE reporting, right?

Roy

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 26 Oct 2021 10:10:29 +0200

Hi,

On 26-10-2021 01:56, Roy Arends wrote:
>> reporting domain(s) setup in the (usual) case of many secondary
>> auth servers.
>> 
>> 1) the zone itself is wrongly signed, so all secondaries share the
>> same error 2) some of the secondaries respond wrongly from
>> correctly signed zone, so the error is slave-specific
>> 
>> IMHO the case (2) is far less common. And the case (1) doesn't
>> require per-secondary reporting domain, just per-zone.
>> 
>> Is it really recommended (in capitals) that the zone operator
>> prepares extra reporting domain for each secondary around the world
>> (it can be hundreds)?

If you have outsourced your secondaries to a company that has hundreds 
of secondaries I guess you can also set up a reporting agent domain like 
"company1.reporting-agent.example". and 
"company2.reporting-agent.example". It won't tell you exactly which 
server caused the problem, but at least it gives you some idea without 
having to set up hundreds of domains.

But I am also not convinced that the recommendation needs to be in capitals.

> The domain owner may have contracts with more than one operator. The
> operator may operate many authoritative servers, which not all serve
> the same set of zones.
> 
> If the reporting agent domain is unique, the erroneous server can be
> pinpointed faster. If all auth servers for a domain have the same
> reporting agent domain, the reporting agent knows there is an error,
> just doesn’t know where.
> 
>> If so, it can cause a disclosure about which secondary the answer
>> is comming from, dunno if some zone operators are not willing to
>> conceal this.
> 

The zone operator may still be interested in knowing about resolving 
issues. And DNS error reporting would still work if you have just a 
single reporting agent domain.

Matthijs

>>> A New Internet-Draft is available from the on-line
>>> Internet-Drafts directories. This draft is a work item of the
>>> Domain Name System Operations WG of the IETF.
>>> 
>>> Title           : DNS Error Reporting Authors         : Roy
>>> Arends Matt Larson Filename        :
>>> draft-ietf-dnsop-dns-error-reporting-00.txt Pages           : 12 
>>> Date            : 2021-04-27
>>> 
>>> Abstract: DNS Error Reporting is a lightweight error reporting
>>> mechanism that provides the operator of an authoritative server
>>> with reports on DNS resource records that fail to resolve or
>>> validate, that a Domain Owner or DNS Hosting organization can use
>>> to improve domain hosting. The reports are based on Extended DNS
>>> Errors [RFC8914].
>>> 
>>> server may be unaware of this.  To mitigate this lack of
>>> feedback, this document describes a method for a validating
>>> recursive resolver to automatically signal an error to an agent
>>> specified by the authoritative server.  DNS Error Reporting uses
>>> the DNS to report errors.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at
>>> tools.ietf.org.
>>> 
>>> _______________________________________________ DNSOP mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> _______________________________________________ DNSOP mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 26 Oct 2021 11:14:35 +0200

Hello.

> DNS Error reporting SHOULD be done using DNS Query Name Minimization
> [RFC7816  <https://datatracker.ietf.org/doc/html/rfc7816>] to improve privacy.

It's just a detail and "SHOULD" isn't strong, but I expect it might be 
worth elaborating here.  The name used in the reporting query adds a few 
labels to the failing QNAME and the whole reporting agent domain, so 
together that's lots of labels, and expending a packet for *each* of 
those labels would seem quite wasteful.  Perhaps we could agree on some 
boundary (e.g. around the "_er" label) under which minimization isn't 
recommended anymore, and put that as a suggestion into the text?

> The reporting resolver MUST NOT report about queries and responses
> from an encrypted channel (such as DNS over TLS [RFC7858  <https://datatracker.ietf.org/doc/html/rfc7858>] and DNS
> over HTTPS [RFC8484  <https://datatracker.ietf.org/doc/html/rfc8484>]).

I believe this needs some explanation at least (in the text, ideally).  
The failing query triggering the report is towards an authoritative 
server (i.e. unencrypted), and the reporting queries do not really carry 
more information.  They may travel by a different path, but on the whole 
I can't see significant motivation for the paragraph, especially in 
"MUST NOT" form.

> This method MUST NOT
> be deployed by default on reporting resolvers and authoritative
> servers without requiring an explicit configuration element.

I'm not so sure about forbidding this on resolvers so strongly, but 
certainly OK if the WG prefers it that way.  (On auths it wouldn't make 
sense to enable by default; what agent?)  If the error-reporting is 
meant really seriously, I'd rather improve the mechanism to never induce 
significant overhead and encourage enabling it by default on resolvers 
(at some point).

To make the error-reporting work, you need noticeable commitment to 
deploy on both sides, because otherwise the perceived benefit from 
deploying might be quite low.  On resolver side, I believe that it will 
be quite rare for operators to tweak such highly technical options[*].  
So if this MUST be off by default, you at least need commitment from 
some significant operators - say, I'm not even sure if Quad9 by 
themselves would suffice to bootstrap this.

--Vladimir | knot-resolver.cz

- - -
[*] and I support that.  I'm a big proponent of defaults.  They should 
work as good as possible, and deployments should operate as close to 
defaults as possible.

---

From: Petr Špaček <[email-masked]>
Date: Tue, 26 Oct 2021 12:02:10 +0200

> recommended anymore, and put that as a suggestion into the text?

We need to consider & document interaction between Query Name 
Minimization and NXDOMAIN processing as per RFC 8020. If minimization & 
RFC 8020 are on default then it might very easily happen that most of 
_er subtrees (which are presumably empty) will be cut out by cache and 
nothing will be sent out when an error is detected.

All in all, I think the text should warn about this interaction instead 
of mandating query name minimization on/off.

> I can't see significant motivation for the paragraph, especially in 

I will use stronger language: This is under-specified to the point where 
it starts causing confusion.
* Is the paragraph considering channel from stub to resolver?
* From resolver to auth?
* Both?
* What to do with queries executed by resolver on its own (prefetch)?
* What if multiple clients are waiting for the same query, using 
different channels? (query deduplication in the resolver)
etc.

I think this should go to Security Considerations section and be left 
for implementations to decide. MUST mandate is way too strong and does 
not accommodate implementation- and deployment- specific circumstances.

> themselves would suffice to bootstrap this.

I agree. Mandating "disabled by default" configuration on _resolvers_ 
sounds like a way to get to a working-but-never-deployed protocol.

-- 
Petr Špaček  @  ISC

---

From: Roy Arends <[email-masked]>
Date: Tue, 26 Oct 2021 11:10:14 +0100

> On 26 Oct 2021, at 10:14, Vladimír Čunát <[email-masked]> wrote:
> 
> Hello.
> 
> 
> It's just a detail and "SHOULD" isn't strong, but I expect it might be worth elaborating here.  The name used in the reporting query adds a few labels to the failing QNAME and the whole reporting agent domain, so together that's lots of labels, and expending a packet for *each* of those labels would seem quite wasteful.  Perhaps we could agree on some boundary (e.g. around the "_er" label) under which minimization isn't recommended anymore, and put that as a suggestion into the text?
> 
> 

I have a slide ready to discuss the issue that DNS Query Name Minimization brings… A minimised query can’t be distinguished from a full query, so it may not be clear what name caused an issue. The current thinking (but will be discussed later today) is to start with _er as well. That way, the erroneous qname is “encapsulated” by _er labels.
> I believe this needs some explanation at least (in the text, ideally).  The failing query triggering the report is towards an authoritative server (i.e. unencrypted), and the reporting queries do not really carry more information.  They may travel by a different path, but on the whole I can't see significant motivation for the paragraph, especially in "MUST NOT" form.
> 
If, at any point, auth servers offer encrypted transport, a faulty query should not be replicated in clear text.
> I'm not so sure about forbidding this on resolvers so strongly, but certainly OK if the WG prefers it that way.  (On auths it wouldn't make sense to enable by default; what agent?)  If the error-reporting is meant really seriously, I'd rather improve the mechanism to never induce significant overhead and encourage enabling it by default on resolvers (at some point).

Ack. 
> To make the error-reporting work, you need noticeable commitment to deploy on both sides, because otherwise the perceived benefit from deploying might be quite low.  On resolver side, I believe that it will be quite rare for operators to tweak such highly technical options[*].  So if this MUST be off by default, you at least need commitment from some significant operators - say, I'm not even sure if Quad9 by themselves would suffice to bootstrap this.
> 
I'm inclined to remove that text alltogether. Resolver implementations either do this by default, or not. No need to pedantically require config first and default off. Additionally, there is an issue where resolvers need to retry without the option when auth servers can’t handle the option… I’m inclined, just like Extended DNS errors itself, to have authoritative servers just set the option, unsolicited. It hasn’t caused any issue for extended DNS errors yet… but lets have that discussion this afternoon.

Roy
> [*] and I support that.  I'm a big proponent of defaults.  They should work as good as possible, and deployments should operate as close to defaults as possible.
>

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 26 Oct 2021 12:11:54 +0200

On 26/10/2021 12.02, Petr Špaček wrote:
> Minimization and NXDOMAIN processing as per RFC 8020. If minimization 
> & RFC 8020 are on default then it might very easily happen that most 
> of _er subtrees (which are presumably empty) will be cut out by cache 
> and nothing will be sent out when an error is detected. 

I believe that's already sufficiently addressed in section 4.1. Managing 
Caching Optimizations

---

From: Roy Arends <[email-masked]>
Date: Tue, 26 Oct 2021 11:18:26 +0100

Hi Petr,

> On 26 Oct 2021, at 11:02, Petr Špaček <[email-masked]> wrote:
> 
> We need to consider & document interaction between Query Name Minimization and NXDOMAIN processing as per RFC 8020. If minimization & RFC 8020 are on default then it might very easily happen that most of _er subtrees (which are presumably empty) will be cut out by cache and nothing will be sent out when an error is detected.

Ack, lets discuss this afternoon.

> All in all, I think the text should warn about this interaction instead of mandating query name minimization on/off.

Yes, one way of dealing with it is to have the reporting agent server (where the reports go), deploy a wildcard under their reporting agent zone.

Additionally, I think we should never require additional complexity to query name minimisation. The issue caused by query name minimisation can be solved by prepending an _er label, so the erroneous qname is encapsulated by _er’s.

> I will use stronger language: This is under-specified to the point where it starts causing confusion.

I agree.

> * Is the paragraph considering channel from stub to resolver?

No.

> * From resolver to auth?

Yes. 

> * Both?

No.

> * What to do with queries executed by resolver on its own (prefetch)?

They’re not special.

> * What if multiple clients are waiting for the same query, using different channels? (query deduplication in the resolver)
> etc.

Assuming you’re referring to stubs (not sure if you do, apologies): The reporting is independent of the client. i.e. the report will not go to clients, but to authoritative servers.

> 
> I think this should go to Security Considerations section and be left for implementations to decide. MUST mandate is way too strong and does not accommodate implementation- and deployment- specific circumstances.

Ack.

> I agree. Mandating "disabled by default" configuration on _resolvers_ sounds like a way to get to a working-but-never-deployed protocol.

I agree.

Roy

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 26 Oct 2021 12:25:22 +0200

On 26/10/2021 12.10, Roy Arends wrote:
> I have a slide ready to discuss the issue that DNS Query Name 
> Minimization brings… A minimised query can’t be distinguished from a 
> full query, so it may not be clear what name caused an issue. The 
> current thinking (but will be discussed later today) is to start with 
> _er as well. That way, the erroneous qname is “encapsulated” by _er 
> labels.

I assumed you can distinguish those quite reliably thanks to QTYPE=NULL 
which I haven't heard of for minimization so far.

> If, at any point, auth servers offer encrypted transport, a faulty 
> query should not be replicated in clear text.

I certainly agree with that, but then the text should be clarified that 
the encryption refers to auth side and not client side.  As it is now, 
it refers to RFC numbers that explicitly consider client side only, so I 
assumed that's what was meant.

>> deploying might be quite low.  On resolver side, I believe that it 
>> will be quite rare for operators to tweak such highly technical 
>> options[*].  So if this MUST be off by default, you at least need 
>> commitment from some significant operators - say, I'm not even sure 
>> if Quad9 by themselves would suffice to bootstrap this.
>>
> I'm inclined to remove that text alltogether. Resolver implementations 
> either do this by default, or not. No need to pedantically require 
> config first and default off. Additionally, there is an issue where 
> resolvers need to retry without the option when auth servers can’t 
> handle the option… I’m inclined, just like Extended DNS errors itself, 
> to have authoritative servers just set the option, unsolicited. It 
> hasn’t caused any issue for extended DNS errors yet… but lets have 
> that discussion this afternoon.

I'm not sure about this reasoning, but anyway - I'd be also inclined to 
remove that paragraph, and we'll see what opinions appear during the 
call and afterwards.