Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-02.txt

[Shumon Huque <[e-mail]>]

On Tue, Aug 16, 2022 at 7:02 PM Paul Vixie <paul=
[e-mail]> wrote:

>
> Hugo Salgado wrote on 2022-08-16 14:19:
> > Dear authors.
> > In the second paragraph of section 3 "Upgrading NS RRset Credibility"
> > there is a mention of "Positive responses...", which I am not sure of
> > its exact meaning. Do you mean ANSWERS>0? Or AA=1?


> i think if the text were "positive responses" then your question would
> be a nonsequitur, but the actual text i see is "positive answers" which
> does indeed raise your questions.
>

Thanks for the question Hugo.

To address Paul's comment first, I think it might be simplest to change
"positive answer" in the text to "positive response" to avoid potential
ambiguity (although in my view they are synonymous). Barring objections,
I'll make that update in the text.

Even the term "positive response" is not precisely defined in the specs.
DNS Terminology (RFC  8499) does define "Negative response", so we
could argue that it is simply the antonym, i.e. a NOERROR response that
isn't a NODATA (with ANCOUNT > 0, or in the case of referrals, with an
NS set in the authority section).


> > I'm thinking of a (broken) nameserver that responds to NSs queries with
> > NXDOMAIN (but does answer to other types)[1]. Is that a positive
> > response, which should be cached with an authoritative data ranking?
>

We cover this case in the 3rd paragraph of section 3 with the following:

      " ... that there are
      number of nameservers in the field that (incorrectly) fail to
      answer explicit queries for NS records, and thus the revalidation
      logic may need to be applied lazily and opportunistically to deal
      with them."

Applying the logic "opportunistically" means that the resolver falls back to
using the delegation information in the referral from the parent. We should
make that clearer in the draft.

Or we could propose to have another "flag day" to try to root out these
broken nameservers :)

i think we're sending an RD=0 question to a server we think is the
> closest enclosing delegator for the zone we are revalidating, and that
> it has to answer AA=0 (because it is a delegated name) with an RRset of
> type NS, or else it's nonresponsive. i leave it to my coauthors to find
> a way using only english words to best express that constraint.
>

Paul - the specific text from the draft that Hugo is quoting is about
upgrading
NS set credibility, and not about revalidation (which is in section 4). If
there are
other ambiguities in that section that need to be addressed, please discuss.

Shumon.