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 that's not quite an accurate statement. We don't actually use the
wildcard port for anything. All packets are sent and received on
specific interface addresses. The wildcard port is bound in order to
prevent more than one application running and setting the system clock
at the same time. It would cause havoc with the clock and the system.
There is also a need to use a specific IP address for sending and
receiving packets for the autokey security protocol to work, though that
would be doable with the advanced api and packet info.
> % netstat -na | grep 123
> udp4 0 0 127.0.0.3.123 *.*
> udp4 0 0 127.0.0.2.123 *.*
> udp4 0 0 10.53.0.7.123 *.*
> udp4 0 0 10.53.0.6.123 *.*
> udp4 0 0 10.53.0.5.123 *.*
> udp4 0 0 10.53.0.4.123 *.*
> udp4 0 0 10.53.0.3.123 *.*
> udp4 0 0 10.53.0.2.123 *.*
> udp4 0 0 10.53.0.1.123 *.*
> udp4 0 0 127.0.0.1.123 *.*
> udp6 0 0 fe80:4::1.123 *.*
> udp6 0 0 ::1.123 *.*
> udp6 0 0 fe80:2::216:6fff.123 *.*
> udp6 0 0 fe80:1::214:22ff.123 *.*
> udp6 0 0 *.123 *.*
> udp4 0 0 *.123 *.*
> %
>
> IPv6 and can use the advanced ipv6 api and packet info
> to make sure the response comes from the right address.
>
We have not done this yet in ntp as it would entail quite a lot of work
to implement correctly and we still have to worry about securing all of
the interfaces to prevent multiple applications from using the addresses
and causing lots of issues. There have been requests to not bind to all
IP addresses and I have implemented that as a non-default option but it
has not yet been released.
Danny
>> -RichardW.
>> --
>> Richard Wall
>> Support Engineer
>> ApplianSys Ltd
>> http://www.appliansys.com
>>
>> (t) +44 (0)24 7643 0094
>> (f) +44 (0)87 0762 7063
>> (e) [EMAIL PROTECTED]
