Subject: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side

From: Petr Spacek <[email-masked]>
Date: Wed, 11 Feb 2015 15:18:36 +0100

Hello dnsop,

while implementing DNSSEC validation into Fedora/RHEL distributions we face
problems with debugging SERVFAILs seen by stub resolvers because different
causes of SERVFAILs are indistinguishable.

Even in cases where we have access to server logs (e.g. because the validating
resolver runs on the same machine as the stub resolver) we have to grep
validator logs which makes the whole system validator-dependent, which is
undesirable.

Wild idea: Could it be solved by adding more information to SERVFAIL answer?

Is there a standard which forbids adding a meta-RRs to SERVFAIL answer?

How likely will it break something? What about middleboxes?

I envision meta-RR with information like:
- signature will be valid in xxx seconds (validator's clock is in past)
- signature expired xxx seconds ago (validator's clock is in future)
- signature expected but was not received (perceived downgrade attack)
- locally generated SERVFAIL y/n
- unspecified (upstream server did not return detailed information)
- forwarder IP address/ID (when applicable)
etc.

dnssec-roadblock-avoidance draft contains interesting list of problems which
could be reported in some way.

My hope is to get enough information to distinguish cases where there is a
problem with validator (clock out of sync, wrong keys etc.) or upstream cache
used by validator (downgrade attack/missing EDNS suport) etc. to make
debugging easier.

Maybe this was discussed in the past and rejected, in that case please refer
me back to archives so I can understand the reasoning.

Thank you for your time!

-- 
Petr Spacek  @  Red Hat

---

From: Pier Carlo Chiodi <[email-masked]>
Date: Wed, 11 Feb 2015 15:44:31 +0100

Hello,

> causes of SERVFAILs are indistinguishable.
...
> Wild idea: Could it be solved by adding more information to SERVFAIL 
...
> me back to archives so I can understand the reasoning.

a draft was proposed with this very topic, but it's expired now:

   https://datatracker.ietf.org/doc/draft-hunt-dns-server-diagnostics/

Regards,

-- 
Pier Carlo Chiodi
http://pierky.com

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 11 Feb 2015 09:57:14 -0500

Hi Petr, 
This has been discussed in the past a few times and died as people could not 
agree on what the format of the record was going to be, if it was going to be useful for human or computers 
etc. 

The first idea was probably presented in 1987 by Robert Watson and myself 
https://tools.ietf.org/html/draft-watson-dns-error-00

Reading that draft over again the only thing I would change is to 
add a 16 bit field that was an index to a registry of error codes. 

I think something like this is needed and we have a much better handle of
what kind of errors we are going to see. 

	Olafur

> On Feb 11, 2015, at 9:18 AM, Petr Spacek <[email-masked]> wrote:
> 
> Hello dnsop,
>

---

From: Evan Hunt <[email-masked]>
Date: Wed, 11 Feb 2015 16:08:13 +0000

>   https://datatracker.ietf.org/doc/draft-hunt-dns-server-diagnostics/

I'd be happy to revive it, especially now that it's explicitly within
dnsop's remit.  I don't recall anyone objecting to the idea; it just
wasn't high-urgency and I had other business to attend to.

It's important that diagnostic signaling only be used for human
troubleshooting purposes and not as input to a policy decision, such
as "ignore DNSSEC failures due to expired signatures" or something,
because the diagnostic messages would be trivial to spoof.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Petr Spacek <[email-masked]>
Date: Wed, 11 Feb 2015 17:36:22 +0100

> because the diagnostic messages would be trivial to spoof.

I generally agree but the data format itself should be easy to parse: My main
goal is to make diagnostics as automatic as possible. (Yes, it will be very
interesting when we start considering active attacks.)

In other words, I do not think we can prevent people from doing crazy things
just by obscuring format of diagnostics data. I'm sure somebody will try to
parse free-form string 'signature expired 1 week ago' and do some decisions
from that :-)

-- 
Petr Spacek  @  Red Hat

---

From: Evan Hunt <[email-masked]>
Date: Wed, 11 Feb 2015 16:42:15 +0000

> parse free-form string 'signature expired 1 week ago' and do some decisions

I wasn't thinking of obscuring anything, just mentioning my one major
concern about including diagnostics with SERVFAIL responses: I fear
it will be a tempting target for someone to attempt misguided cleverness.