Hey Wouter! On 18 Mar 2019, at 11:00, Wouter Wijngaards via Unbound-users <[email protected]> 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
