Extended DNS Errors proposal
jabley at hopcount.ca
Mon Mar 18 11:43:30 UTC 2019
On 18 Mar 2019, at 11:00, Wouter Wijngaards via Unbound-users <unbound-users at 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.
More information about the Unbound-users