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!

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)
ondrej@sury.org