DNS Infrastructure: #2 Hidden Master

A hidden primary master is a nameserver which is not publicly advertised. It does not answer queries; it’s only purpose is to act as source for authoritative data. The easiest way to achieve this is to treat the publicly advertised nameservers as slaves:

  • – (master / hidden)
  • dns1 (slave / primary)
  • dns2 (slave / secondary)

This introduces a single point of failure since if the hidden master fails and reaches TTLs or does not make zone-transfers with dns1/dns2 then entries might leave the DNS infrastructure without anyone noticing. Therefore it is absolutely required to monitor a hidden primary master – or to use some of the high availability tools to make sure it can’t go away (keepalived, heartbeat, etcetera).

So why should someone want a hidden primary master?

A publicly advertised master is open for attacks from the outside (internet) and might get compromised; In the case of an attack of the outside, if the master is down it might not be able to send zone transfers to its slave(s). Basically that means, having a hidden master increases security and reliability of the DNS infrastructure.

dns3.ip-minds.eu

This is a so-called hidden master. The purpose of this DNS server is to provide zone-transfers to the publicly advertised DNS servers dns1.ip-minds.eu and dns2.ip-minds.eu.

Zone updates, DNSSEC signing, etc happens on this server, which then sends notifications to dns1.ip-minds.eu and dns2.ip-minds.eu. This also applies for DNS servers we act as a slave for. For updates/zone-transfers they communicate with dns3 which then notifies dns1 and dns2.

Generic configuration

# named.conf>
include "/etc/bind/named.conf.bogons";
include "/etc/bind/named.conf.acl";
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/named.conf.zones";

Access Control Lists

keys

For every server-to-server connection there is one key in the configuration. A key is defined by:

key key_id {
    algorithm string;
    secret string;
};

The algorithm might be one of hmac-md5, hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384 and hmac-sha512. We do use hmac-sha256 as default. In this case there are the following connections

  • dns3.ip-minds.eu to dns1.ip-minds.eu
  • dns3.ip-minds.eu to dns2.ip-minds.eu
  • dns3.ip-minds.eu to ns1.xxxx // (a friend using us as secondary nameserver) //

The keys can be created using

dnssec-keygen -a hmac-sha256 -b 128 -n HOST host1-host2.

The key is in the file Khost1-host2.+XXX+XXXXX.private. Nothing uses this file, but the
string following „Key:“ can be extracted from the file and used as secret. Putting this altogether it does look like this:

key dns3-dns1.ip-minds.eu. {
    algorithm hmac-sha256;
    secret "xxxx==";
};
 
key dns3-dns2.ip-minds.eu. {
    algorithm hmac-sha256;
    secret "xxxx==";
};
 
key dns3-ns1.xxxx. {
    algorithm hmac-sha256;
    secret "xxxx==";
};
server

For every server (in this case dns1.ip-minds.eu, dns2.ip-minds.eu, ns1.xxxx) there is one server-entry in the configuration. This is used to allow and advertise udp packet sizes of up to 4096 bytes. We do also enable many-answers which is more efficient (but might only be understandable by BIND) with zone transfers. Finally the previously defined key is referenced. In general that looks like this:

server ip {
    edns-udp-size 4096;
    max-udp-size 4096;
    transfer-format many-answers;
    keys {
        key_id;
    };
};

In this case the following entries are created:

server xx.xxx.xx.xxx/32 {
    edns-udp-size 4096;
    max-udp-size 4096;
    transfer-format many-answers;
    keys { dns3-dns1.ip-minds.eu.; };
};
 
server xxx.xx.xxx.xxx/32 {
    edns-udp-size 4096;
    max-udp-size 4096;
    transfer-format many-answers;
    keys { dns3-dns2.ip-minds.eu.; };
};
 
server xxxx:xxxx:xx::xx/128 {
    edns-udp-size 4096;
    max-udp-size 4096;
    transfer-format many-answers;
    keys { dns3-dns1.ip-minds.eu.; };
};
 
server xxxx:xxxx:xx::x/128 {
    edns-udp-size 4096;
    max-udp-size 4096;
    transfer-format many-answers;
    keys { dns3-dns2.ip-minds.eu.; };
};
 
server xx.xxx.xxx.xx/32 {
    edns-udp-size 4096;
    max-udp-size 4096;
    transfer-format many-answers;
    keys { dns3-ns1.xxxx.; };
};
acl and masters

Finally the IPs listed in server entries are placed into an ACL so that this can be accessed through a name later. An ACL looks like this:

acl name {
    ip1;
    ip2;
};

In this case:

acl authoritatives {
    xx.xxx.xx.xx/32;
    xxx.xx.xxx.xxx/32;
    xxxx:xxxx:xx::xx/128;
    xxxx:xxxx:xx::x/128;
    xx.xxx.xxx.xx/32;
};

To easily reference names like „masters“ and „slaves“ there are a few further acl-clauses and master-clauses:

masters dns1.ip-minds.eu. {
    xx.xxx.xx.xxx key dns3-dns1.ip-minds.eu.;
    xxxx:xxxx:xx::xx key dns3-dns1.ip-minds.eu.;
};
 
masters dns2.ip-minds.eu. {
    xxx.xx.xxx.xxx key dns3-dns2.ip-minds.eu.;
    xxxx:xxxx:xx::x key dns3-dns2.ip-minds.eu.;
};
 
masters ns1.xxxx. {
    xx.xxx.xxx.xx key dns3.ip-minds.eu-ns1.xxxx.;
};
 
acl masters {
    xx.xxx.xxx.xx;
};
 
masters slaves {
    dns1.ip-minds.eu.;
    dns2.ip-minds.eu.;
};

Options

The main configuration of the nameserver occurs in the options-block:

options {
    directory "/var/named";
    key-directory "keys";
cache

Specifying additional-from-cache no actually disables the use of the cache not only for additional data lookups but also when looking up the answer. This is usually the desired behavior in an authoritative-only server where the correctness of the cached data is an issue. [..] the server will not be able to provide upwards referrals when additional-from-cache no has been specified. Instead, it will respond to such queries with REFUSED. This should not cause any problems since upwards referrals are not required for the resolution process
BIND 9 Administrator Reference Manual Page 69

    additional-from-cache no;

For the same reason as explained above, you do not want the cache to be accessible. Hence disallowing it per

    allow-query-cache { none; };
recursion

Since this is an authoritative server recursion should be disabled

    recursion no;
updates, transfers and notifies

The remaining part of the configuration makes sure that only our slave nameservers are notified , updates are restricted to localhost and transfers are restricted to all authoritative nameservers.

    allow-update { localhost; };
    allow-transfer { authoritatives; };
 
    notify explicit;
    allow-notify { masters; };
    also-notify { slaves; };
};

public advertised authoritatives

(talking about dns1 and dns2 which are publicly advertised. dns3 is _not_). These are pretty similar configured, in addition:

bogons

I am using a list of bogons to protect against spoofing; those are located in a file named.conf.bogons which is auto-created with the [[scripts:dns-bogons|bogons-bash-script]].

    blackhole { bogons; };

ratelimit

    rate-limit {
        responses-per-second 10;
        exempt-clients { resolvers; };
    };

updates, transfers and notifies

The remaining part of the configuration makes sure that only our slave nameservers are notified , updates are restricted to localhost and transfers are restricted to all authoritative nameservers. Version is set to some string to hide the version.

    allow-update { localhost; };
    allow-transfer { authoritatives; };
 
    notify explicit;
    allow-notify { masters; };
    also-notify { slaves; };
 
    version "none of your business";
};

Zone Examples

dns1.ip-minds.eu

zone "ip-minds.eu" {
    type slave;
    masters { dns3.ip-minds.eu.; };
    file "zones/ip-minds.eu"; 
};

dns2.ip-minds.eu

zone "ip-minds.eu" {
    type slave;
    masters { dns3.ip-minds.eu.; };
    file "zones/ip-minds.eu"; 
};

dns3.ip-minds.eu

Master with DNSSEC
# /etc/bind/named.conf.zones
zone "antiucegateway.de" {
    type master;
    file "zones/antiucegateway.de";
    key-directory "keys/antiucegateway.de";
    inline-signing yes;
    auto-dnssec maintain;
};
Master without DNSSEC
# /etc/bind/named.conf.zones
zone "no-uce.de" {
    type master;
    file "zones/no-uce.de";
};

No Comments

Post a Comment