Re: [DNSOP] draft-ietf-dnsop-dnssec-roadblock-avoidance & support for local DNS views

[Olafur Gudmundsson <[e-mail]>]

Petr, sorry for delayed response, 

> On Feb 11, 2015, at 11:24 AM, Petr Spacek <[e-mail]> wrote:
> 
> 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.
> 
You are correct we ignore split-DNS completely and that is on purpose.  It is unfortunately badly/not defined. 
But in your case there is in many cases simple solution “when running SPLIT-DNS make sure internal DNSSEC resolvers are DNSSEC capable and sign inside and outside if there is overlap in names.” 


> 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 …)

This is side effect of the badly specified nature of SPLIT-DNS, 

> 
> 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
> 
> 
I reject the below text as I do not want any IPR on anything in this informational document. 

Olafur

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop