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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop