IPv4 control socket binding failure with BIND 9.9.4-P1 on RHEL6
Shumon Huque
shuque at upenn.edu
Thu Dec 5 17:57:32 UTC 2013
On 12/5/13 11:49 AM, Jay Ford wrote:
> I'm testing BIND 9.9.4-P1 on a RHEL6 system & am getting this log message:
>
> /etc/named.conf:56: couldn't add command channel 127.0.0.1#953:
> address in use
>
> That's with an rndc.key file in place & no "controls" config, which implies
> TCP 953 on 127.0.0.1 & ::1.
>
> Control via IPv6 (::1 port 953) works fine, but IPv4 doesn't:
> % netstat -an -A inet | fgrep :953
> % netstat -an -A inet6 | fgrep :953
> tcp 0 0 ::1:953 :::* LISTEN
>
> Even if I try to configure the controls to listen on a different port for
> IPv6, such as:
> controls {
> inet ::1 port 954 allow { localhost; };
> inet 127.0.0.1 allow { localhost; };
> };
> the IPv4 bind still fails, while the IPv6 bind works.
>
I'm going to take a guess: you might have portreserve running
that is reserving the control channel port, or v4 only because
they forgot about v6. We usually turn it off.
PORTRESERVE(1) TCP port reservation utility
PORTRESERVE(1)
NAME
portreserve - reserve ports to prevent portmap mapping them
SYNOPSIS
portreserve
DESCRIPTION
The portreserve program aims to help services with well-known ports
that lie in the bindresvport range. It prevents portmap (or other
programs using bindresvport) from occupying a real service?s port by
occupying it itself, until the real service tells it to release the
port (generally in its init script).
It is intended that portreserve runs from an initscript of its
own, and
services wishing to interact with it should use portrelease.
--Shumon.
More information about the bind-users
mailing list