Extended DNS Errors proposal

Unbound
1

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

2

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

3

a message of 37 lines which said:

Recently I have been looking for ways to determine/differentiate
(from the DNS client) SERVFAIL & SERVFAIL due to DNSSEC errors.

Indeed, this is a big problem, and a serious issue for the DNS in
general, and for DNSSEC specially.

Would anyone happen to know if this proposal is planned to be
supported by Unbound in the near future?

At the next IETF hackathon (in one week), there is work planned for
Knot <https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon&gt; (and
may be getdns). If someone wants to join us to work on Unbound...

4

Hey Wouter!

5

Yes.

You can distinguish between something DNSSEC and something else if you
re-query with CD=1 (e.g. `dig +cd`), but that still leaves a lot to be
desired.

Tony.

6

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

7

a message of 33 lines which said:

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.

Clearly, DNS Extended Error is exactly what you want. Your use-case is
quite common. But DNS Extended Error is not yet a RFC and not yet
implemented (see my message about the IETF hackathon).

If you control the client application, getdns <https://getdnsapi.net/&gt; may
interests you.