On Nov 17, 2011, at 6:28 PM, Mark Andrews wrote:
> In message <201111171600.pahg0ucw011...@scramble.princeton.edu>, Irwin
> Tillman writes:
>> It appears that named is trying to use ports I've mentioned in
>> avoid-v4-udp-ports.
>>
>> Platform: BIND 9.8.1-P1 on Solaris 10 / SPARC
>>
>> On some of the ports which BIND might otherwise choose to use,
>> I have other daemons running and/or the OS treats the ports
>> as privileged. To keep named from trying to use those ports, I have
>> in named.conf:
>>
>> options {
>> ...
>> # there is no use-v4-udp-ports statement.
>> avoid-v4-udp-ports { 1812; 1813; 2049; 4045; };
>> # I don't speak v6.
>> };
>>
>> When I upgraded from BIND 9.7.3-P3 to 9.8.1-P1, I began seeing in the log:
>>
>> named[9185]: dispatch: warning: dispatch 42d950: open_socket(::#2049) ->
>> permission denied: continuing
>> named[9185]: dispatch: warning: dispatch 42d950: open_socket(::#4045) ->
>> permission denied: continuing
>>
>> ...which suggests to me that BIND is trying to use ports I specified in
>> avoid-v4-udp-ports.
>>
>>
>> Checking get_dispsocket() in ./lib/dns/dispatch.c, I see that a difference
>> between 9.7.3-P3 and 9.8.1-P1 is that 9.8.1-P1 logs a warning when an attempt
>> to open the socket returns ISC_R_NOPERM (perhaps the result of bind()
>> returning EACCESS ?),
>> while 9.7.3-P3 didn't log the warning. The warning is new.
>> When confronted with the error, both versions proceed to pick another port
>> to try again.
>> So I don't know if the older version was also trying to use these ports and
>> encountering
>> the same error.
>>
>> I imagine Solaris might return EACCESS because:
>>
>> % ndd /dev/udp udp_extra_priv_ports
>> 2049
>> 4045
>>
>>
>> I don't understand why named would try to use these ports in the first
>> place as they appear in avoid-v4-udp-ports.
>
> The "::" in the log message is the IPv6 equivalent of 0.0.0.0 in IPv4.
> You machine *is* dual stacked even if it only has IPv6 on loopback.
I noticed this same log message on our Solaris 9 servers and I don't see IPv6
enabled on any of our interfaces, including loopback:
$ /sbin/ifconfig -a inet6
$ /sbin/ifconfig -a inet
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
bge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 128.59.59.92 netmask ffffff00 broadcast 128.59.59.255
bge0:10: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 128.59.59.70 netmask ffffff00 broadcast 128.59.59.255
It's not a big deal for me as it doesn't happen very often (& can be easily
avoided by setting a matching avoid-v6-udp-ports), but it did surprise me.
Thanks Irwin for the tip on ndd. I had to avoid those exact same ports & I
couldn't find a process bound to port 2049 causing it.
--
Dave Coulthart
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
