Extended DNS Errors proposal

[Wouter Wijngaards]

Hi Nick,

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.

If you have something else, eg. DOH or TLS, then you trust that and you
imply you trust the server and then again you do not need to know the
status; you trust that connection and server to set the right value.  Or
if you really want it anyway, just run the DNSSEC validator to see if
the response is genuine according to the desired configuration you want.

If you want to debug the upstream server, unbound has options like
log-servfail: yes that prints the reason for a servfail into the logs
for inspection, also DNSSEC related reasons.

Best regards, Wouter

On 3/18/19 10:36 AM, Nick via Unbound-users wrote:
> 
> Hi,
> 
> Recently I have been looking for ways to determine/differentiate (from
> the DNS client) SERVFAIL & SERVFAIL due to DNSSEC errors.
> 
> I came across this submission to the ietf:
> 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/
> 
> The proposal utilises an EDNS0 option code to request that the DNS
> server appends an additional record to the response, conveying
> additional information. This includes the status of DNSSEC.
> 
> Would anyone happen to know if this proposal is planned to be supported
> by Unbound in the near future?
> 
> Regards
> 
> Nick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190318/8c74adca/attachment.bin>