2

I have set up a single DNS server with bind9 and a split dns configuration so that all internal requests for my domain name get the internal IP address, and all requests from outside my network get the official address (which are routed through the Cisco ASA firewall but will eventually reach the same systems).

When I use nsupdate from my internal network, the internal zone is updated. Likewise when I run nsupdate on an outside system (with TSIG), then the external zone is updated.

However I would rather be able to update all DNS data from within the internal network. The problem seems to be that I can define several views to my domain name but bind9 identifies the zone to use by the ip address of the client, according to my views.conf. So when it is an internal ip address, the internal zone is retrieved or updated, but it is not possible to update the external zone from an internal system.

I also tried using two different TSIG keys in the hope that bind9 can identify the external zone by the key, which does not work either:

Aug 26 11:04:22 s1006 named[13444]: client 10.1.1.6#39841: view internal: signer "external" denied
Aug 26 11:04:22 s1006 named[13444]: client 10.1.1.6#39841: view internal: update 'example.org/IN' denied

Here are the relevant bind9 configuration settings:

view "internal" {
        match-clients {
                10.1.1.6;
        };
        recursion yes;
        include "/etc/bind/named.conf.default-zones";

        include "/etc/bind/zones/example.org-internal.conf";
};

view "external" {
        match-clients {
                10.1.1.3;
        };
        recursion no;
        include "/etc/bind/named.conf.default-zones";

        include "/etc/bind/zones/example.org-external.conf";
};

key internal {
        algorithm hmac-md5;
        secret "x2ZKW4SxbeySMK7PmV1Nng==";
};

key external {
        algorithm hmac-md5;
        secret "kiHB9BR6IeSmUUnp1QMCcA==";
};

zone "example.org" {
        type master;
        file "/var/cache/bind/example.org-internal/example.org";
        notify yes;
        allow-update {
                key internal;
        };
};

zone "example.org" {
        type master;
        file "/var/cache/bind/example.org-external/example.org";
        notify yes;
        allow-update {
                key external;
        };
};

Note: for test purposes the views are set up so that all requests from 10.1.1.3 are "external" and from 10.1.1.6 are considered "internal".

Please advise how to configure this so that I can update the external zone by running nsupdate on 10.1.1.6 instead of 10.1.1.3. Also if you think this particular setup is a really dumb idea please let me know.

2 Answers 2

1

I think the best solution would generally be to just use dedicated TSIG keys to access the different views.

I know the question mentions this and says it didn't work, but that must have been because the client matching directives of the two views were not updated appropriately.

If we assume that there are the two TSIG keys named internal and external for this purpose (looks to be the case in the question), the views should be updated along these lines:

view "internal" {
        match-clients {
                key "internal";
                !key "external";
                ... # existing IP-based matching as it was
        };
        ... # all the other stuff from the view as it was
};

and

view "external" {
        match-clients {
                    key "external";
                    !key "internal";
                    ... # existing IP-based matching as it was
        };
        ... # all the other stuff from the view as it was
};

This way, any incoming messages (queries/updates) signed with one of these two keys will always hit the corresponding view as the new key-based matching entries are listed before any IP-based matching and exhaust all possible view/key combinations regarding these keys.

(Technically there is a bit of redundancy in my proposed solution as the order of the views are also a factor that could be used to eliminate some view/key combinations, but I would recommend explicitly listing all the combinations regardless. This way things don't fall apart if you were to reorder the views, and I personally also find it more clear what the actual intent is.)

0

nsupdate has a local subcommand which lets you select the source address. In theory this will let you trigger an update of the external view from inside the internal network by using an external source address. In practice your firewall policy may prevent it.

1
  • unfortunately I can't use this subcommand due to our network configuration.
    – nn4l
    Aug 26, 2014 at 10:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .