[getdns-api] DANE with dnssec_return_only_secure extension

[Wiley, Glen]

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
advised
By the UI that something untoward has happened if the response fails to
Validate.

-- 
Glen Wiley
KK4SFV

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
>GETDNS_RESPSTATUS_NO_SECURE_ANSWERS.  DANE records MUST and ordinary
>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
>case of GETDNS_RESPSTATUS_NO_NAME .
>
>What about another return status: "GETDNS_RESPSTATUS_ALL_BOGUS_ANSWERS"?
>
>I'd very much like to hear your opinions.
>
>Cheers,
>
>-- Willem
>_______________________________________________
>getdns-api mailing list
>getdns-api at vpnc.org