[getdns-users] getdns_validate_dnssec() Example?

[Hollenbeck, Scott]

> -----Original Message-----
> From: Users [mailto:users-bounces at getdnsapi.net] On Behalf Of Willem
> Toorop
> Sent: Wednesday, May 06, 2015 8:15 AM
> To: users at getdnsapi.net
> Subject: Re: [getdns-users] getdns_validate_dnssec() Example?
> 
> Scott,
> 
> why is this data of type string?  Shouldn't those be array's in php?
> But the actual content of those strings are indeed the lists (array's)
> that should be used as parameters with getdns_validate_dnssec yes.

They're strings because they are the output of the "pretty print" functions.

> The bug is in getdns_validate_dnssec itself.  Currently it cannot
> handle
> compressed dname's.  NS records do have compressed dname's and the
> records you try to validate in this case actually do contain compressed
> dname's too.
> 
> Look for example to the rdata_raw in the first RR-dict in the answer:
> 
>   {
>     "class": GETDNS_RRCLASS_IN,
>     "name": <bindata of "getdnsapi.net.">,
>     "rdata":
>     {
>       "nsdname": <bindata of "getdnsapi.net.">,
>       "rdata_raw": <bindata of 0xc00c>
>     },
>     "ttl": 450,
>     "type": GETDNS_RRTYPE_NS
>   },
> 
> It has the compression pointer bits set (first byte, 0xC0 has bits 8
> and
> 7 set) and points to 0x000C, so position 12 which is directly after the
> 12 bytes DNS header, so it points to the query name.
> 
> The presence of this RR-dict alone is enough trigger the
> getdns_validate_dnssec bug.
> 
> Although not displayed, the third RR-dict in the answer must have a
> compression pointer too for ".nl", because the rdata_raw attribute is
> not expanded to a dname rendering.
> 
> As I said, fixing this bug is on top of my TODO list, because native
> stub DNSSEC validation (without relying on libunbound to perform the
> DNSSEC queries) is dependent on it.
> 
> Besides this fixable bug, using getdns_validate_dnssec also has the
> shortcoming that it cannot recognize insecure delegations, so it should
> never be used blindly to determine the DNSSEC status of answers
> received
> with the dnssec_return_validation_chain extension.
> Actual real-life DNSSEC validation needs a more intelligent approach
> than getdns_validate_dnssec can offer with the current API's prototype.

Understood, and thanks for confirming. I'm updating my documentation to note this current limitation in the library.

Scott