RFE: Retry fetching of trust anchor for DNSSEC validation

[jonathanunderwood]

Currently stubby tries to retrieve a trust anchor on startup. If that fails, stubby gives up on DNSSEC validation. This can be problematic if stubby is started before the wan connection is fully up. In OpenWRT we work around this by using triggers. But it would b better if stubby would try to retrieve the trust anchor ahead of subsequent lookups, otherwise stubby will be silently not validating, and the user could be misled as to the validity of the returned records.

This was discussed here, and @saradickinson recommended raising an issue here for the attention of @wtoorop .

[wtoorop]

Acknowledged.

Failure of fetching the trust anchor results in context->trust_anchors_source to get value GETDNS_TASRC_FAILED (on lines 925 and 1589 of anchor.c).

This will prevent fetching, because context->trust_anchors_source needs to be GETDNS_TASRC_NONE (or GETDNS_TASRC_XML_UPDATE) before a fetching will start (see from line 594 in general.c).

One way around this might be to register the time when context->trust_anchors_source is set to GETDNS_TASRC_FAILED (in anchor.c) and then in general.c start fetching anyway when the failure was more than a configurable back off period.

[jonathanunderwood]

I'm sure this thinking is faulty, but I'll ask anyway: If I've configured stubby to require dnssec validation, wouldn't I expect to get SERVFAIL until the trust anchor is in place? IOW, to me, it seems surprising to ever get non-validated responses from stubby if I've configured stubby to validate. What am I missing?

[saradickinson]

The DNSSEC configuration is quite subtle and I can see why this leads to confusion fo users. None of the current settings do what you want (hard fail if I DNSSEC is configured but stubby can't fetch the trust anchor - I've talked to @wtoorop and agreed we need a new option for this and much better logging of the failure mode).

Have a read of this section of the API:
https://getdnsapi.net/documentation/spec/#31-extensions-for-dnssec

Stubby only SERVFAILS if the answer is BOGUS, without a trust anchor I believe everything comes back INDETERMINATE....

[wtoorop]

It's in 1.5.0

[jonathanunderwood]

As far as I can see, the backoff time isn't exposed via the Stubby configuration, is it?

[wtoorop]

It should be, because stubby uses the getdns_context_config() function under the hood.

[wtoorop]

Just tested it and it works. I updated the example configuration file with an example: getdnsapi/stubby@006e43fd .

[jonathanunderwood]

Great, thanks. I guess the same thing applies to the new TLS options as well?

[wtoorop]

Yes, I'll add those to the example config file as well (as you requested in getdnsapi/stubby#148 )