probing sendmsg() with IPV6_TCLASS=b8 failed: Permission denied

PMc

PMc

Code: 
Apr 24 22:01:01 pole named[2169]: running as: named -n 1 -4 -t /var/named -u bind -c /usr/local/etc/namedb/named.conf
Apr 24 22:01:01 pole named[2169]: compiled by CLANG FreeBSD Clang 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
Apr 24 22:01:01 pole named[2169]: compiled with OpenSSL version: OpenSSL 1.1.1h-freebsd  22 Sep 2020
Apr 24 22:01:01 pole named[2169]: linked to OpenSSL version: OpenSSL 1.1.1h-freebsd  22 Sep 2020
Apr 24 22:01:01 pole named[2169]: compiled with libxml2 version: 2.9.10
Apr 24 22:01:01 pole named[2169]: linked to libxml2 version: 20910
Apr 24 22:01:01 pole named[2169]: compiled with zlib version: 1.2.11
Apr 24 22:01:01 pole named[2169]: linked to zlib version: 1.2.11
Apr 24 22:01:01 pole named[2169]: ----------------------------------------------------
Apr 24 22:01:01 pole named[2169]: BIND 9 is maintained by Internet Systems Consortium,
Apr 24 22:01:01 pole named[2169]: Inc. (ISC), a non-profit 501(c)(3) public-benefit 
Apr 24 22:01:01 pole named[2169]: corporation.  Support and training for BIND 9 are 
Apr 24 22:01:01 pole named[2169]: available at https://www.isc.org/support
Apr 24 22:01:01 pole named[2169]: ----------------------------------------------------
Apr 24 22:01:01 pole named[2169]: net.c:536: unexpected error:
Apr 24 22:01:01 pole named[2169]: probing sendmsg() with IPV6_TCLASS=b8 failed: Permission denied

Ever seen this one, anybody? The thing shouldn't even use IPv6!
 
SirDice said:
Did you build a kernel without INET6?
Click to expand...
Not to my knowledge - I just copied GENERIC and did not yet find time to change anything there (system will be replaced anyway). Lets see:
$ strings kernel | grep "options.*INET6"
options INET6

Strangely, on another system with one of my locally hand-crafted kernelconfigs ;) the error does *not* appear. These also have INET6 active (and then everything concerning ipv6 switched off). The bind config is also respectively identical.

It is difficult to find out what this IPV6_TCLASS actually is or does. It seems to have something to do with quality-of-service. Then, what permission do you need to use ipv6 qos, and who would normally grant such permission?
 
To be honest I have no idea what IPV6_TCLASS does, but the INET6 option seemed obvious, I've seen some people remove it from the kernel configuration. Which would then cause problems if applications try to do anything with IPv6.

I have BIND 9.16 running at home on a dual stack (IPv4 and IPv6) and one at work that only runs on IPv4. Both are the same application built with the same options enabled/disabled, but obviously have a few different configurations set. I'd take a closer look at named.conf and see if there's anything referring to IPv6. It's fine if it hosts IPv6 addresses, you can query those fine over IPv4 but would be somewhat unnecessary if you only have IPv4 on your network.
 
Had to reboot the server at work (updates) anyway, so I had a chance to look at the output of BIND starting up. This should appear where you're getting an error:
Code: 
Apr 28 14:55:03 p1.example.com named[624]: statistics channel listening on 127.0.0.1#8053
Apr 28 14:55:04 p1.example.com named[624]: command channel listening on 127.0.0.1#953
Apr 28 14:55:04 p1.example.com named[624]: command channel listening on ::1#953
So I'd take a look at the settings regarding statistics (I have those enabled, it may not for you) and the command channels. You'll notice it does try to open a command channel on ::1 even though this machine doesn't have IPv6. It should still be enabled on lo0 though, just not on any external interfaces. Perhaps you turned IPv6 off there.
 
  • Thanks
Reactions: PMc
Okay, that figures. Normally I don't get that message:
Code: 
Apr 11 20:03:27 <daemon.notice> conn named[4153]: BIND 9 is maintained by Internet Systems Consortium,
Apr 11 20:03:27 <daemon.notice> conn named[4153]: Inc. (ISC), a non-profit 501(c)(3) public-benefit 
Apr 11 20:03:27 <daemon.notice> conn named[4153]: corporation.  Support and trining for BIND 9 are 
Apr 11 20:03:27 <daemon.notice> conn named[4153]: available at https://www.isc.org/support
Apr 11 20:03:27 <daemon.notice> conn named[4153]: ----------------------------------------------------
Apr 11 20:03:28 <daemon.notice> conn named[4153]: command channel listening on 127.0.0.1#953
Apr 11 20:03:29 <local0.notice> conn named[4153]: general: notice: all zones loaded
Apr 11 20:03:29 <local0.notice> conn named[4153]: general: notice: running

But on the machine in question I find this:
Code: 
Apr 24 22:01:01 pole kernel: ipfw: 2595 Unreach 13 UDP [::1]:13851 [::1]:13851 out via lo0
Which is normal, because my ipfw scriptsets are not (yet) supporting ipv6 - so there is none, not even for lo0. And which perfectly explains the error message.

Thanks a lot! :)
 
You can probably bind that control channel to 127.0.0.1 alone with this:
Code: 
controls {
        inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
Then it shouldn't attempt to bind to ::1 any more.

But I see no harm in allowing ::1 it's basically the IPv6 equivalent of 127.0.0.1 and shouldn't go anywhere except to the machine itself.
 
SirDice said:
But I see no harm in allowing ::1 it's basically the IPv6 equivalent of 127.0.0.1 and shouldn't go anywhere except to the machine itself.
Click to expand...
Well, there was harm. Its a longer story. I had the problem that the named would not start quickly, it would always delay 90 seconds on startup - during which, according to truss, it repeatedly tries to talk to itself and get 'connection refused' (probably not due to the firewall, there's no logging there). Which means, the server would delay boot for 90 seconds, because I don't want to proceed without nameserver.
Removing 127.0.0.1 from the listening addresses solved the issue, but only when starting with -4. Otherwise it would do the delay game on ::1.
Surely this should be fully analyzed and understood and corrected (might be jail related), but then I left it as is and postponed the issue until when I will finally tackle ipv6.

Later I copied that working config to another machine. Only that other machine is not a jail, and there named works only on 127.0.0.1 as a forwarder. There was not so much delay and it seemed to work fine, until I recently discovered this error message and didn't understand it.

So it seems to me all this will occasionally need a serious workout for proper understanding, probably alongside with fully implementing ipv6.
 
That control connection is used by rndc(8), which is used to freeze, unfreeze, reload, etc. It can also be used in combination with DHCP for example to automatically register DHCP hosts in DNS. rndc(8) needs a key, that key is also configured in named.conf, if those keys don't match it will fail to connect, perhaps that's what you're seeing?
 
SirDice said:
That control connection is used by rndc(8), which is used to freeze, unfreeze, reload, etc. It can also be used in combination with DHCP for example to automatically register DHCP hosts in DNS. rndc(8) needs a key, that key is also configured in named.conf, if those keys don't match it will fail to connect, perhaps that's what you're seeing?
Click to expand...
That one is implicitely used for service named reload, and that works. That should use the rndc.key that is created by the install script - I never had to bother with that.
For dynamic updates I use nsupdate with tkey-gssapi auth. So there is a bunch of potential hen&egg issues lingerling (Kerberos depends on the DNS) that need to be carefully observed.
(And it seems, only few people are doing this - it does not work out of the box: the gssapi libs must be copied into the chroot, otherwise, after sytem upgrade, no DNS.)
 
You must log in or register to reply here.
Back
Top