DNSSEC and split DNS

[David Newman]

On 10/23/13 4:28 PM, Mark Andrews wrote:
> 	You sign all versions of the zone.
> 
> 	As for key management you can:
> 
> 	* use the same keys in all views which makes mobile device
> 	  management simpler as there is no need to distribute keys.
> 	  Validating from the root will work in all cases though
> 	  there is still something to be said for distributing keys
> 	  for local zones locally as this prevents resolution
> 	  failures when the site is disconnected from the rest of
> 	  the world.
> 
> 	* different keys per view.  You will need to distribute the
> 	  keys and for mobile devices they will need all sets of
> 	  keys as they see both the internal and external views
> 	  depending apon where they attach to the network and whether
> 	  there is a VPN active.  For fixed devices different keys
> 	  will cause data leakage to be rejected as the leaked data
> 	  won't validate.
> 
> 	You can change strategy if you pick the wrong one.

Thanks, makes sense.

What about delegation? Right now, there is none between external zones
and internal forward zones using RFC 1918 addresses.

I *think* option 1 would require, for example, example.org's zone to
include delegation and glue records for internal.example.org to keep the
chain of trust intact.

And I *think* option 2 in theory could be set up as an island of trust,
with no delegation from parent domains.

True?

Thanks again

dn

> 
> 	Mark
> 
> In message <526857A2.8050405 at networktest.com>, David Newman writes:
>> What is the recommended practice for adding DNSSEC to an environment
>> that currently uses split DNS?
>>
>> Apologies as I'm sure this has come up before, but most discussion I
>> found on bind-users was from 1999, and this isn't covered in the ARM.
>>
>> I did find this draft (not RFC) from 2007, but even the author
>> acknowledges that some examples given can invite misconfiguration:
>>
>> http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view-04
>>
>> On the surface, split DNS and DNSSEC have seemingly opposite goals: One
>> seeks to provide different responses to queries for the same resource,
>> and the other seeks to prevent it.
>>
>> Is there some way of reconciling these?
>>
>> Thanks
>>
>> dn
>>
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users