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