[DNSOP] Re: Potentially interesting DNSSEC library CVE

[Philip Homburg <[e-mail]>]

>Are you trying to say that the behaviour of a validating stub resolver
>is not in scope of the work on DNS(SEC)?
>Because I was pretty sure it is.
>See Thomas' post before on how separating validation from result
>filtering (following the CNAME-chain) would be tricky to do outside of
>the validating stub resolver (or only with significant overhead and re-
>validation) for any implementation.

The function of a stub resolver is to send a DNS query to a recursive
resolver and receive a reply. How the request is sent and how reply is
validated is within the scope of the IETF. What happens later with the
reply is not part of the stub resolver requirements.

A DNSSEC validator is basically a function that can assign a status to
a reply message: secure, insecure, indeterminate or bogus. Based on these,
the a validating resolver can set the rcode to SERVFAIL, set or clear the AD
bit.

Filtering of DNSSEC secure replies is not tricky. It is just following
CNAMEs until either a suitable RRset is found (or collection of RRsets) or
nothing.

In any case, if you don't like the protocol between the stub resolver and
recursive resolver, the come with a concrete proposal to fix it.

The IETF does not create standards for APIs. So a validating stub resolver is
not really something that can be defined, because it is not a protocol.