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