Luc Pardon wrote: > > > Danny Mayer wrote: >> Luc Pardon wrote: >>> >>> In any case, it looks like it will always listen on 127.0.0.1 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 > 127.0.0.1 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. Danny > Just my 0.02 Euro. > > Luc _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
