Re: bind reacts badly to dhcpcd losing/regaining connectivity

[christos%astron.com@localhost (Christos Zoulas)]

In article <4355.1492217952%andromeda.noi.kre.to@localhost>,
Robert Elz  <kre%munnari.OZ.AU@localhost> wrote:
>    Date:        Sat, 15 Apr 2017 01:41:17 +0200
>    From:        Rhialto <rhialto%falu.nl@localhost>
>    Message-ID:  <20170414234117.GA18315%falu.nl@localhost>
>
>
>  | Why does named not succeed in using the interface when it gets an
>  | address again? What to do about it? I noticed partly because my dns data
>  | seemed to have dropped out of caching name servers elsewhere.
>
>This will be a side-effect of the non-root version of named.
>
>Named binds to port 53 on each address it can find, rather than
>just port 53 (any address) as typical daemons do, as it is required
>to send its replies (UDP replies) from the same address as they
>were sent to (part of the DNS spec.)
>
>[These days, I think there's an interface to allow a UDP socket
>to be told which (local) addr a packet was sent to, but when bind
>was created there was no such thing, so it does it the way that
>works everywhere.]
>
>Binding to port 53 requires root permissions - when named first starts
>it binds to all addresses, and then drops privs.
>
>Later, when an addr goes away, it will close the socket bound to that
>addr - if the addr comes back (or a new address appears) it (attempts
>to) bind to port 53 on that addr - but without root privs any more, it
>cannot (EPERM).
>
>Solutions to this are just to always run as root, or to recode the
>receive code to use the new way to receive the dest addr of incoming
>packets, and to set the source addr of outgoing ones (so just one
>UDP socket is needed), or perhaps to have named simply re-exec itself
>whenever a new addr appears, if not running as root.

Or capabilities, or wildcard bind.

christos