• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Issue DNS requests are denied (allow-query-cache did not match) after upgrading from Debian 10 to 12

Hangover2

Regular Pleskian
Server operating system version
Debian 12.5
Plesk version and microupdate number
18.0.59 # 2
Hello,

after upgrading one of our older servers from Debian 10 to 12 the BIND domain name server does not answer to requests anymore.
For domains where the server is the primary name server requests end up like this:

Dig:
;; QUESTION SECTION:
;my-hosted-domain.com. IN A

Log:
named[38936]: client @[...]#50309 (my-hosted-domain.com): query (cache) 'my-hosted-domain.com/A/IN' denied (allow-query-cache did not match)

AppArmor looks good so far same as the bind configuration. But maybe we did miss sth.
Thanks in advance for any idea what's going on.
 
After digging deeper into our problem we did find the reason. "/etc/default/named" did not have the correct content (still default Debian 12).

After updating the file to the Plesk specific default settings the DNS is working like a charm again:
OPTIONS=" -t /var/named/run-root -c /etc/named.conf -u bind -n 2"

Maybe the Plesk team could add this info to a support article or even check this file as part of the Plesk repair utility (DNS check did not show up any problems either).
 
Same problem here, while upgrading from Ubuntu 18.04 to 20.04.
Thank you @Hangover2.

We only found this article here. Has an error report already been created?
 
I did not file a bug report because we later discovered that we had accidentally updated the configuration file, /etc/default/named , with the default Debian version during the upgrade process when prompted. Therefore, the fault was on our end. However, perhaps Plesk could include a check for this file in the Plesk repair utility for the DNS server.
 
Back
Top