[getdns-api] DANE with dnssec_return_only_secure extension

Paul Hoffman paul.hoffman at vpnc.org
Tue Jul 1 06:34:50 MST 2014

On Jul 1, 2014, at 5:14 AM, Willem Toorop <Willem at NLnetLabs.nl> wrote:

> Could you advice me on this...
> The dnssec_return_only_secure extension seems on first sight an ideal
> fit for looking up DANE records.
> DANE records (like TLSA) MUST be used when they can be retrieved
> securely.  The dnssec_return_only_secure will return with status
> GETDNS_RESPSTATUS_GOOD and the answers MUST be use to validate a secure
> session.  Good!
> On insecure answers (either existing or non-existing), the
> dnssec_return_only_secure extension makes requests return
> PKIX should proceed.  Also good!
> On non-existing secure answers, the dnssec_return_only_secure extension
> makes requests return GETDNS_RESPSTATUS_NO_NAME.  We should proceed with
> normal PKIX now too.  Fine!

Agree up to here.

> On bogus answers, the dnssec_return_only_secure extension makes requests
> also returns GETDNS_RESPSTATUS_NO_NAME .  

I think that is an error in the implementation. The text from the spec says:


At least one response was returned


Queries for the name yielded all negative responses


All queries for the name timed out


The context setting for getting only secure responses was specified, and at least one DNS response was received, but no DNS response was determined to be secure through DNSSEC.

The API got a positive response: it simply didn't pass validation. So, for bogus answers, dnssec_return_only_secure that gets at least one answer back should return GETDNS_RESPSTATUS_GOOD, even if they are all bogus. In the case that any of the answers are bogus, the replies_tree and replies_full are not filled in. Thus, if they are all bogus, both of those dicts are empty.

An application that sees a good reply that is empty knows that it should proceed with normal PKIX validation.

> This is inconvenient, because
> in this case we should not proceed with PKIX, but no secure session
> should be set up at all!  Not good.
> In that last case we must also enable the dnssec_return_validation_chain
> extension to be able to peek at the packets to see if none was bogus in
> What about another return status: "GETDNS_RESPSTATUS_ALL_BOGUS_ANSWERS"?

I don't think we should be adding DNSSEC-specific responses to the list above. That list pertains to the number of answers received, not the number that later processing (in this case, with DNSSEC) could use.

--Paul Hoffman

More information about the getdns-api mailing list