Split-DNS + Views + master/slave

[Jay Ford]

On Thu, 7 Jul 2011, Ewald Jenisch wrote:
> So here is my question: How do I set up two servers (master/slave)
> using views (for internal and external clients) so that both of them
> hold the the correct data and return the correct answers to their
> respective clients (inside and outside)?
>
> Thanks much in advance for any clue,

You need to think about the master-slave interaction in the context of the 
views.  The master will receive zone transfer requests & the slave will
receive notifies, all of which need to be handled correctly for each view.

With your current configuration, the zone transfer requests by the slave will
be treated by the master to be in 1 view based on the view definition.  In
your case, it's probably the internal view because the slave is probably in
the "trusted" address range.  The effect is that the slave will get the
internal view data from the master when the slave requests it for the
internal view, then it will get the same internal view data from the master
when the slave requests it for the external view.  Does that explain what you
are seeing?

The "trick" is to let the master & slave differentiate the notifies &
transfers in each view.  The most flexible way to do that is with TSIG, such
as defining a key to trigger the external view by overriding the address
range.

You can use TSIG for all inter-server traffic, via a "normal" key.

For example:

______________________________master______________________________
...
key intra-dns.keys. {
    algorithm hmac-md5;
    secret "<normal-key-data>";
};
key intra-dns-be-internal.keys. {
    algorithm hmac-md5;
    secret "<be-internal-key-data>";
};
key intra-dns-be-external.keys. {
    algorithm hmac-md5;
    secret "<be-external-key-data>";
};

view "internal" {
    // the internal view is for local queriers except those which connect
    // using the "be-external" key which triggers non-local behavior
    // (used by our slave servers getting the zones in the external
    // view); it's also for any querier which connects using the
    // "be-internal" key
    match-clients {
       key intra-dns-be-internal.keys.;
       !key intra-dns-be-external.keys.;
       acl-internal;
    };

    // normal TSIG key for inter-server traffic
    server <slave> {
       keys { intra-dns.keys. ; };
    };

    ...internal zone definitions...

}; // end internal view

view "external" {
    // the internal view is for everybody else who wasn't considered local
    match-clients { any; };

    // special "be-external" TSIG key used by local servers
    // when getting zones in external view
    server <slave> {
           keys { intra-dns-be-external.keys. ; };
    };

    ...external zone definitions...

}; // end external view
__________________________________________________________________

______________________________slave_______________________________
...
key intra-dns.keys. {
    algorithm hmac-md5;
    secret "<normal-key-data>";
};
key intra-dns-be-internal.keys. {
    algorithm hmac-md5;
    secret "<be-internal-key-data>";
};
key intra-dns-be-external.keys. {
    algorithm hmac-md5;
    secret "<be-external-key-data>";
};

view "internal" {
    // the internal view is for local queriers except those which connect
    // using the "be-external" key which triggers non-local behavior
    // (used by our slave servers getting the zones in the external
    // view); it's also for any querier which connects using the
    // "be-internal" key
    match-clients {
       key intra-dns-be-internal.keys.;
       !key intra-dns-be-external.keys.;
       acl-internal;
    };
    // normal TSIG key for inter-server traffic
    server <master> {
    	keys { intra-dns.keys. ; };
    };

    ...internal zone definitions...

}; // end internal view

view "external" {
    // the internal view is for everybody else who wasn't considered local
    match-clients { any; };

    // special "be-external" TSIG key used by local servers
    // when getting zones in external view
    server <master> {
       keys { intra-dns-be-external.keys. ; };
    };

    ...external zone definitions...

}; // end external view
__________________________________________________________________

So, the master & slave each use the "intra-dns-be-external.keys." key to get
the external view.  They use the normal "intra-dns.keys." key to get the
internal view, letting the address-based ACL select that view.

The "intra-dns-be-internal.keys." key isn't used in the example, but can be
useful for troubleshooting.  For example, you can tell dig to use that key
when querying from an "external" client to get the "internal" view.  The
reverse is probably more useful, using the "be-external" key on an "internal"
client to get the external view.

It's complicated, but that's the fun with multi-view DNS.  ;^)


In case you don't already do so, you might be able to save yourself some work
by including the common data into both views on the master instead of
duplicating it.  That is, have 3 files:
    1. internal view file: SOA, NS..., internal-only data, & an $INCLUDE of
       file #3
    2. external view file: SOA, NS..., external-only data, & an $INCLUDE of
       file #3
    3. common view file: common data (no SOA...)
If the SOA, NS... are the same between the views, they can also be in the
common file.

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951