Bind named to 0.0.0.0 (INADDR_ANY)

Adam Tkac atkac at redhat.com
Wed Oct 1 09:02:36 UTC 2008


On Wed, Oct 01, 2008 at 11:28:25AM +1000, Mark Andrews wrote:
> 
> In message <cbf1a1340809301028o3ffc5e71ua6a38d7aaefeedca at mail.gmail.com>, "Rich
> ard Wall" writes:
> > 2008/9/30 Mark Andrews <Mark_Andrews at isc.org>:
> > > In message <cbf1a1340809300721j468531d5sa5da8bedb3fff47e at mail.gmail.com>, "
> > Rich
> > > ard Wall" writes:
> > <snip>
> > >> I've tried:
> > >> listen-on { 0.0.0.0; };
> > >        Which is "listen-on { 0.0.0.0/32; };" which won't match any
> > >        interface's address.
> > 
> > Hi Mark,
> > 
> > Understood.
> > 
> > <snip>
> > >> listen-on { any; };
> > >> listen-on { localhost; };
> > >> listen-on { localnets; };
> > >> These explicitly bind named to the configured local IP addresses.
> > >> Is there another way to do this?
> > >
> > >        No. Named listens on individual interfaces so that the reply
> > >        traffic comes from the correct address.
> > >
> > 
> > Okay, thanks for the prompt response. We were looking for a convenient
> > way to use multiple source and destination addresses with dns views,
> > but we can just explicitly configure all the IPs that we're going to
> > use.
> > 
> > Out of interest, how do other services get round this? For example I
> > notice that ntpd is listening on IPv4 0.0.0.0:123; doesn't it have the
> > same issue?
> 
> 	Yes and the same solution was used. :-)

Well it is quite different if you create per-interface bindings or bind(2)
to INADDR_ANY.

If you create per-interface bindings and you create new network interface
BIND can't see it and use it (not sure if rndc reload/reconfig helps,
I haven't test it yet).

Adam

-- 
Adam Tkac, Red Hat, Inc.


More information about the bind-users mailing list