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

[Viktor Dukhovni <[e-mail]>]

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 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?

> > 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).

> > 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.

-- 
    Viktor.