[dns-operations] Split DNS: DNSSEC outside and not inside

[Olafur Gudmundsson]

At 10:56 02/09/2008, Edward Lewis wrote:
>At 9:02 +1000 9/2/08, Mark Andrews wrote:
>>>  On Aug 30, 2008, at 11:25 PM, Edward Lewis wrote:
>>>
>>>  >
>>>  > The one problem with DNSSEC and split-DNS that has not been solved
>>>  > is "how does one deploy DNSSEC on the outside and not on the
>>>  > inside?" (A topic for another thread.)
>>>
>>>  I've changed the thread subject, are you willing to describe this use
>>>  case in more detail?
>>>
>>>
>>>  --Olaf
>>
>>         I suspect that is more about being able to specify that
>>         a zone is *not* secure in the validators configuration
>>         regardless of whether there is a DS in the parent or not.
>
>Well, Mark listed the suggested requirement I have in mind although 
>that is just one way to do it.  I also toyed with the notion of a 
>"null key" at the apex - saying "uh, never mind."  The difference is 
>one is a "control plane/configuration file" knob and the other is in-data.
>
>The use case is this.  (Speaking in a hypothetical voice, 
>representing a previous employer's case.)  On an outside zone, I'll 
>have a few entries that are fairly static, like the public facing 
>servers of the org, the non-RFC 1918 stuff and all.  The inside zone 
>will be very dynamic, have updates from DHCP and from personal 
>computers configured to update the address data, include my RFC 1918 
>space, etc.  Because of the mayhem inside, and the different threat 
>model, I may decide (and have in the past) that is isn't worth 
>throwing in DNSSEC in to the internal mix.  As it is, the updates 
>from personal computers are not secured (because the key management 
>problem is too much for my staff to handle, slows things down, etc., 
>and a failure usually only hits the ones involved - plus mission 
>critical devices are configured in a way that is not vulnerable to a 
>"situation").

Every time I see this I ask the same question
"why is the internal naming the same as the external one when the
contents is different?"

The way I recommend people to address this is to have an internal 
naming schema
that is a delegation of the external one, e.g. inside.example.com with this
all the DNSSEC issues about unsigned internal names disappear as the delegation
to "inside" from example.com is provably insecure.
The only complication is if there is an internal presence of the 
external services
located on internal addresses. In that case the organization needs to have two
copies if their zone signed with the SAME key one for the external 
world the other
for the internal one.

         Olafur