• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Forwarded to devs DNS - order of records unreliable and thus primary master name server in SOA broken

ChristophRo

Regular Pleskian
TITLE:
DNS - order of records unreliable and thus primary master name server in SOA broken
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:
Plesk 9.0 - 17.8, Debian 6-9, Ubuntu 12-16, x64
PROBLEM DESCRIPTION:
Plesk (still) does not have a proper way to configure the primary master name server in the SOA records and relies on some ubscure and random way of choosing one of the configured NS records for that.
This does lead to non RFC conform dns zones and even nonsyncronous or missing zones on the secondary nameserver(s)
STEPS TO REPRODUCE:
1) make sure the DNS template is fine and records have correct order (was a pro tip from plesk support back in the days)
plesk_bogusdns_01.png

2) create a new domain and check its DNS settings - order of records is completely random, but at least SOA is correct (but not always!)
plesk_bogusdns_02.png

3) add a DNS record to this zone and observe the primary name server change in SOA
plesk_bogusdns_03.png




A) Using the "Reset to Default" button does fix that, i.e. it does properly order the records and adding/deleting records in the furture does not mess with the primary name server in the SOA.

B) Using the "Apply DNS Template" button does break that, i.e. will re-order the records randomly and break the SOA again, if not instant then the next time a record is added or deleted on this domain
ACTUAL RESULT:
Broken SOA record in zonefile, leading to troubles (i.e. unable to transfer zone data) with secondary DNS
EXPECTED RESULT:
a) a proper way to configure the primary name server in the SOA

b) a reliable way to configure the panel so it always uses the same and correct NS records as source for the name server in the SOA
ANY ADDITIONAL INFORMATION:
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:
Confirm bug
 
What version and architecture are you actually using?

This was a bug back in Plesk 12 I believe, I can't replicate it in Onyx.
 
many, but just did test and re-verify the problem right now on the following systems:

- Plesk 17.8.11 Update #2 on Debian 9.4‬, x64
- Plesk 12.5.30 Update #74 on ‪Ubuntu 14.04.5 LTS‬, x64
- Plesk 17.5.3 Update #43 on ‪Debian 8.10‬, x64
- Plesk 17.5.3 Update #43 on Ubuntu 16.04.4 LTS, x64
 
Last edited:
Just installed a fresh Plesk 17.8 on a Centos7
Same problem, completely unreliable and uncontrollable behaviour when it comes to the primary name server in the SOA record.

Another way to reproduce this botched behaviour on a fresh server without any custom config applied:

1) create domain
2) check it's SOA just to see that everything is fine and master DNS is ns1.<domain>.
3) open "Tools & Settings" --> "DNS Template", click on the first record (<domain>. NS ns1.<domain>), but do not change anything, just click OK.
4) click the "apply the changes to the existing domains"
5) check SOA again and observe how master DNS changed to ns2.<domain>.
 
Last edited:
ChristophRo, can you provide more details regarding statement:
>Broken SOA record in zonefile, leading to troubles (i.e. unable to transfer zone data) with secondary DNS
which scenarios are broken due such behavior (this behavior is actual at least since Plesk 7)
 
We use PowerDNS based slave servers for multiple (100+) primary nameservers, consisting of various systems, i.e. Bind, PowerDNS, Microsoft DNS, etc.
And they do not accept a domain, when the primary master server in the SOA is bogus, i.e points to themself

Code:
Apr  3 08:06:23 ns3 pdns[27190]: Received NOTIFY for aaaaatest.com from 2001:8e0:41:604::173 for which we are not authoritative
Apr  3 08:06:23 ns3 pdns[27190]: Received NOTIFY for aaaaatest.com from 212.25.26.173 for which we are not authoritative
Apr  3 08:06:23 ns3 pdns[27190]: Unable to find backend willing to host aaaaatest.com for potential supermaster 2001:8e0:41:604::173. 3 remote nameservers:
Apr  3 08:06:24 ns3 pdns[27190]: Created new slave zone 'aaaaatest.com' from supermaster 212.25.26.173
Apr  3 08:06:27 ns3 pdns[27190]: While checking domain freshness: Query to '212.25.8.162:53' for SOA of 'aaaaaatest.com' produced no results (RCode: Query Refused)
Apr  3 08:06:27 ns3 pdns[27190]: Received NOTIFY for aaaaatest.com from 2001:8e0:41:604::173 which is not a master
Apr  3 08:06:30 ns3 pdns[27190]: Domain 'aaaaatest.com' is stale, master serial 2018040303, our serial 0
Apr  3 08:06:30 ns3 pdns[27190]: Initiating transfer of 'aaaaatest.com' from remote '212.25.26.173'
Apr  3 08:06:30 ns3 pdns[27190]: Domain 'aaaaatest.com' is stale, master serial 2018040303, our serial 0
Apr  3 08:06:31 ns3 pdns[27190]: AXFR started for 'aaaaatest.com'
Apr  3 08:06:31 ns3 pdns[27190]: Transaction started for 'aaaaatest.com'
Apr  3 08:06:31 ns3 pdns[27190]: AXFR done for 'aaaaatest.com', zone committed with serial number 2018040303
Apr  3 08:06:31 ns3 pdns[27190]: Initiating transfer of 'aaaaatest.com' from remote '212.25.26.173'
Apr  3 08:06:31 ns3 pdns[27190]: AXFR started for 'aaaaatest.com'
Apr  3 08:06:31 ns3 pdns[27190]: Transaction started for 'aaaaatest.com'
Apr  3 08:06:31 ns3 pdns[27190]: AXFR done for 'aaaaatest.com', zone committed with serial number 2018040303
Apr  3 08:06:33 ns3 pdns[27190]: While checking domain freshness: Query to '212.25.8.162:53' for SOA of 'aaaaaatest.com' produced no results (RCode: Query Refused)
Apr  3 08:17:16 ns3 pdns[27190]: AXFR of domain 'aaaaatest.com' initiated by 2001:8e0:40:2::197
Apr  3 08:17:16 ns3 pdns[27190]: AXFR of domain 'aaaaatest.com' failed: not authoritative
Apr  3 08:19:30 ns3 pdns[27190]: AXFR of domain 'aaaaatest.com' initiated by 2001:8e0:40:2::197
Apr  3 08:19:30 ns3 pdns[27190]: AXFR of domain 'aaaaatest.com' failed: not authoritative

When the primary master server in the SOA is correct initially but changes afterwards (cause we add a record and plesks reorders the nameserver), the zone that got created on the secondary DNS, but will then get deleted after 7 days. (default expire time, configured in the SOA)


So in the end we have domains, that only live on the master nameserver (the Plesk server) and not the secondary DNS - but of course all two/three nameservers are set at th e registry for that domain.
This will cause clients to randomly get the servefail error when performing DNS querys, depending on which nameserver they use.
 
Hi,

The bug was fixed in Plesk Obsidian Preview (8 May 2019), Change Log for Plesk.
[+] It is now possible to select which NS record will be set as a primary name server in the Plesk interface. It can be done using SOA record, for DNS Template - SOA record template.

PPP-14761.png
 
Back
Top