Hi, Thanks for all the responses. I guess I should have clarified my use-case:
I am running unbound locally (localhost), and use it as a front-end to the internets public DNS servers. For some client requests we would like to insist on DNSSEC, and others I would like to understand if DNSSEC failed, but still retain the option to get a result from the DNS lookup. Right now, when receiving a SERVFAIL, I am forced to perform a second query to unbound with the CD flag set (disabling DNSSEC for the query). There are some issues with this approach 1) The original SERVFAIL may have been legitimate, the second query may not fail, but we now have unsigned results 2) The original SERVFAIL may have been a legitimate DNSSEC issue, but we cant tell 3) Increased latency on all SERVFAILs because of the second call So, I am looking for a solution that can convey the DNSSEC status as part of the DNS response... Cheers Nick March 18, 2019 11:44 AM, "Joe Abley via Unbound-users" <unbound-users@nlnetlabs.nl> wrote: > Hey Wouter! > > On 18 Mar 2019, at 11:00, Wouter Wijngaards via Unbound-users > <unbound-users@nlnetlabs.nl> wrote: > >> Avoiding the extended error topic entirely, let me respond to your >> problem. If you need to know the cryptographic DNSSEC error status on >> the client, you should run a validator on the client. This is because >> there is no security for the connection between client and server, you >> have to perform the DNSSEC validation yourself. I.e. I am trying to >> tell you to not trust unsigned error codes, run end-host DNSSEC validation. > > There *is* the possibility that someone could choose to use unbound (bound to > localhost, for > example) as a DNS validator engine that other applications running within the > same kernel namespace > will talk to. This might be a pragmatic choice if the application you are > trying to support > validation in is not open source, or otherwise difficult to modify with a > modern DNS resolver > library. > > I realise it's not unbound's prime objective to be used as a resolver > library, but dropping an > instance with a trust anchor into a container image is a nice, quick way to > get the benefits of > validation for a distributed workload without having to refactor everything. > > Joe
