[getdns-api] DANE with dnssec_return_only_secure extension

Wiley, Glen gwiley at verisign.com
Tue Jul 1 05:44:06 MST 2014

I agree that it is important to distinguish between a failure to answer and
An answer that fails to validate.   I envision an application rendering the
Results of the two answers very differently - the end user should be
By the UI that something untoward has happened if the response fails to

Glen Wiley

Sr. Engineer
The Hive, Verisign, Inc.

On 7/1/14 8:14 AM, "Willem Toorop" <willem at nlnetlabs.nl> wrote:

>Dear list,
>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!
>On bogus answers, the dnssec_return_only_secure extension makes requests
>also returns GETDNS_RESPSTATUS_NO_NAME .  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'd very much like to hear your opinions.
>-- Willem
>getdns-api mailing list
>getdns-api at vpnc.org

More information about the getdns-api mailing list