Extended DNS Errors proposal

[Joe Abley]

Hey Wouter!

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.


Joe