Bind named to 0.0.0.0 (INADDR_ANY)

Danny Mayer mayer at ntp.isc.org
Wed Oct 1 15:03:27 UTC 2008


Adam Tkac wrote:
> 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).
> 

BIND9 has no problem with seeing new interfaces. You don't need rndc for
that, it's quite automatic. You can use interface-interval to adjust the
frequency of the checking.

Danny

> Adam
> 



More information about the bind-users mailing list