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

[Roy Arends <[e-mail]>]

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 <[e-mail]> 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 normal query though. All the intermediates (forwarders, caches, authoritivate servers) have no idea that this query is any different than others. There is nothing special in this query. I really want to avoid OPCODE subtyping by qtype.

> 
>>>> This document gives no guidance on the content of the TXT resource
>>>> record RDATA for this record.
>>> 
>>> The dedicated qtype should have an empty payload.
>> 
>> We can require that the returned TXT record should record have an
>> empty payload. 
> 
> I would strongly prefer a dedicated qtype (with support from Puneet
> Sood).  However, if the WG consensus is TXT, we'll grudginly cope.
> Would it make sense to raise this narrow question by the chairs as a
> consensus call?

To me, a dedicated qtype vs TXT seems like bike-shedding. 

This is not your typical “overloading an RRTYPE coz it’s difficult to allocate a new one”. 

I’m well aware that allocating a new RRTYPE is a trivial exercise (I’m one of the RFC6895 expert reviewers) as long as they don’t require any special processing. If it does require any special processing, then we’re doing it wrong IMHO.

However, we’re not overloading the TXT record IMHO. We had to pick one. One that can have an empty RDATA. One that can be cached. One that works with all well known implementations. And there is one that does the trick already: TXT.

It seems really late in the process to now be changing RRTYPE.


>>> As mentioned above, making the "info-code" more significant than the
>>> domain gets in the way here.
> 
> I did not see a response to the point about moving the info code to the
> least-significant label in the query (first or right after the leading
> "_er" if despite my exhortations that's retained).

The purpose of keeping the info code right before the separating _er label is that it helps to separate incoming reports by “severeness”, as in “lame delegation” reports go here,  “expired RRSIG” reports go there. This can all be delegated nicely by the monitoring agent.

>>> Instead, note that qname minimised queries will not have the same qtype
>>> (be it TXT or dedicated).  Instead they'll typically be "A" or "NS",
>>> and also the reporting resolve should avoid all qname minimisation
>>> below the agent domain, unasking the question.
>> 
>> Viktor, your optimisations (removing the _er labels) are premature as
>> it turns a deterministic process at the monitoring agent into a
>> heuristic process. 
> 
> I don't see how it becomes heuristic.  The dedicated qtype signals an
> complete error reporting query, other qtypes are minimised variants.

Again, there is no guarantee that a minimised variant does not use the dedicated qtype. It is simply easier to recognise a minimised variant by checking if the QNAME starts with _er. This is far more reliable than assuming a dedicated QTYPE is not minimised.

Warmly,

Roy