2

The listen-on statement of bind9 configuration seems to only take IP address(es) for an interface. "man named.conf" shows details on listen-on

For an internal named daemon, the interface being listen on can be declared as:

listen-on {
    127.0.0.1;
    192.168.1.1;
 };

Now onward to the external bind9/named daemon... ISP provides dynamic IP address to this box (ie. 4.3.2.1). If I wanted to listen ONLY to the ISP-assigned IP address, I tried this:

listen-on {
    !127.0.0.1;
    !192.168.1.1;
 };

Alas, that didn't work on stopping bind named from picking up any of the unused network interfaces.

How does one make bind9 named daemon listen ONLY on the dynamic IP interface and none of the unused interfaces (IP address)? Remember, you don't know in advance the IP address of the public-facing network interface that you need for your bind's configuration file.

John Greene
  • 2,239
  • 3
  • 26
  • 37

1 Answers1

5

This works for me:

listen-on {
        !127.0.0.1;
        !172.17.0.0/24;
        0.0.0.0/0;
};

Or if you know the list of the potential IP address ranges used by the service provider (you could ask them, or you could look into the WHOIS database for their AS route objects), you could list those prefixes only:

listen-on {
        194.38.96.0/19;
        200.201.202.0/24;
};
Laszlo Valko
  • 2,683
  • 25
  • 29
  • Secured against latching on to a renegade DHCP server? Probably not. It’s more ideal to have this “latching on to a specific network interface”, no? – John Greene Jan 14 '19 at 15:26
  • 1
    It's the service/network provider's job to make sure no renegade DHCP servers can supply a bogus IP to your server. – Laszlo Valko Jan 14 '19 at 17:11
  • I agree. Can’t say the same for my ISP provider. Got a neighborhood DHCP server and he is “apparently” targeting a specific MAC. – John Greene Jan 14 '19 at 17:12
  • Workaround is to do MAC filtering on the upstream but it would require prior screenshot of the ISP router’s ARP table. (And periodic checking, *groan* – John Greene Jan 14 '19 at 17:14
  • 1
    You can install an ebtables filter to filter out all traffic from his MAC address, including the bogus DHCP replies :D – Laszlo Valko Jan 14 '19 at 17:14
  • Don’t forget, it is not just an entry for ebtable for the ISP DHCP server (they have primary/secondary) but one for media server, upstream router/concentrator, DNS serverS (not that I use them), and their NMS. – John Greene Jan 14 '19 at 17:17
  • It’s a poor network engineer design that requires piling on other ISO layer filtering. Bind9 could co-opt Apache web server interface design and allow something like `listen-on { device eth0; };`, but noooo. Accepting this answer as the ONLY but poor workaround. – John Greene Jul 04 '22 at 13:28