Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
avoid-v4-udp-ports ineffective? (BIND 9.8.1-P1)
352 views
Skip to first unread message
Irwin Tillman
Nov 17, 2011, 11:00:56 AM11/17/11
to bind-...@lists.isc.org
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.
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.
Mark Andrews
Nov 17, 2011, 6:28:32 PM11/17/11
to Irwin Tillman, bind-...@isc.org
You machine *is* dual stacked even if it only has IPv6 on loopback.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
David Coulthart
Nov 17, 2011, 7:56:34 PM11/17/11
to Mark Andrews, bind-...@isc.org
$ /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
Mark Andrews
Nov 17, 2011, 8:07:43 PM11/17/11
to David Coulthart, bind-...@isc.org
In message <4B588336-2DE9-45BD...@columbia.edu>, David Coulthart writes:
> On Nov 17, 2011, at 6:28 PM, Mark Andrews wrote:
> Tillman writes:
> >> It appears that named is trying to use ports I've mentioned in =
> avoid-v4-udp-ports.
> >>=20
> >> Platform: BIND 9.8.1-P1 on Solaris 10 / SPARC
> >>=20
> >> On some of the ports which BIND might otherwise choose to use,=20
> >> 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:
> >>=20
> >> 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.
> >> };
> >>=20
> >> ...
> >> # 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:
> >>=20
> >> named[9185]: dispatch: warning: dispatch 42d950: open_socket(::#2049) =
> -> permission denied: continuing
> >> named[9185]: dispatch: warning: dispatch 42d950: open_socket(::#4045) =
> -> permission denied: continuing
> >>=20
> >> ...which suggests to me that BIND is trying to use ports I specified =
> in avoid-v4-udp-ports.
> >>=20
> >>=20
> >> 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 =
> >> while 9.7.3-P3 didn't log the warning. The warning is new.
> port to try again.=20
> >> So I don't know if the older version was also trying to use these =
> ports and encountering
> >> the same error.
> >>=20
> >> the same error.
> >> I imagine Solaris might return EACCESS because:
> >>=20
> >> % ndd /dev/udp udp_extra_priv_ports
> >> 2049=20
> >> 4045=20
> >>=20
> >>=20
> >> I don't understand why named would try to use these ports in the =
> first
> >> place as they appear in avoid-v4-udp-ports.
> >=20
> >> 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=20
>
> $ /sbin/ifconfig -a inet6
> lo0: flags=3D1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index =
> 1
> inet 127.0.0.1 netmask ff000000=20
> bge0: flags=3D1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 =
> index 2
> inet 128.59.59.92 netmask ffffff00 broadcast 128.59.59.255
> bge0:10: flags=3D1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 =
> inet 128.59.59.92 netmask ffffff00 broadcast 128.59.59.255
> 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 =
> inet 128.59.59.70 netmask ffffff00 broadcast 128.59.59.255
>
> 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.
A bound port gives a different error code when you attempt to bind
to it a second time and havn't set the right socket options. We
expect that error code. We also expect EPERM but log it.
Irwin Tillman
Nov 18, 2011, 2:11:32 PM11/18/11
to bind-...@lists.isc.org
I wrote:
> I don't understand why named would try to use these ports in the first
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.
Ah. Adding avoid-v6-udp-ports has indeed solved my issue.
Thank you.
(I'd assumed BIND wouldn't be trying to open IPv6 sockets since I'd not
configured any IPv6 interfaces on the host.
'/sbin/ifconfig -a inet6; /sbin/ifconfig -a inet' is showing
only IPv4 interfaces, not even a IPv6 loopback.)
> I don't understand why named would try to use these ports in the first
> place as they appear in avoid-v4-udp-ports.
Mark Andrews replied:
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.
Ah. Adding avoid-v6-udp-ports has indeed solved my issue.
Thank you.
(I'd assumed BIND wouldn't be trying to open IPv6 sockets since I'd not
configured any IPv6 interfaces on the host.
'/sbin/ifconfig -a inet6; /sbin/ifconfig -a inet' is showing
only IPv4 interfaces, not even a IPv6 loopback.)
0 new messages