Re: dnssec: resolver - application communication

[ted@tednet.nl (Ted Lindgreen)]

>From the reactions, it appears that not everyone understood what
Miek meant with the principles like: "it's only OK, when it's OK".

Let me try to refrase the three points he was making:

In the current situation with the current (rfc2535bis) spec:

Secure-aware caching forwarders (outside the end-users control):
- CAN filter/cleanup the DNS info on the net;
- CAN prevent or at least limit the effect of spoofing;
- CAN NOT guarantee security to the end user.

Secure-aware stub resolvers (behind an unknown caching forwarder):
- CAN guarantee security to the end user when everything validates;
- CAN NOT say anything for sure when something is not found, or
  does not validate.

When the caching forwarder returns SERVFAIL, or the stub resolver
check fails, a debugging tool is needed that is able to bypass the
caching forwarder when CD=1 is insufficient to resolve the problem.

------

The question at hand is now:

 In case a secure-aware caching forwarder stumbles on bad DNS info
 (i.e. somewhere in the tree something does not validate), is it
 then OK when the caching forwarder responds with SERFVAIL, or do
 we need it respond with a special (new) code like NOTVAL?

 When does that help? We must to walk the tree anyway to locate
 the problem, whether it is caused by non-responding nameservers,
 or bad or expired signature, somewhere in the tree.

-- ted