# Odd behaviour since bind update?

## hanj

Ever since I updated named to net-dns/bind-9.4.3_p4, I've been seeing the following in my logs every hour:

```
Dec  6 01:39:10 comp named[3198]: listening on IPv4 interface lo, 127.0.0.1#53

Dec  6 01:39:10 comp named[3198]: could not listen on UDP socket: permission denied

Dec  6 01:39:10 comp named[3198]: creating IPv4 interface lo failed; interface ignored

Dec  6 02:39:10 comp named[3198]: listening on IPv4 interface lo, 127.0.0.1#53

Dec  6 02:39:10 comp named[3198]: could not listen on UDP socket: permission denied

Dec  6 02:39:10 comp named[3198]: creating IPv4 interface lo failed; interface ignored

Dec  6 03:39:10 comp named[3198]: listening on IPv4 interface lo, 127.0.0.1#53

Dec  6 03:39:10 comp named[3198]: could not listen on UDP socket: permission denied

Dec  6 03:39:10 comp named[3198]: creating IPv4 interface lo failed; interface ignored

Dec  6 04:39:10 comp named[3198]: listening on IPv4 interface lo, 127.0.0.1#53

Dec  6 04:39:10 comp named[3198]: could not listen on UDP socket: permission denied

Dec  6 04:39:10 comp named[3198]: creating IPv4 interface lo failed; interface ignored

Dec  6 05:39:10 comp named[3198]: listening on IPv4 interface lo, 127.0.0.1#53

Dec  6 05:39:10 comp named[3198]: could not listen on UDP socket: permission denied

Dec  6 05:39:10 comp named[3198]: creating IPv4 interface lo failed; interface ignored

Dec  6 06:39:10 comp named[3198]: listening on IPv4 interface lo, 127.0.0.1#53

Dec  6 06:39:10 comp named[3198]: could not listen on UDP socket: permission denied

Dec  6 06:39:10 comp named[3198]: creating IPv4 interface lo failed; interface ignored

Dec  6 07:39:10 comp named[3198]: listening on IPv4 interface lo, 127.0.0.1#53

Dec  6 07:39:10 comp named[3198]: could not listen on UDP socket: permission denied

Dec  6 07:39:10 comp named[3198]: creating IPv4 interface lo failed; interface ignored

Dec  6 08:39:10 comp named[3198]: listening on IPv4 interface lo, 127.0.0.1#53

Dec  6 08:39:10 comp named[3198]: could not listen on UDP socket: permission denied

Dec  6 08:39:10 comp named[3198]: creating IPv4 interface lo failed; interface ignored

Dec  6 09:39:10 comp named[3198]: listening on IPv4 interface lo, 127.0.0.1#53

Dec  6 09:39:10 comp named[3198]: could not listen on UDP socket: permission denied

Dec  6 09:39:10 comp named[3198]: creating IPv4 interface lo failed; interface ignored
```

This is happening to only one of my two DNS servers? Anyone else noticing this? Any suggestions on how to correct it? Let me know if you need any more information.

Thanks!

hanji

----------

## causality

TCP and UDP ports range from 1 to 65,535.  On Unix and Unix-like systems, all ports in the range of 1-1024 are privileged.  Only the root user can bind to those ports (that is, listen for incoming traffic).  The purpose of this is to prevent normal users from interfering with the system services that use those lower port numbers.

It looks to me like you have configured BIND to run as a non-root user for security purposes.  When it listens on localhost, this is not nearly so important as when it's actually accepting remote traffic, but running non-root is still a very good idea and conforms to the sound principle of least-privilege.  The benefit is that if someone should compromise the DNS server, it won't automatically give them full control of your machine.  Typically, this is arranged by initially running BIND as root so it can bind (no pun intended) to the privileged port 53.  Upon binding to that port, BIND will then drop its root privileges and at that point it will be a normal, unprivileged user.  

I wonder if BIND is being initially run as a normal user and is never root for even a moment.  That would certainly cause the kind of error you are receiving.  I think the place to begin checking this is the initscript, which is definitely located in /etc/init.d/ and is probably located at /etc/init.d/bind.  Sorry I don't know for sure where it is because I don't use BIND myself.  That initscript probably uses start-stop-daemon to launch the BIND executable and the paramaters to that would be one thing to check.  Next would be BIND's config files as they probably have an entry stating which user it should run as.

----------

## hanj

Hello

Thanks for the reply. I am running a named chroot'd, which might be the problem, but curious why it's able to bind to the other interfaces on UDP:53 without a problem? It's just having trouble on 127.0.0.1

hanji

----------

## causality

That's interesting.  I think the general practice is to bind it to either localhost or the network interface but not both.  I wonder if the cause of the error could be that simple.

Binding to both is not really needed anyway.  Usually the purpose of binding to localhost is to prevent it from listening for remote network traffic.  In situations where you only want a local server, not listening for network traffic means one less thing to worry about from a security standpoint.  If you are going to let it listen for remote traffic anyway (like my setup where my DNS server is serving 3 computers) then the purpose of binding to localhost is nullified.  This isn't specific to BIND at all but is more of a general principle.

To make up an example, let's say my computer is on LAN behind a NAT router.  It's IP is 192.168.1.5.  In my BIND config file, I would tell it to listen on 192.168.1.5 port 53.  My computer (the same one running the BIND server) can always use "nameserver 192.168.1.5" in its /etc/resolv.conf file and it will work just fine even though it's the same computer.  Of course other computers on the LAN can also use "nameserver 192.168.1.5" to communicate with the BIND daemon over the LAN.  In my case, listening on localhost would be redundant and (if I haven't made too many assumptions) I think your situation is like this.

----------

## doctork

 *causality wrote:*   

> That's interesting.  I think the general practice is to bind it to either localhost or the network interface but not both.  I wonder if the cause of the error could be that simple.
> 
> Binding to both is not really needed anyway.  Usually the purpose of binding to localhost is to prevent it from listening for remote network traffic.  In situations where you only want a local server, not listening for network traffic means one less thing to worry about from a security standpoint.  If you are going to let it listen for remote traffic anyway (like my setup where my DNS server is serving 3 computers) then the purpose of binding to localhost is nullified.  This isn't specific to BIND at all but is more of a general principle.
> 
> To make up an example, let's say my computer is on LAN behind a NAT router.  It's IP is 192.168.1.5.  In my BIND config file, I would tell it to listen on 192.168.1.5 port 53.  My computer (the same one running the BIND server) can always use "nameserver 192.168.1.5" in its /etc/resolv.conf file and it will work just fine even though it's the same computer.  Of course other computers on the LAN can also use "nameserver 192.168.1.5" to communicate with the BIND daemon over the LAN.  In my case, listening on localhost would be redundant and (if I haven't made too many assumptions) I think your situation is like this.

 

Well, not really!  I have one DNS server that is available to systems on my LAN as well as to itself.  I consider that to be more the general practice than what's said in the post above.  To that end, I have this in my /etc/bind/named.conf:

```
        listen-on { 127.0.0.1; 172.20.31.74; };
```

 I am also running named chroot'd to named.  I'm currently using version 9.6.1_p2, but have used the same configs through several versions of bind and have never had a problem.

--

doc

----------

## hanj

Interesting? I just specified the IP/interface that I wanted it to listen-on (excluding lo) and restarted named, and all is better now. I had nothing specified originally, so it was trying to listen on all interfaces. The other odd thing, my secondary nameserver is configured the same as this one (originally), and is not showing this warning on 127.0.0.1#53?

Thanks!

hanji

----------

## doctork

 *hanj wrote:*   

> Interesting? I just specified the IP/interface that I wanted it to listen-on (excluding lo) and restarted named, and all is better now. I had nothing specified originally, so it was trying to listen on all interfaces. The other odd thing, my secondary nameserver is configured the same as this one (originally), and is not showing this warning on 127.0.0.1#53?
> 
> Thanks!
> 
> hanji

 

Odd indeed.  It would be interesting to see the output of (run as root)

```
netstat -nlp | grep named

and

dig @127.0.0.1 forums.gentoo.org

```

--

doc

----------

