Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

[Tony Finch <[e-mail]>]

John Levine <[e-mail]> wrote:
> >Should we treat synthesis as if the cache is pretending to be an
> >authoritative server?
>
>
> Yes, although it's kind of subtle.

Yep, that's kind of why I am suggesting a more detailed spec but also
trying to leave as much as possible to the existing intricate
documentation.

>  For example, I query for
> a.h.g.iana.fail:
[snip]
> You can see that the wildcard is *.h.g.iana.fail.
>
> But query for e.h.g.iana.fail:
>
> ;; ANSWER SECTION:
> e.h.g.iana.fail.        3600    IN      A       2.2.2.2
> e.h.g.iana.fail.        3600    IN      RRSIG   A 8 4 3600
>       20161211000000
> 20161010180056 31806 iana.fail.
>
> You can see that it's synthesized from a wildcard, but you can't tell
> whether the wildcard was
> *.iana.fail or *.g.iana.fail or *.h.g.iana.fail.

Ah, but that is what the label count (4) is for in the RRSIG A. The
QNAME has 5 labels so you know the RRSIG belongs to *.h.g.iana.fail, and
you have to work this out in order to validate it.

> That's OK, and I believe it is straightforward for a cache to tell
> what names it can synthesize and what names it can't, but it means
> it'd probably be a good idea to make it clear that if there are other
> names in the wildcard's range, the cache often can't synthesize
> results.

And the rules for authoritative servers say which records you have to
put in the answer, so I think it is enough for the cache to check that
it already has the right ones.

In your examples, the first NSEC covered *.h.g to b.h.g proving that
a.h.g did not exist and could be the result of wildcard expansion. In
the second query, e.h.g is outside that NSEC's range, so although the
cache knows it e.h.g is a candidate for wildcard synthesis, it
doesn't have the nonexistence proof, so it has to query upstream. And
it knows what nonexistence proof it needs from the rules for
authoritative answers.

I think something that might need saying (it probably isn't in the
existing specs) is that the validator should cache the wildcard record
that it retconned from the answer (*.h.g in this example). Or maybe it
is obvious from the fact that it is being used for synthesis :-)

Tony (sorry this is a bit vague and off the cuff).
--
f.anthony.n.finch  <[e-mail]>  http://dotat.at/  -  I xn--
  zr8h punycode