DNSSEC and split DNS
David Newman
dnewman at networktest.com
Sat Oct 26 01:11:24 UTC 2013
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:
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.
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.
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?
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
More information about the bind-users
mailing list