Re: bind reacts badly to dhcpcd losing/regaining connectivity

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 15 Apr 2017 02:53:23 +0200
    From:        Rhialto <rhialto%falu.nl@localhost>
    Message-ID:  <20170415005323.GA17890%falu.nl@localhost>

  | I also noticed the error seems to mention IPv4 only. I am not sure if it
  | managed to bind an IPv6 address on the same interface (and now it is too
  | late, unfortunately).

IPv6 does not have the same problem/issue - the IPv6 UDP API was
designed from the start with the requirement that the incoming dest
addr be available to the application, named knows that, and uses it,
so binds just to port 53 on any (all) local v6 addrs.

On munnari, for IPv4, we have (ignoring other sockets for current
tcp connections, etc) ...

tcp        0      0  127.0.0.1.53           *.*                    LISTEN
tcp        0      0  202.29.151.3.53        *.*                    LISTEN
tcp        0      0  172.30.0.22.53         *.*                    LISTEN
udp        0      0  127.0.0.1.53           *.*                   
udp        0      0  202.29.151.3.53        *.*                   
udp        0      0  172.30.0.22.53         *.*                   

whereas for IPv6 ...

tcp6       0      0  *.53                   *.*                    LISTEN
udp6       0      0  *.53                   *.*                   

The IPv4 sockets bound to all the IPv4 addresses for TCP are not really
needed, I assume it is just done that way for simplicity/consistency.

  | In case it makes a difference, I am running bind in the chroot as
  | provided by named_chrootdir="/var/chroot/named". And I have 2 views, an
  | internal and an external one.

The chroot itself makes no difference (it is changing from root to _named
or whatever user name it uses, that matters) and nor do views (though
personally I believe that the DNS tree should be one consistent data
set with the exact same answers available from everywhere).

kre