<div dir="ltr">On Tue, Jul 1, 2014 at 10:14 AM, Willem Toorop <span dir="ltr"><<a href="mailto:willem@nlnetlabs.nl" target="_blank">willem@nlnetlabs.nl</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">op 01-07-14 15:34, Paul Hoffman schreef:<br>
<div class="">> 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.<br>

><br>
> An application that sees a good reply that is empty knows that it should proceed with normal PKIX validation.<br>
<br>
</div>According to RFC6698 applications should *NOT* proceed normal PKIX<br>
validation on BOGUS answers.  That is why I am raising this issue in the<br>
first place!<br>
<br>
I quote second point of section 4.1:<br>
<br>
   o  If the DNSSEC validation state on the response to the request for<br>
      the TLSA RRSet is bogus, this MUST cause TLS not to be started or,<br>
      if the TLS negotiation is already in progress, MUST cause the<br>
      connection to be aborted.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Right. <br><br></div><div>Can't we use the "dnssec_status" component of the response dictionary (set if the "dnssec_return_status" extension is specified) to examine this? I assume it will have GETDNS_DNSSEC_BOGUS in this case.<br>
<br></div><div>--Shumon.<br></div><div><br></div></div></div></div>