Exposure of hidden-master stealth DNS server on public-facing authoritative slave

Question

In a typical hidden-master DNS network layout, there are basically two components:

• Hidden master DNS server, may be behind a NAT or firewall, or be totally exposed
• Slave authoritative non-recursive DNS server(s)

Zone files on slave DNS servers often do not (and should not) have information to this hidden master DNS server. But these same slave DNS servers do require the use of certain DNS options like server, allow-update, allow-transfer, and some ACLs.

While at first, those required server and allow-update seem to require an IP address match list. This leaves the named.conf as the primary source of such stealth information (i.e. the IP address of the hidden-master).

Can such exposure of the IP address to the hidden-master DNS server be further limited by using keys instead and not using any IP address in the named.conf file?

The key answer I’m looking for is whether or not we can minimize exposure of hidden-master at the level of its configuration file as well as in zone databases.

Answer 1

Zone files on slave DNS servers often do not (and should not) have information to this hidden master DNS server.

They can have A records in their zone files to point to this hidden DNS master server. The server is called "hidden" not because no one can ever know about it, but because it's not listed anywhere using NS records so clients can't query them.

Edit: there is no point in trying to avoid all references to this hidden master from your configuration file. Once someone has access to this file, it assumes they have access to your server anyway and then that sounds like a bigger problem than them knowing the IP address of your hidden master.

But these same slave DNS servers do require the use of certain DNS options like server, allow-update, allow-transfer, and some ACLs.

The slave DNS servers do indeed need to know about the existence of the hidden DNS server. It's possible to define masters using only keys and then refer to those masters in the allow-notify etc statements. That way you do not need to specify the IP address of the hidden master server.

The server statement looks like this:

server <netprefix> {
   ...
};

Thus it requires the IP address of the hidden master.

It seems however that statements like allow-update, allow-transfer etc require an address_match_list which (BIND 9.11.4-P1 documentation, p. 51):

(...) is a list of one or more ip_addr, ip_prefix, key_id, or acl_name elements, see section 6.1.

So you can enter only keys in these commands, excluding the IP address of your hidden master from those parts of the configuration.