Your message dated Wed, 6 Jul 2022 07:41:15 +0200 with message-id <[email protected]> and subject line Re: bind9: named periodically logs large number of "error sending response: permission denied" lines has caused the Debian Bug report #897139, regarding bind9: named periodically logs large number of "error sending response: permission denied" lines to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 897139: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897139 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: bind9 Version: 1:9.11.3+dfsg-1 Severity: normal Dear Maintainer, Periodically, I see large number of "permission denied" log lines showing up in various logs: Apr 28 15:07:22 fidelity named[879]: client @0xb23daa80 10.0.5.255#61981 (gs-loc.apple.com): error sending response: permission denied Apr 28 15:07:23 fidelity named[879]: client @0xb313a730 10.0.5.255#61981 (gs-loc.apple.com): error sending response: permission denied Apr 28 15:07:25 fidelity named[879]: client @0xb2318e40 10.0.5.255#61981 (gs-loc.apple.com): error sending response: permission denied Apr 28 15:07:29 fidelity named[879]: client @0xb075cb10 10.0.5.255#61981 (gs-loc.apple.com): error sending response: permission denied Apr 28 15:07:35 fidelity named[879]: client @0xb0754d40 10.0.5.255#55290 (p31-fmip.icloud.com): error sending response: permission denied Apr 28 15:07:37 fidelity named[879]: client @0xb1d94c80 10.0.5.255#61981 (gs-loc.apple.com): error sending response: permission denied Apr 28 15:08:07 fidelity named[879]: client @0xb1d431f0 10.0.5.255#51460 (p31-fmip.icloud.com): error sending response: permission denied Apr 28 15:08:08 fidelity named[879]: client @0xb1d431f0 10.0.5.255#51460 (p31-fmip.icloud.com): error sending response: permission denied Apr 28 15:08:10 fidelity named[879]: client @0xb1d431f0 10.0.5.255#51460 (p31-fmip.icloud.com): error sending response: permission denied Apr 28 15:08:14 fidelity named[879]: client @0xb1d431f0 10.0.5.255#51460 (p31-fmip.icloud.com): error sending response: permission denied Apr 28 15:08:38 fidelity named[879]: client @0xb1d6c430 10.0.5.255#51460 (p31-fmip.icloud.com): error sending response: permission denied Apr 28 15:08:47 fidelity named[879]: client @0xb237dab0 10.0.5.255#50319 (www.icloud.com): error sending response: permission denied Apr 28 15:08:47 fidelity named[879]: client @0xb23e0a60 10.0.5.255#56916 (apple.com): error sending response: permission denied It doesn't seem to negatively impact named's ability to function. It started happening around April 9th, 2018 but I had not done any significant upgrades around that time. (I upgraded the bind9 package on March 28). I can resolve the relevant domains listed above with no difficulty. When I review the last month's worth of the data, they appear to be centered around Apple domains. Here's a breakdown from a representative day: 61 (init-p01st.push.apple.com): 54 (www.icloud.com): 54 (apple.com): 45 (gs-loc.apple.com): 41 (push.apple.com): 16 (mesu.apple.com): 14 (p31-fmip.icloud.com): Happy to run more diagnostics on my side. thank you! -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.15.0-2-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bind9 depends on: ii adduser 3.117 ii bind9utils 1:9.11.3+dfsg-1 ii debconf [debconf-2.0] 1.5.66 ii libbind9-160 1:9.11.3+dfsg-1 ii libc6 2.27-2 ii libcap2 1:2.25-1.2 ii libcom-err2 1.44.0-1 ii libdns1100 1:9.11.3+dfsg-1 ii libgeoip1 1.6.12-1 ii libgssapi-krb5-2 1.16-2 ii libisc169 1:9.11.3+dfsg-1 ii libisccc160 1:9.11.3+dfsg-1 ii libisccfg160 1:9.11.3+dfsg-1 ii libjson-c3 0.12.1-1.3 ii libk5crypto3 1.16-2 ii libkrb5-3 1.16-2 ii liblmdb0 0.9.21-1 ii liblwres160 1:9.11.3+dfsg-1 ii libssl1.1 1.1.0g-2 ii libxml2 2.9.4+dfsg1-6.1 ii lsb-base 9.20170808 ii net-tools 1.60+git20161116.90da8a0-2 ii netbase 5.4 bind9 recommends no packages. Versions of packages bind9 suggests: pn bind9-doc <none> ii dnsutils 1:9.11.3+dfsg-1 pn resolvconf <none> pn ufw <none> -- Configuration Files: /etc/apparmor.d/local/usr.sbin.named changed [not included] /etc/bind/db.local changed [not included] /etc/bind/named.conf.local changed [not included] /etc/bind/named.conf.options changed [not included] -- debconf information: bind9/different-configuration-file: bind9/start-as-user: bind bind9/run-resolvconf: true
--- End Message ---
--- Begin Message ---See man send: ERRORS These are some standard errors generated by the socket layer. Additional errors may be generated and returned from the underlying protocol modules; see their respective manual pages. EACCES (For UNIX domain sockets, which are identified by pathname) Write permission is denied on the destination socket file, or search permission is denied for one of the directories the path prefix. (See path_resolution(7).) (For UDP sockets) An attempt was made to send to a network/broadcast address as though it was a unicast address. Apr 28 15:07:22 fidelity named[879]: client @0xb23daa80 10.0.5.255#61981 (gs-loc.apple.com): error sending response: permission denied 10.0.5.255 is a broadcast address in /24 network, so I think this is the culprit here, not BIND 9. Closing the issue. Ondrej -- Ondřej Surý (He/Him) [email protected]
--- End Message ---
