• 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.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

SOA-record set to secondary DNS

Frater

Regular Pleskian
According to http://kb.odin.com/en/1229
The SOA-record is set to the first NS-record set in Plesk.

I have noticed that new domains get my secondary DNS set as SOA.

I checked the DNS-template and there the correct nameserver is on top.
Maybe the NS-record order is random or always swapped. I just noticed this.

I do know it's giving me a lot of work by having to switch these manually.

If it's always swapped then I could give the authorative NS last in my template...

But why isn't it giving itself as authorative?
If Plesk is configured as master it also implies this, or am I missing something there?
It could at least make sure it puts itself first.
 
Last edited:
I just added some new domains and am getting frustrated by this.
I already changed the order in my template hoping it would give me a reverse order of the NS-records in the actual DNS zone, but it didn't
The quickest way for me now is to leave that 2nd NS out of the template and add it manually when creating a domain on the server.
This needs the least handling for now...
It also gives room for error, because I need to add that 2nd NS-server each time.

Can we get a proper solution for this???
I have yet to receive an answer from Parallels
 
There is following behaviour. NS which was modified last will be used for SOA record. So, just go to DNS template, select ns2 and click OK. This ns will be used for SOA record.
 
I first tried that with the template and that didn't work.
Not even if I deleted the record I want as SOA and add it again.

A newly created domain would still have the domain I don't want as SOA.

Maybe it only works if one lets the template change all domains that are created with that template.
So, I tried the same with the already created domain and that didn't work either....

It still sounds as a dubious mechanism...
I don't understand why it would not use itself as the SOA-record.
The server knows it is the authorative server, so why not have that in its SOA-record?
 
Hi Frater,
Do you mean "local" NS should be used for SOA in case of several NS records exists?
 
I have given a name to my Plesk server and this name corresponds with one of the 2 NS-records.

But it can be more robust than that. Plesk could resolve all NS-records and then check which one is local. That record should go into the SOA-record.

A radio button that comes with all the NS-records would be a solution. As long as it's possible to do that on the template as well.

For now I have only one NS-record in my template. After creating the domain I will add the secondary. That way I have worked around it.
 
Really... this one is driving me nuts...

Did a fresh install last weekend and migrated over 40 customers - and no matter what I try - it seems to be impossible to configure the
DNS-Template to set the correct soa. The only workaround I found is to open the DNS-settings for a domain, remove all secondary nameservers,
allpy the settings and then add the secondary nameservers again. But I can't do that for hundreds of domains!

Dear Plesk guys - please add an option where I can choose the soa. Maybe a checkbox telling 'use this nameserver as SOA' when adding
nameservers.

Best regards,

Oliver Meyer
 
Last edited:
Ah... Someone else suffering the same thing.
I don't understand why not more are having problems with this.
They don't notice, probably..

Given suggestions don't work.

I think it's not that difficult. Plesk should put itself into the SOA-record. Being able to change the DNS-records implies authority (if it's properly configured)
 
It is a bit more complicated than that! namservers in the template are not necessarily local. Maybe it would be better to add an option to tick a box to say "this is my primary ns record" (which then goes in the SOA) or something like that?
 
It is a bit more complicated than that! namservers in the template are not necessarily local. Maybe it would be better to add an option to tick a box to say "this is my primary ns record" (which then goes in the SOA) or something like that?
Maybe it is. I couldn't think of any scenario that wasn't.
Could you explain such a scenario where you are using Plesk to set the records and another server is authoritative?

If you are changing the DNS-records on that server why would that server be anything but the authoritative server?

The script that creates the SOA-record only has to check the IP's of the NS-record and if one of the NS-records is matching that IP it should use that one instead of the first (which it is using now).

I'm using this method in a script where I check all DNS-records to check if there aren't any orphan domains.

Even if Faris comes up with a scenario I presume it will be an unlikely one (i can't say that yet, really).

Anyhow it would be an improvement over this one.
 
When is this getting some attention?
It doesn't have to be fixed immediately, but a comment or a recognition of the problem is a good start.
 
Let me clarify a little bit.

We use value of NS record of corresponding zone for for SOA record. If there are several NS records, they are sorted by timestamp and after that by id. I.e. NS record with earliest timestamp will be used. But if timestamp is equal for several NS records - record with less id will be used in SOA record.

If the zone is turned off, or NS-records are absent in zone, we use the name of zone as SOA-record.

When creating DNS zone all records get the same timestamp with a fairly high probability because it is measured in seconds. ID of record depends on the order in which they are created, and this order depends on the order of extraction records of zone template from database. When extracting records of zone template from database we do not specify an explicit sorting. Therefore, in theory, records may be returned in any order. In practice, this procedure is generally similar to the order in which the records of zone template were created, but this is no guarantee.

When you synchronize an existing zone, it is more complicated...

In general, manage SOA-record by editing the a template zone is impossible.

As possible solution you can write script for extracting NS records from zones and update them with dns CLI utility for changing timestamp for record which mustn't be in SOA record.

If you need possibility to define needed NS in SOA record through Plesk interface - please submit corresponding feature request here http://plesk.uservoice.com
 
I think most Plesk users are not aware their SOA-record does not represent their authoritative server. I never was.
This until I wrote a script to check if the DNS config of the Plesk server represented the real world....
Orphans on the server can be confusing when troubleshooting and it's good to check if the slave server is responding and also has the same serial in the SOA-record as the authorative server.

In this script I'm resolving the NS-records and check them with the IP's the server is having to determine which NS-record is authoritative.
Last year I was using this script regularly and it enabled me to keep a clean config.

This script was not written for this bug, but it made me discover it.

After I upgraded to Plesk 12 many, but not all domains had their SOA-record changed to the slave server.

It still is changing the SOA-records of old domains for no apparent reason from time to time!

I corrected this, but what I was never able to fix was the creation of new domains.
They always had the slave server as SOA-record.
In the end I just removed the NS-record of this slave server from the DNS-template and now I have to manually add that NS-record after creating a new domain.

Having this random behaviour in Plesk is quite a nuisance and it's beyond me why "my approach" is not used for creating the SOA-record.
Having your Plesk server as a "Master server" implies that the server is authoritative.
Why not use thát as the best guess for the SOA-record

Here's the quick-and-dirty script I wrote. It was intended for internal use and it helped me get the job done:

# cat /usr/local/sbin/dnsconfigcheck
Code:
#!/bin/bash
# Author: JP van Melis

ZONEFILE="$1"

NAMED_CONF=/etc/named.conf
CACHING_DNS=8.8.8.8

ZONES=`mktemp`
THIS_SERVER_A=`mktemp`
THIS_SERVER_IP=`mktemp`
IP_SOA=`mktemp`
IP_AUTH=`mktemp`

# get this server's IP's
ifconfig | egrep -o 'inet( | addr:)[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | tr -cd '0-9.\n' >${THIS_SERVER_IP}

# extract domain names from named.conf or given file
if [ -z "${ZONEFILE}" ] || [ ! -f "${ZONEFILE}" ] ; then
  egrep -o '^zone \"[a-z0-9-]+\.[a-z]+\"' ${NAMED_CONF} | awk '{print $2}' | tr -d '"' >${ZONES}
else
  egrep -o '[a-z0-9-]+\.[a-z]+' ${ZONEFILE} >${ZONES}
fi
sed -i '/^domain.com$/d' ${ZONES}
# Parse all the domains
while read ZONE ; do
  echo -en "${ZONE}                    \r"

  # Get SOA-record
  SOA=`host -t SOA ${ZONE} ${CACHING_DNS} 2>/dev/null | egrep -o 'has SOA record [A-Za-z0-9.-]+' | awk '{print $4}'`

  if [ -z ${SOA} ] ; then
    echo "${ZONE}:" | awk '{ printf("%-35s",$0)}'
    echo "has no SOA-record (according to ${CACHING_DNS})"
  else
    IT_IS_ME=
    if ! grep -q ${ZONE} ${THIS_SERVER_A} ; then
      # Collect all the IP's of that SOA-record
      host -t A ${SOA} ${CACHING_DNS} 2>/dev/null | egrep -o 'has address [0-9.]+'| awk '{print $3}' >${IP_SOA}
      while read IP ; do
        # Check if the SOA-record points to one of my IP-addresses
        if grep -q "^${IP}$" ${THIS_SERVER_IP} ; then
          IT_IS_ME=${IP}
          echo "${ZONE}" >>${THIS_SERVER_A}
          break
        fi
      done <${IP_SOA}

      # If the domain is foreign then warn me
      if [ ! ${IT_IS_ME} ] ; then
        echo "${ZONE}:" | awk '{ printf("%-35s",$0)}'
        echo "has ${SOA} as SOA-record (not me)"
      fi
    fi
    if [ ${IT_IS_ME} ] ; then
      egrep -A15 "zone.+\"${ZONE}" ${NAMED_CONF} | grep -B20 '^};' | grep -A8 'allow-transfer {' | grep -B8 'common-allow-transfer;' | egrep -o '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' >${IP_AUTH}
      if [ -s ${IP_AUTH} ] ; then
        SOA_THIS_SERIAL=`host -t SOA ${ZONE} ${IT_IS_ME} 2>/dev/null | egrep -o 'has SOA record [A-Za-z0-9.-]+ .*' | awk '{print $6}'`
        while read IP ; do
          SOA_AUTH_COMPLETE=`host -t SOA ${ZONE} ${IP} 2>/dev/null | egrep -o 'has SOA record [A-Za-z0-9.-]+ .*'`
          SOA_AUTH=`echo "${SOA_AUTH_COMPLETE}" | awk '{print $4}'`
          SOA_AUTH_SERIAL=`echo "${SOA_AUTH_COMPLETE}" | awk '{print $6}'`
          if [ -z "${SOA_AUTH}" ] ; then
            echo "${ZONE}:" | awk '{ printf("%-35s",$0)}'
            echo "Unable to resolve the SOA-record at the IP ${IP}"
          elif [ ! "${SOA_AUTH}" = "${SOA}" ] ; then
            echo "${ZONE}:" | awk '{ printf("%-35s",$0)}'
            echo "The SOA-record I resolved at the IP ${IP} (${SOA_AUTH}) is different than the one I resolved using ${CACHING_DNS} (${SOA})"
          elif [ ! "${SOA_AUTH_SERIAL}" = "${SOA_THIS_SERIAL}" ] ; then
            echo "The serial of the SOA-record I resolved at the IP ${IP} (${SOA_AUTH_SERIAL}) is different than the one I resolved using ${IT_IS_ME} (${SOA_THIS_SERIAL})"
          fi
        done<${IP_AUTH}
      else
        echo "${ZONE}:" | awk '{ printf("%-35s",$0)}'
        echo "No IP's for Authorative Namerserver found in ${NAMED_CONF}"
      fi
    fi
  fi
done<${ZONES}
echo "                                "

rm ${ZONES}
rm ${THIS_SERVER_A}
rm ${THIS_SERVER_IP}
rm ${IP_SOA}
rm ${IP_AUTH}

Just ran the script...
Again the SOA-record has been changed for several domains. It was fine a month ago.
 
Last edited:
I'm so grateful, as the current (intransparent) behaviour drove us mad.
We're using powerDNS based secondarys for several of our Plesk servers, and whenever the primary DNS in the SOA record is no longer the Plesk server itself, the secondarys stop updating the zone and will even drop it after the expire timer.
We have so many customer calls because of this and the often the only way to fix this, was to recreate the complete DNS zone. (not so much fun when it contains lots of custom records)
 
Back
Top