"netstat -l" shows for each interface named is listening to port 53 UDP and TCP instead just 0.0.0.0:53 listen-on {0.0.0.0;}; results in no longer listening on any interface that is really a strange behavior and resuluts in you need to mangle "named.service" with "After=openvpn.service" in case somewhere in the boot process OpenVPN gets started and you expect a working name-resolution on the VPN address from the target network
I must say I was also always curious about the reason as it doesn't happen for IPv6. It's not only hand-configured OpenVPN which is affected, on the other hand, AFAIK there are dispatcher.d scripts for NetworkManager.
no NetworkManager for me - my setups are way to complex and built from a lot of services like bringing up a second WLAN-AP with a "fake MAC" for a guest-WLAN and complex routings to different VPN subnets all over the country and even if - it's a workaround not a solution eth0 eth1 eth2 wlan0 wlan1 br0 br1 tap0 vmnet8 that listen-on {0.0.0.0;}; results in no longer listen at all is clearly a bug, the default iterate the interfaces is questionable, but may it be so - if i say 0.0.0.0 i mean that
If I remember well, main reason why named creates per-interface IPv4 sockets is that there is no portable way of getting destination IPv4 address of DNS packet on the server when socket listens on 0.0.0.0. However there is portable way for IPv6 sockets, so this is the reason why named creates IPv4 socket for each interface (and not one for 0.0.0.0) and one socket for all IPv6 interfaces. Note that destination IP address must be known and set correctly in reply, otherwise clients will be confused.
i don't buy that, otherwise any UDP service would have that problem and the two dhcpd instances on the same machine, both listening to 0.0.0.0 would not work - both dhcpd serve a different subnet on one of the two hostapd-wlan-instances udp 0 0 0.0.0.0:67 0.0.0.0:* 7124/dhcpd udp 0 0 0.0.0.0:67 0.0.0.0:* 7128/dhcpd dhcpd 7124 0.0 0.1 108000 18800 ? Ss 15:58 0:02 /usr/sbin/dhcpd -4 -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid br0 dhcpd 7128 0.0 0.1 107528 18392 ? Ss 15:58 0:02 /usr/sbin/dhcpd -4 -f -cf /etc/dhcp/dhcpd-guest.conf -lf /var/lib/dhcpd/dhcpd-guest.leases -user dhcpd -group dhcpd --no-pid br1
(In reply to Harald Reindl from comment #2) > no NetworkManager for me - my setups are way to complex That doesn't prevent you from using the very same workaround of restarting BIND whenever it's expected to rescan the devices. (In reply to Harald Reindl from comment #4) > i don't buy that, otherwise any UDP service would have that problem and the > two dhcpd instances on the same machine, both listening to 0.0.0.0 would not > work - both dhcpd serve a different subnet on one of the two > hostapd-wlan-instances While the dhcpd instances are not bound to a specific IP address, they are bound to a specific device which you don't see in netstat and similar tools. Otherwise, without any flags, they couldn't listen on the same IP and port at all. Look for SO_BINDTODEVICE socket option for more details. (In reply to Adam Tkac from comment #3) > If I remember well, main reason why named creates per-interface IPv4 sockets > is that there is no portable way of getting destination IPv4 address of DNS > packet on the server when socket listens on 0.0.0.0. Any specific information for that? Also, even if there was no portable way, I don't see a reason not to use the nonportable way specifically for Linux as that way you could avoid the restarting workaround in all sorts of tools. Btw, when does BIND need to check the destination address? Would it be possible to just disable the per-destination feature when listening on 0.0.0.0?
Asked upstream about the reasons... For the reference: [ISC-Bugs #36574]
I didn't get any response regarding the reasons or motivation, however Brian Conry pointed out the 'interface-interval' option I was not aware of: interface-interval (From 9.9.5 ARM) ----------------------------------- The server will scan the network interface list every interface-interval minutes. The default is 60 minutes. The maximum value is 28 days (40320 minutes). If set to 0, interface scanning will only occur when the configuration file is loaded. After the scan, the server will begin listening for queries on any newly discovered interfaces (provided they are allowed by the listen-on configuration), and will stop listening on interfaces that have gone away. Also Mark Andrews pointed out improved situation in BIND 9.10: automatic-interface-scan (From 9.10.0 ARM) ------------------------------------------ If yes and supported by the OS, automatically rescan network interfaces when the interface addresses are added or removed. The default is yes. Currently the OS needs to support routing sockets for automatic-interface-scan to be supported. (In reply to Harald Reindl from comment #0) > "netstat -l" shows for each interface named is listening to port 53 UDP and > TCP instead just 0.0.0.0:53 > > listen-on {0.0.0.0;}; results in no longer listening on any interface If specific address is passed to BIND, it looks for an existing interface with this address. Since you don't have 0.0.0.0 on any interface it does not listen on any interface. Please consider using 'any' for address and using the 'interface-interval' option set to the lowest possible value. BIND 9.10 rebase is planned for F22 and as pointed out it should improve the situation even more. > that is really a strange behavior and resuluts in you need to mangle > "named.service" with "After=openvpn.service" in case somewhere in the boot > process OpenVPN gets started and you expect a working name-resolution on the > VPN address from the target network I admit it could work out-of-the-box. However I don't see a big problem in adjusting the named.service to reflect special needs of your configuration. Note that it should be enough just to: echo "After=openvpn.service" >> /etc/systemd/system/named.service.d/myopenvpnsetup.conf I will leave this bug opened for a while to see if upstream responds with any specific reasons.
while i understood partly what is happening it's still wrong 0.0.0.0 is by defintion "all interfaces" and means a listening socket independent of how many interfaces are there, added or removed and last but not least it is available in a early boot state that should in general be the default for any network facing service unless specific configuration not to do so
(In reply to Harald Reindl from comment #8) > 0.0.0.0 is by defintion "all interfaces" and means > a listening socket independent of how many interfaces > are there, added or removed and last but not least it > is available in a early boot state > > that should in general be the default for any network > facing service unless specific configuration not to > do so +1
(In reply to Harald Reindl from comment #8) > while i understood partly what is happening it's still wrong > > 0.0.0.0 is by defintion "all interfaces" and means > a listening socket independent of how many interfaces > are there, added or removed and last but not least it > is available in a early boot state > > that should in general be the default for any network > facing service unless specific configuration not to > do so Feel free to express your opinion to upstream by sending email to bind-suggest using the "[ISC-Bugs #36574]" in the subject.
Closing as UPSTREAM. This is definitely not a Bug, but intention. The concern was forwarded to upstream. I'm not going to implement the change because you think it is wrong, however you are welcomed to implement it by yourself.