Bug 1073038 - why does named listen on any IP instead 0.0.0.0
Summary: why does named listen on any IP instead 0.0.0.0
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: bind
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tomáš Hozza
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-05 16:14 UTC by Harald Reindl
Modified: 2014-07-23 13:08 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-23 13:08:21 UTC
Type: Bug


Attachments (Terms of Use)

Description Harald Reindl 2014-03-05 16:14:12 UTC
"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

Comment 1 Pavel Šimerda (pavlix) 2014-03-05 16:27:38 UTC
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.

Comment 2 Harald Reindl 2014-03-05 16:34:17 UTC
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

Comment 3 Adam Tkac 2014-03-05 16:50:45 UTC
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.

Comment 4 Harald Reindl 2014-03-05 17:38:42 UTC
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

Comment 5 Pavel Šimerda (pavlix) 2014-03-06 12:44:32 UTC
(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?

Comment 6 Tomáš Hozza 2014-07-18 15:03:52 UTC
Asked upstream about the reasons...

For the reference: [ISC-Bugs #36574]

Comment 7 Tomáš Hozza 2014-07-21 08:19:47 UTC
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.

Comment 8 Harald Reindl 2014-07-23 10:55:10 UTC
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

Comment 9 Pavel Šimerda (pavlix) 2014-07-23 11:02:58 UTC
(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

Comment 10 Tomáš Hozza 2014-07-23 11:58:34 UTC
(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@isc.org using the "[ISC-Bugs #36574]"
in the subject.

Comment 11 Tomáš Hozza 2014-07-23 13:08:21 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.