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

[Petr Spacek <[e-mail]>]

On 26.6.2015 22:45, Olafur Gudmundsson wrote:
>> On Feb 11, 2015, at 11:24 AM, Petr Spacek <[e-mail]> wrote:
>> 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.” 

Unfortunately this approach ignores existence of old or broken resolvers, e.g.
in hotel networks where user has no control over the network. Think about
roaming users.

The community around Fedora distribution is right now trying to get caching &
validating resolver to every installation by default and this is not going to
happen if we cannot workaround broken networks reliably. It does not seem like
a good idea to either to show pop-up 'This network seems broken, do you want
to turn off validation?' or to simply ignore existence of DNS names which are
resolvable only locally.

Both approaches will upset users and the only result will more pushback
against DNSSEC validation on end-systems and exclamations like 'World is not
ready for DNSSEC!'

SPLIT-DNS is not going away and it would be shame if it would stop DNSSEC from
being used to its full potential.

What other options do we have to workaround this?

Petr Spacek  @  Red Hat

>> 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.