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.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
