DNSSEC and split DNS

[David Newman]

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

[Mark Andrews]

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.

Mark

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[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 Andrews]

In message <526857A2...@networktest.com>, David Newman writes:
> 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.

DNSSEC seeks to prevent *other parties* from injecting in false
data.

With split DNS while the data presented to different clients differs
it is still true data coming from the owner of the data.

Split DNS is no different to having a single zone. Updating it on
every query based on the address the query came from then returning
the response.

> 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-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

[Mark Andrews]

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

[David Newman]

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

..

[David Newman]

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

[Mark Andrews]

In message <526EBA87...@networktest.com>, David Newman writes:
>
> > 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.

Inconsistant use of views. The NOERROR will probably be coming
from a the internal view and the NXDOMAIN from the external view
(or the other way around).

As for SERVFAIL you may have badly configured firewalls that are
dropping fragmented responses, or responses > 512 bytes resulting
in excessive timeouts and excessive use of TCP. This is more visible
in a newly started server.

Mark

[David Newman]

On 10/28/13 1:46 PM, Mark Andrews wrote:
> In message <526EBA87...@networktest.com>, David Newman writes:
>>
>>> 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.
>
> Inconsistant use of views. The NOERROR will probably be coming
> from a the internal view and the NXDOMAIN from the external view
> (or the other way around).

The underlying question is what forwarders to use, if any, on an
internal caching-only nameserver where DNSSEC and split DNS are in use.

In this case, per your guidance there are two versions of some zones,
with the internal version using delegation and the external not.

The only way I can think of is to allow recursion on authoritative
servers, but only from the caching-only servers, and put the
authoritative servers in their forwarders statement.

For all other clients, the only servers with recursion would be the
caching-only ones. And the authoritative servers would be the only ones
listed in the forwarders statement.

Or is there a better way to do this?

thanks

dn