Hello dnsop,

draft-ietf-dnsop-dnssec-roadblock-avoidance is a nice idea in general but
current version of "Roadblock Avoidance", section 5, version 01 has a
significant drawback:

       Else if the resolver is labeled "Not a DNS Resolver" or
          "Non-DNSSEC capable"

           Mark it as unusable and try next resolver

This effectively cuts off the client from local DNS view, which can
effectively mean that internal resources on the network will be unavailable.

On public networks it may be perfectly fine to sacrifice local names to get
DNSSEC validation.

However, on internal networks it is a big problem for practical usability of
the system. I personally experienced this when using dnssec-trigger on
networks where DHCP does not send complete list of local DNS domains. (Also, I
have to say that the fact that dnssec-trigger disables DNSSEC validation for
list of domains supplied DHCP effectively takes all the security away ...)

Generally my concern is about practical usability of the proposed solution:
Imagine that I'm road-warrior/consultant who is traveling all the time and is
working for different companies. When I arrive to a customer I should not need
to spend time fiddling with network configuration to get connected to local
network before I can start working on customer's problem.


Few guys in Red Hat proposed "hacky but almost-reliable automatic" way how to
improve usability without sacrificing security.


Disclaimer
==========
Method described below is covered by US patent application named "USING DOMAIN
NAME SYSTEM SECURITY EXTENSIONS IN A MIXED-MODE ENVIRONMENT".

See Red Hat, Inc. Statement of Position and Our Promise on Software Patents:
http://www.redhat.com/legal/patent_policy.html


The Hack
========
Fundamental assumption:
Internal & external DNS view are both signed with the same keys or both
unsigned. This assumption allows the method to work without explicit
configuration on every client and removes dependency on reliable/secure
network-detection logic.


The main idea can re-phrased as amendment to section 5 of the draft:

   The general fallback approach can be described by the following
   sequence:

       If the resolver is labeled as "Validator" or "DNSSEC aware"
           Send query through this resolver and perform local
           validation on the results.

           If validation fails, try the next resolver

       Else if the resolver is labeled "Not a DNS Resolver" or
          "Non-DNSSEC capable"
           Mark it as unusable and try next resolver

--- amended text begins here ---

       Else if no more resolvers are configured and if direct queries
       are supported
          1. Try iterating from Root

          2. If the answer is SECURE/BOGUS
            Return the result of iteration.

          3. If the answer is INSECURE
            Re-query "Non-DNSSEC capable" servers and get answer
            from "Non-DNSSEC capable" servers.
            Set AD bit to 0 before returning the answer to client.

       Else return a useful error code


This method covers DNS split-views with internal unsigned views pretty
nicely as long as the fundamental assumption holds. (Naturally it works only
for cases where fallback to iteration is possible.)

We wanted to write Unbound module for this but it is harder than it seems.
(Proof-of-concept with stand-alone DNS proxy works fine, we have problem with
Unbound module architecture - not with the described method.)

Feel free to incorporate the idea to the draft if you wish.

-- 
Petr Spacek  @  Red Hat