DNSSEC and split DNS

David Newman dnewman at networktest.com
Mon Oct 28 19:27:03 UTC 2013


On 10/25/13 6:11 PM, David Newman wrote:
> 
> 
> On 10/23/13 5:20 PM, Mark Andrews wrote:
>> In message <5268626C.8040603 at networktest.com>, David Newman writes:
>>> 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.
>>
>> You can
>> * add the delegation for internal.example.org to example.org
>>   and make it visible to the world with a appropriate acl on
>>   internal.example.org.
>> * have two version of example.org, one with and one without the
>>   delegation for internal.example.org.
> 
> I went this route, and encountered three issues:

Answering two of my own questions. The final one remains unresolved.

> 
> 1. After a reload, there are out-of-zone warnings for hosts in example.org:
> 
> 25-Oct-2013 16:02:49.330 general: warning:
> dynamic/example.org/example.org.db:133: ignoring out-of-zone data
> (hostname.example.org)
> 
> Both internal and external zones are called 'example.org' but each is in
> a separate view. These warnings come from the example.org zone file, the
> one in the external view.

Root cause: An $INCLUDE statement in a zone file in the internal view
called a file with a typo in its name. That zone wasn't loading as a result.


> 2. With two zones using the same name, I'm unsure how to use rndc to
> reload just the internal or just the external version since both use the
> same name.

rndc reload zone IN view

> 
> 3. Another internal nameserver gets intermittent dig +dnssec errors on
> queries for internal resources. Sometimes after a restart, the result is
> NOERROR and other times it's NXDOMAIN or SERVFAIL.
> 
> This is seen on an internal recursive nameserver (let's call it NS2). I
> think this might be due to the presence of external servers in the
> forwarding statement. If I comment out the external forwarders and
> include only one other internal server (let's call it NS1), dig lookups
> always work, including DNSSEC.
> 
> Problem is, NS1 is currently an authoritative and recursive server, and
> I'm trying to separate these functions. Is there some other way to build
> up a cache and get DNSSEC data on NS2?

Still stuck on this one. Authoritative and recursive servers should be
separate (this is to allow trust anchors on internal zones).

If delegation only happens for a zone in the internal view, how would an
internal caching-only server build up a cache of both internal and
external responses? What should it use as forwarders?

Thanks

dn



> 
> Config details below. Thanks very much for additional troubleshooting clues.
> 
> dn
> 
> This is from named.conf:
> 
> acl internal-xfer {
> ..
> }
> 
> acl external-xfer {
> ..
> }
> 
> acl trusted {
> 	..
> }
> 
> view "internal" in {
> 
>         match-clients { trusted; };
>         recursion yes;
>         additional-from-auth yes;
>         additional-from-cache yes;
> 
> ..
> 
>        zone "example.org" in {
>                 type master;
>                 file "dynamic/split.example.org/split.example.org.db";
>                 allow-query { trusted; };
>                 allow-transfer { internal-xfer; };
>                 // internal and external zones use same key
> 		key-directory "managed-keys/example.org";
>                 inline-signing yes;
>                 auto-dnssec maintain;
>         };
> 
> 	..
> 
> };
> 
> view "external" in {
> 
> 	match-clients { any; };
>     	recursion no;
>     	additional-from-auth no;
>     	additional-from-cache no;
> 
> 	..
> 
> 	zone "example.org" in {
>                 type master;
>                 file "dynamic/example.org/example.org.db";
>                 allow-query { any; };
>                 allow-transfer { external-xfer; };
>                 // internal and external zones use same key
>                 key-directory "managed-keys/example.org";
>                 inline-signing yes;
>                 auto-dnssec maintain;
>         };
> 
> 	..
> };
> 
> 
> Here is the internal split.example.org.db zone file:
> 
> $TTL 1h
> internal.example.org. IN SOA ns.example.org. hostmaster.example.org. (
>                                 2013102500 ; serial
>                                 1h         ; refresh
>                                 15m        ; retry
>                                 28d        ; expire
>                                 1h )       ; minimum
> example.org.        IN      NS      ns.example.org.
> example.org.        IN      NS      ns2.example.org.
> example.org.        IN      MX      10 mail.example.org.
> example.org.        IN      MX      100 mail2.example.org.
> 
> example.org.       IN      A       10.0.0.10
> mail.example.org.    IN      A       10.0.0.20
> mail2.example.org.	IN	A	10.0.0.21
> ns.example.org.	IN	A	10.0.0.30
> ns2.example.org.	IN	A	10.0.0.31
> 
> ..
> 
> ; delegation, glue, and DS records for internal.example.org
> internal.example.org.	IN      NS      ns100.internal.example.org.
> internal.example.org.	IN      NS      ns101.internal.example.org.
> ns100.internal.example.org.	IN      A      10.0.0.100
> ns101.internal.example.org.	IN      A      10.0.0.101
> internal.example.org.	IN DS 48835 8 1 C142...
> internal.example.org.   IN DS 48835 8 2 DFDE...
> 
> And here is the external example.org.db zone file:
> 
> $TTL 1h
> example.org.        3600 IN SOA ns2.example.org. hostmaster.example.org (
>                                 2013102301 ; serial
>                                 3600       ; refresh (1 hour)
>                                 900        ; retry (15 minutes)
>                                 2419200    ; expire (4 weeks)
>                                 3600       ; minimum (1 hour)
>                                 )
> example.org.        3600 IN A 666.1.2.3
> example.org.        3600 IN AAAA 1234:dead:beef::123
> example.org.        3600 IN NS ns.example.org.
> example.org.        3600 IN NS goodbuddy.secondary.com.
> example.org.        3600 IN MX 10 mail.example.org.
> ns2.example.org.    3600 IN A 666.1.2.4
> mail.example.org.   3600 IN A 666.1.2.5
> hostname.example.org	3600 IN A 666.1.2.6
> 
> ..
> 
> 
> 
> 
>> * you can add a trust anchor for internal.example.org.
>>
>> As more validation takes place in applications the first two
>> will be easier to mangage.
>>
>>> 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
>>> _______________________________________________
>>> 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
> _______________________________________________
> 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
> 


More information about the bind-users mailing list