Subject: Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side

From: Petr Spacek <[email-masked]>
Date: Wed, 03 Jun 2015 08:40:16 +0200

On 11.2.2015 17:08, Evan Hunt wrote:
> On Wed, Feb 11, 2015 at 03:44:31PM +0100, Pier Carlo Chiodi wrote:
>>> Wild idea: Could it be solved by adding more information to SERVFAIL 
>>> answer?
>>
>> a draft was proposed with this very topic, but it's expired now:
>>
>>   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.

Could this be added to agenda for IETF 93? Does it make sense to discuss it there?

-- 
Petr Spacek  @  Red Hat

---

From: Evan Hunt <[email-masked]>
Date: Wed, 3 Jun 2015 15:00:34 +0000

> Could this be added to agenda for IETF 93? Does it make sense to discuss

Unfortunately I won't be in Prague, but I do expect to be in Yokohama.
If you or someone else would like to push the idea forward in my absence,
that's fine.

There were a couple of review comments that I'll need to dig out and
address if the draft is coming back to life.

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

---

From: Petr Spacek <[email-masked]>
Date: Thu, 04 Jun 2015 17:13:24 +0200

> If you or someone else would like to push the idea forward in my absence,

Today I spent half a day writing diagnostics for weird corner cases so I'm
very interested in the idea :-)

Hopefully I should be in Prague - please let me know if I can do something to
push the discussion forward.

> address if the draft is coming back to life.

I'm willing to help if you need to borrow a pair of hands.

-- 
Petr Spacek  @  Red Hat

---

From: Petr Spacek <[email-masked]>
Date: Tue, 16 Jun 2015 11:10:42 +0200

Hello,

(re-sending to list)

I would like to find a solution which covers other possible failure modes than
SERVFAIL, too.

Looking at BIND 9.9, it sometimes can return NXDOMAIN or even NOERROR when
validation fails for some obscure reasons.

E.g. an attempt to invent private TLD like 'mycompany' without proper trust
anchor configuration / negative trust anchor can yield NXDOMAIN answer and one
line in log, but not a SERVFAIL.

Similarly, an attempt to 'shadow'/'hijack' an existing domain which has DS
records in the parent might result in returning NOERROR with data from the
real parent while ignoring 'spoofed' data.

I agree that this behavior makes sense from security stand point but it would
be tremendously handy to get information that something like that happened.

Maybe
https://tools.ietf.org/html/draft-hunt-dns-server-diagnostics-00#section-2.2
could be relaxed to allow the server to send ESD option even in non-SERVFAIL
responses?

Maybe there will be other use-cases for ESD option too. E.g. GSS-TSIG errors
could be accompanied with detailed error codes and/or human-readable error
messages from GSS libraries and so on. GSS-TSIG is sometimes quite hard to
debug so this extension could be a tremendous help!

(Yes, all this may require some configurable policy to specify clients who can
use ESD option.)

I will be in Prague so I'm more than happy to discuss it there if there is
enough interest.

-- 
Petr Spacek  @  Red Hat