To:
dnssec@cafax.se
From:
Jim Reid <jim@rfc1035.com>
Date:
Tue, 11 May 2004 17:01:47 +0100
In-Reply-To:
Message from Miek Gieben <miekg@atoom.net> of "Tue, 11 May 2004 13:47:43 +0200." <20040511114743.GD18540@atoom.net>
Sender:
owner-dnssec@cafax.se
Subject:
Re: dnssec: resolver - application communication
>>>>> "Miek" == Miek Gieben <miekg@atoom.net> writes:
Miek> I think this what DNSSEC aims to do on the Net:
Miek> filter out bogus data. I also believe that SERVFAIL is
Miek> sufficient for this. I would call this "if it's bad, it's
Miek> bad".
Sorry Miek, I very strongly disagree. DNSSEC validation failures
deserve to have their own error code. Currently SERVFAIL means
something went wrong during the resolution and the DNS can't provide
any data. This is subtly but very significantly different from saying
the DNS isn't able to return data because some DNSSEC RR doesn't
validate or a signature has expired. If that happens the client might
be able to get (unsigned) data back if it wasn't DNSSEC-aware. As
compared to knowing it will be impossible to get anything back because
of a totally lame delegation or whatever.
If I was writing a DNSSEC-aware application (ha!), I'd like to be able
to tell the difference between these two things. For instance a
SERVFAIL would just mean give up: the name/qtype tuple is unresolvable
with or without DNSSEC. And a hypothetical NOTVAL response would mean
DNSSEC validation didn't work, but you might be able to get unsecured
data if you repeated the query without insisting on DNSSEC. This might
be a reasonable thing to do in some cases, like fetching something's
SSH key.
BTW, saying SERVFAIL means "it's bad data" doesn't fit with the
language in RFC2136:
SERVFAIL 2 The name server encountered an internal
failure while processing this request,
for example an operating system error
or a forwarding timeout.
The introduction of DNSSEC brings new error conditions, like provably
bad data. These should not be overloaded on existing error codes. They
should get their own. Just like when Dynamic Updates were standardised.
What's the problem with this? Why are you saying SERVFAIL is all
that's needed? Maybe we could just use that for every possible DNS
error... :-)