To:
dnssec@cafax.se
From:
Jim Reid <jim@rfc1035.com>
Date:
Mon, 10 May 2004 15:05:07 +0100
In-Reply-To:
Message from Miek Gieben <miekg@atoom.net> of "Mon, 10 May 2004 15:23:57 +0200." <20040510132357.GA28493@atoom.net>
Sender:
owner-dnssec@cafax.se
Subject:
Re: dnssec: resolver - application communication
>>>>> "Miek" == Miek Gieben <miekg@atoom.net> writes:
Miek> So basically it comes down to answering the question:
Miek> Must applications know the security status of DNS answers?
Miek> (last week we thought: yes, now we (labs) think no)
I think it depends. If the application isn't DNSSEC-aware, the answer
can only be no. In that case, known bad data may well be preferable to
a SERVFAIL. This is where we are in today's unsecured DNS. If the
application is DNSSEC-aware and cares about that, the answer to your
question becomes local policy. I'm inclined towards answering yes
because if my app cares about security, the reason it's DNSSEC-aware,
it will want to know about validation failures and may try to do
something about them. Like pop up a dialogue box asking the user if
they want to continue resolving without DNSSEC because some SIGRR or
DNSKEY is broken.
I think it would be better to have a discrete error code for DNSSEC
validation failures rather than overload SERVFAIL. This would make it
easier for the application to make an intelligent decision. If my stub
resolver gets back a SERVFAIL it may have to go down a rathole of lame
delegations or forwarding loops before deciding that the response was
or wasn't a validation failure. And if there was a validation failure,
it would be nice to get some indication from the DNS where that
happened. A SERVFAIL is just too brutal. It may even hamper DNSSEC
deployment by making it harder to troubleshoot validation failures.