[ntp:questions] Re: "Listen on" semantics

Danny Mayer mayer at ntp.isc.org
Fri Sep 15 04:06:32 UTC 2006

Luc Pardon wrote:
> Danny Mayer wrote:
>> Luc Pardon wrote:
>>>     In any case, it looks like it will always listen on and on
>>> the wildcard interface, there is no way to disable those.
>> Right. That was deliberate. You always want to listen on those addresses
>> as well as ::1 and ::. Is there and issue with that?
>    That depends on one's definition of "issue" <g>.
>    In my view it certainly does not meet the "principle of least
> surprise". It might be OK now because of the single -I limitation. But
> as soon as we can specify multiple addresses, if I want it to listen on
> I will tell it to. I mean, I would expect this to be "all or
> nothing": Either I let it use the defaults, or I take control. As it is
> now, it is a little bit of both and that is, well, surprising.

This is actually a bit more complicated than this. First let me explain
what the -I interface option really means. The code binds to all
available addresses on all interfaces irrespective of what options you
specify. What -I really does is specify to ONLY accept those packets
that arrive on that specific interface and it drops all packets arriving
on all other interface. It's still listening on those addresses. More on
this in a moment.

Since you are able to only specify one interface this way it is
important to be able to still listen on the loopback interface since you
usually want to keep this enabled. You can if you want specify the
loopback interface it it will only listen on that, not very useful.

If you don't want to wait and REALLY want to disable the loopback
interface you can just as effectively do that with restrict statements.
The main difference between the two methodologies is that the -I option
drops this right away while a restrict statement has to progress much
further into the code before dropping the packet.

Even when we allow you to specify multiple specific addresses or
interfaces the code will still bind to ALL addresses but drop any packet
arriving on an address you don't want.

>    There is also the issue of security. It is generally accepted as
> common sense that one should only install and run the services and open
> the ports that are absolutely needed.

Here we are ahead of you. By binding to all interfaces and addresses we
prevent other applications using them. The worst thing you can have is
two different applications modifying the clock. The results would be
totally unpredictable. Sometimes security involves doing more rather
than less. In addition restrict statements allow you to refine the types
of packets the server will accept and how it will respond and react to them.

>    You may argue that in this particular case it doesn't hurt, and you
> may or may not have a point. But from the "common sense" point of view
> that is irrelevant. The only question is: do I absolutely need it under
> all circumstances? If not, don't open it.

No, on the contrary, you MUST open all of them or it WILL hurt. If you
want to change the behavior in some way, use restrict statements. This
is unlike almost any other application server where it doesn't matter if
another application or a different instance of the same application
could run. Here it DOES matter.

My two shillings worth.


>    Just my 0.02 Euro.
>    Luc

More information about the questions mailing list