<div dir="ltr">On Tue, Jul 1, 2014 at 10:33 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">op 01-07-14 16:24, Shumon Huque schreef:<br>
<div class="">> Right.<br>
><br>
> Can't we use the "dnssec_status" component of the response dictionary<br>
> (set if the "dnssec_return_status" extension is specified) to examine<br>
> this? I assume it will have GETDNS_DNSSEC_BOGUS in this case.<br>
<br>
</div>It doesn't have that because the dnssec_return_status does validation<br>
and will not include BOGUS answers.  You have to also enable<br>
dnssec_return_validation_chain to include BOGUS packets too.<br></blockquote><div><br></div><div>Ah, got it. I agree that we probably don't want application developers to trudge through the validation chain to get this indication, so I think a simpler way is needed to distinguish the bogus answer case. Your suggestion of a GETDNS_RESPSTATUS_BOGUS sounds reasonable to me. This seems easier than inferring it from (Paul's suggestion of) a combination of a positive status code and an empty response dict component. As for the RESPSTATUS list not containing DNSSEC specific responses, it already has one right? (GETDNS_RESPSTATUS_NO_SECURE_ANSWERS)<br>
<br></div><div>--Shumon.<br></div><div><br></div></div><br></div></div>