Re: dnssec: resolver - application communication

[ted@tednet.nl (Ted Lindgreen)]

 NOTVAL <==> SERVFAIL

pro:
 some very small optimalisation in case of an error, that is
 not a validation error (see below).

contra:
 protocol change.
 implementation change of current recursive nameservers.

Question:
 Is the optimalisation worth the extra delay, that this protocol
 change will cause in finalising RFC2535bis?

For those interested in details:

- currently, i.e. without NOTVAL, the caching forwarder will
  return SERVFAIL when the recursive caching forwarder encounters
  any error decending the tree. A second query with CD=1 may, or
  may not return an answer, and in case of an answer, this answer
  is always bogus;
- with NOTVAL, one need not re-query on SERVFAIL, but everything
  else remains exactly the same.

In both cases, one needs to do recursing and validating locally
anyway to determine what or where the actual problem is.

So, the optimalisation means that when an application, that is
intentionally not interested whether the answer is bogus or not,
but is using a secure aware caching forwarder non-the-less:
 ONE query is saved on encountering a SERVFAIL, which is caused
 by something else than a validation error (i.e. all nameservers
 are lame or dead).

I think this optimalisation is rather small and only
applicable in very few situations.

-- ted