On Wed, Oct 01, 2008 at 11:28:25AM +1000, Mark Andrews wrote:
> 
> In message <[EMAIL PROTECTED]>, "Rich
> ard Wall" writes:
> > 2008/9/30 Mark Andrews <[EMAIL PROTECTED]>:
> > > In message <[EMAIL PROTECTED]>, "
> > 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.

Reply via email to