Report information
The Basics
Id:
36574
Status:
resolved
Priority:
Medium/Medium
Queue:
bind9-public
People
Owner:
Nobody in particular
Requestors:
Tomas Hozza <thozza@redhat.com>
Cc:
AdminCc:
BugTracker
Version Fixed:
(no value)
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
(no value)
Priority:
(no value)
Severity:
(no value)
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
(no value)
Area:
(no value)
Dates
Created:Fri, 18 Jul 2014 11:02:45 -0400
Updated:Fri, 07 Jul 2017 20:15:25 -0400
Closed:Wed, 01 Oct 2014 02:07:53 -0400

This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

History
  Fri, 18 Jul 2014 11:02:45 -0400 Tomas Hozza <thozza@redhat.com> - Ticket created
CC: Pavel Simerda <psimerda@redhat.com>
Subject: The way of binding to listen-on addresses
Date: Fri, 18 Jul 2014 11:02:42 -0400 (EDT)
To: bind-suggest@isc.org
From: Tomas Hozza <thozza@redhat.com>

Hi. Recently we had some issues with starting services (also named) in Fedora due to Systemd changes. This brought huge discussion about whether some services could use IP_FREEBIND socket option to be able to bind to the address, before it is configured on the interface. I looked into named sources and realized that it looks for existing interface with the specified address and if there is none it does not even try to bind to it. Did you ever considered using IP_FREEBIND socket option when binding named to a specific address(es) and changing the logic? It should be possible, but looking at the code it's far from trivial. Second think I would like to discuss is the named behavior when it is configured to listen on 'any' address. It binds to all specific addresses available on the system when starting up. If some interface goes up, one have to restart named. Did you considered adding support for netlink to be able to dynamically bind to new addresses? In Fedora we already have come "complains" [1] about why named does not bind to 0.0.0.0 when configured to listen-on 'any' address. Adam Tkac commented that he recalls the reason is that there is no portable way for IPv4 to find out to which address was the incoming packet addressed. Is this really the reason, or are there any other? Did you considered using the 0.0.0.0 address when listening on 'any' address (even to use some non-portable way on systems supporting it)? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1073038 Thank you in advance. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com
  Fri, 18 Jul 2014 18:36:33 -0400 Brian Conry <bconry@isc.org> - Correspondence added

Hi Tomas, I can't speak to everything you brought up, but I can answer one item: > Second think I would like to discuss is the named behavior when it is > configured to listen on 'any' address. It binds to all specific addresses > available on the system when starting up. If some interface goes up, > one have to restart named. There is a configuration option, 'interface-interval' that specifies how often, in minutes, named should rescan the interfaces looking for changes and adjusting what it is listening on accordingly. Thanks, Brian Conry
Fri, 18 Jul 2014 18:36:33 -0400 The RT System itself - Status changed from 'new' to 'open'
  Fri, 18 Jul 2014 22:13:10 -0400 Mark Andrews <marka@isc.org> - Correspondence added
Subject: Re: [ISC-Bugs #36574] The way of binding to listen-on addresses
Date: Sat, 19 Jul 2014 12:13:06 +1000
To: bind-suggest@isc.org
From: Mark Andrews <marka@isc.org>

Also 9.10 has the following. Scanning is needed for be done to update the built in acls. 3733. [func] Improve interface scanning support. Interface information will be automatically updated if the OS supports routing sockets (MacOS, *BSD, Linux). Use "automatic-interface-scan no;" to disable. Add "rndc scan" to trigger a scan. [RT #23027] In message <rt-3.8.6-35155-1405722993-1507.36574-4-0@isc.org>, "Brian Conry via RT" writes: > Hi Tomas, > > I can't speak to everything you brought up, but I can answer one item: > > > Second think I would like to discuss is the named behavior when it is > > configured to listen on 'any' address. It binds to all specific addresses > > available on the system when starting up. If some interface goes up, > > one have to restart named. > > There is a configuration option, 'interface-interval' that specifies how > often, in minutes, named should rescan the interfaces looking for changes > and adjusting what it is listening on accordingly. > > Thanks, > Brian Conry > > -- > Ticket History: https://bugs.isc.org/Ticket/Display.html?id=36574 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
  Mon, 21 Jul 2014 03:08:04 -0400 Tomas Hozza <thozza@redhat.com> - Correspondence added
Subject: Re: [ISC-Bugs #36574] The way of binding to listen-on addresses
Date: Mon, 21 Jul 2014 03:07:58 -0400 (EDT)
To: bind-suggest@isc.org
From: Tomas Hozza <thozza@redhat.com>

----- Original Message ----- > Hi Tomas, > > I can't speak to everything you brought up, but I can answer one item: > > > Second think I would like to discuss is the named behavior when it is > > configured to listen on 'any' address. It binds to all specific addresses > > available on the system when starting up. If some interface goes up, > > one have to restart named. > > There is a configuration option, 'interface-interval' that specifies how > often, in minutes, named should rescan the interfaces looking for changes > and adjusting what it is listening on accordingly. > > Thanks, > Brian Conry > Thank you very much for the response. I was not aware of the option. Regards, -- Tomas Hozza Software Engineer - EMEA ENG Developer Experience PGP: 1D9F3C2D Red Hat Inc. http://cz.redhat.com
Wed, 01 Oct 2014 02:07:53 -0400 Mark Andrews <marka@isc.org> - Status changed from 'open' to 'resolved'
Fri, 07 Jul 2017 20:15:25 -0400 Vicky Risk <vicky@isc.org> - Queue changed from #3 to bind9-public