Scenario
A Bind 9.x server has been installed and configured as a Slave host to an existing Master. TSIG has been configured on both the Master and the Slave servers so that changes to zone files can be transferred securely. Transfers between the Master and the Slave server has been tested and confirmed to be working.
Problem
Upon looking at the Slave logs, you notice there is a number of entries originating from outside the secure network, trying to establish a zone transfer. An example is as follows:
validating ./NS: got insecure response; parent indicates it should be secure
insecurity proof failed resolving './NS/IN': xxx.xxx.xxx.xxx#53
Solution
The default configuration of a Bind 9.x server enables dnssec by default. (It is included in the 'options' section of named.conf . ) Thus, all name resolution traffic that gets directed through the Slave, will be subjected to dnssec . Since our Slave server is going to be used for resolving traffic other than zones it is hosting, we have to change the configuration of the Slave server. This is when Views and ACLs are most handy.
Firstly, a background:
ACLs
ACLs (as its' name suggests) are Access Control Lists. Dependent on what the client's IP address was assigned, determines which control list(s) (ie. ACL(s)) is assigned to. Here is an example of two ACLs:
acl trusted { key ZoneXFER; 192.168.0.0/24; 192.168.1.0/24; localhost; };
acl guest { !key ZoneXFER; 192.168.0.0/24; 192.168.1.0/24; };
In the first ACL, the ACL 'trusted' will only consider client's IP addresses that have a valid TSIG key 'ZoneXFER', and are within the two Class C subnet ranges, as well as itself 'localhost'. However with ACL 'guest', it will only consider client's IP addresses that don't have a valid TSIG key 'ZoneXFER' (note the '!' indicating NOT), and are within the two Class C subnets. Note that 'localhost' has been excluded from the list for client's that aren't trusted. ACLs can be made as granular you want them, depending upon the type of network you are administering and how secure it needs to be.
Views
Views are a way of segmenting the name server access across the network. Think of a View like a separate instance of Bind with a fancy multiplexer in front that determines whereabouts the packet of information gets access to. Views work in conjuction with the ACLs that you assigned in the configuration file. For example: you may want to give clients on one subnet access to the internet, whilst clients on another subnet won't be given access. That's what a Bind 9.x server configured with Views is able to do.
Configuring Named.conf
To configure the Slave so that it properly routes both secured and insecured traffic, you need to implement two views - one for each scenario type. Here I will outline the changes to my configuration.
options {
.
dnssec-enable no;
dnssec-validation no;
allow-recursion { none; };
.
}
acl trusted { key ZoneXFER; 192.168.0.0/24; 192.168.1.0/24; localhost; };
acl guest { !key ZoneXFER; 192.168.0.0/24; 192.168.1.0/24; };
view trusted {
dnssec-enable yes;
dnssec-validation yes;
match-clients { trusted; };
allow-recursion { any; };
allow-transfer { key ZoneXFER; };
zone "thorp.intnet" IN {
type slave;
file "trusted/intnet.zone";
masters { <master ip> key ZoneXFER; };
};
};
view guest {
match-clients { guest; };
allow-recursion { any; };
};
In the 'options' section, I turned off the dnssec settings so as process these settings later in a View. I also disabled recursion by default as a security precaution.
Following on are the ACLs that will help determine which client will be a member of.
Next is the 'trusted' View . How access to the View is determined is by what is contained in the 'match-clients' statement. This statement contains the ACL that the client needs to satisfy. If the client doesn't satisfy the 'match-clients' statement, then the client won't gain access to the resources contained within the View. In this case, a trusted client will have the dnssec features enabled, allow transfers via the TSIG key 'ZoneXFER', and more specifically accept zone transfers of the zone 'thorp.intnet' from the Master via TSIG key 'ZoneXFER'.
Finally is the 'guest' View' . This allows client matching the 'guest' ACL to allow recursion, and to use the dnssec settings described in 'options' (ie. turned off).
In Summary
Views and ACLs are powerful tools to implement when configuring your Bind installation, particularly in a complex network environment. As always, check and re-check your configuration in every scenario, as well as continually monitor your log files in case of unwelcome intruders.
About the author |
|
 |
Tom Thorp is an IT Consultant living in Miami on Queensland's Gold Coast. With over 30+ years working in the IT industry, Tom's experience is a broad canvas. The IT services Tom provides to his clients, includes :
Website development and hosting
Database Administration Server Administration (Windows, Linux, Apple) PABX Hosting and Administration Helpdesk Support (end-user & technical). |
If you like any of my content, consider a donation via Crypto by clicking on one of the payment methods :
|
|
