SOLVED [CPANEL-30649] Misleading message on "Email Deliverability" SPF / DKIM option.

[4u123]

I've noticed a very misleading and innacurate message that now appears when any cpanel user tries to use the "Email Deliverability" option. It has started saying this...

This system does not control DNS for the “domain.com” domain. You can install the suggested “DKIM” record locally. However, this server is not the authoritative nameserver. If you install this record, this change will not be effective. Contact the person responsible for the “ns2.blah.net”, “ns1.blah.net”, “ns3.blah.net”, and “ns4.blah.net” nameservers and request that they update the “DKIM” record with the following:

This is stupid because those ARE our nameservers - these are the nameservers in our cpanel cluster.

The error message seems to suggest that the local cpanel server must be an authoritative nameserver for the domain - whch is again stupid becasue this is almost never the case. When using a cpanel DNS cluster correctly, the local nameserver on the cpanel servers should always be disabled.

Further to this, the servers are listed in the remote nameserver IP's list in WHM.

What really gets me is this " If you install this record, this change will not be effective."

It's simply not true. If they install the records the change will be effective since those nameservers are our cpanel cluster nameservers.

Something very wrong here.

 

[cPanelLauren]

Hello,


I'd lean toward this being a result of a case that was opened yesterday CPANEL-30649 - cPanel -> Email Deliverability' is unable to determine that a domain has local authority

The issue lies specifically in /usr/local/cpanel/Cpanel/DnsUtils/Authority.pm with:

             $dns_soa{$zone} //= _get_serial_number_from_dns($zone);

In v82 this was completed and we compared a string with a string:

# /usr/local/cpanel/3rdparty/bin/perl -MData::Dumper -MCpanel::DnsUtils::Authority -e 'my @domains = qw[domain.tld]; print Dumper( Cpanel::DnsUtils::Authority::has_local_authority(\@domains) );'
$VAR1 = 'domain.tld';
$VAR1 = '2019120903';
$VAR1 = '2019120910';

It was found that in v84 and v86 to determine if the server's nameservers were authoritative for a domain we ran the same query and began comparing a string to a hash reference which won't match in the SOA field:

# /usr/local/cpanel/3rdparty/bin/perl -MData::Dumper -MCpanel::DnsUtils::Authority -e 'my @domains = qw[domain.tld]; print Dumper( Cpanel::DnsUtils::Authority::has_local_authority(\@domains) );'
$VAR1 = 'domain.tld';
$VAR1 = '2019120903';
$VAR1 = {
          'mname' => 'ns.primarydomain.tld.',
          'minimum' => 86400,
          'rname' => 'host.primarydomain.tld.',
          'retry' => 7200,
          'refresh' => 3600,
          'expire' => 1209600,
          'serial' => 2019120903
        };

To confirm that this is the same issue you're experiencing you might try running the command provided above and replace domain.tld with your domain name. Alternatively, you could potentially confirm that authority is being seen on the local machine by running the WHMAPI1 function as follows:

whmapi1 has_local_authority domain=$domain

This issue is currently being monitored and has not been resolved yet, nor are there any viable workarounds at this time. We will update this thread when there are any further updates or the issue is resolved.

 

[4u123]

In order for me to understand this correctly, I need to know how you define "has local authority".

 

[cPanelLauren]

"has local authority" and a server being Authoritative for the domain are the same thing in this context. The definition that I believe explains this best is as follows:

What Is Authoritative Name Server?

Explains Authoritative DNS Name Server – which provides actual answer to your DNS queries such as – mail server IP address or web site IP address (A resource record).

www.dnsknowledge.com

An authoritative name server provides actual answer to your DNS queries such as – mail server IP address or web site IP address (A resource record). It provides original and definitive answers to DNS queries. It does not provides just cached answers that were obtained from another name server. Therefore it only returns answers to queries about domain names that are installed in its configuration system.

Meaning, the domain is assigned nameservers local to your server/cluster.

 

[4u123]

While I don't agree with your first comment...

"has local authority" and "a server being Authoritative for the domain" are the same thing in this context.

I'd argue that those are two different things, especially in this context. The authoritative nameservers for the domain could be anywhere. The local server, within the cluster, or any external nameserver.

I didn't ask "what is an authoritative nameserver?" so your pasted description was really quite unnecessary.

I'll take your final comment...

Meaning, the domain is assigned nameservers local to your server/cluster.

...that you define "has local authority" to mean that the authoritative nameservers for the domain are either on the local server or within the cpanel DNS cluster. You could have simply said that - it's all I asked for.

I'm assuming that you use the SOA record comparison to avoid cached responses that could occur via simpler methods of looking up this information. I don't see any problems with this process. The script you have pasted in your initial response appears to show how you are obtaining the authoritative nameserver details - but I'm not sure exactly how you are determining the "local" aspect of it? Your reply is missing that info. This is the part of the process that is failing and is what we are concerned with here.

So as per my original post in this thread. When attempting to identify "local authority" - the Email deliverability process is missing the fact that the DNS cluster servers are "local" and while it identifies them as authoritative correctly, it considers them external.

Running the commands you pasted simply confirms this. I'm guessing this is simply another bug that is affecting everyone.

Please do let me know if you find out any more info about this bug, or if you want us to run some tests in our environment we would be happy to do so.

 

[cPanelLauren]

Thank you so much for the suggestions! Your assistance is not necessary at this time, but we do appreciate the offer.

We'll update here when the issue is resolved as well as in our changelogs here: 84 Change Log - Change Logs - cPanel Documentation

 

[4u123]

Can you please find out for me whether or not the "Remote Service IP's" configured in WHM are taken into consideration during this process?

 

[cPanelLauren]

Hello,

I don't see it being referenced in an strace when using either the WHM or cPanel email deliverability UI. The strace used was:

ps aux|awk '/(cpsrv|whostmgr)d/{print"-p",$2}'|xargs strace -fvyyys1024 -e trace=file |&egrep 'ips.remotedns|ips.remotemail'
^@^@^@^C

Furthermore in this instance, referencing wouldn't really be relevant. Even though email deliverability is determining whether the server is authoritative for the domain, having an IP in ips.remotedns or ips.remotemail wouldn't cause this server to be viewed as authoritative. This would only allow an exception for the following:

• Mail routing - IP's added would be considered locally routed)
• Adding remote domains (IP's added here would be an exception for having "allow remote domains" disabled).

 

[4u123]

Thanks for checking. We had some old nameserver IP's listed in there and once I removed them I checked a customer's domain with this problem and the error message didn't come up. It must just be a coincidence, or It's possible once you ignore the error message and set up the records anyway, that the error doesn't come up again on the same domain afterwards.

 

[cPanelLauren]

Thanks for checking. We had some old nameserver IP's listed in there and once I removed them I checked a customer's domain with this problem and the error message didn't come up. It must just be a coincidence, or It's possible once you ignore the error message and set up the records anyway, that the error doesn't come up again on the same domain afterwards.

That sparks some curiosity, I'll test on Monday whether or not I have the same behavior or similar and let you know my findings.

 

[anton_latvia]

Hopefully this is fixed soon.

 

[sneader]

We are seeing the exact same problem. I'm looking at one customer right now that has their DNS servers set, per InterNIC whois, to the exactly correct nameservers for this particular server, yet cPanel says "this system does not control DNS for the redacted.com domain".

It's flat out WRONG information, and super confusing to customers. We have nothing in Remote Service IPs (and have never used that feature). I hope this gets fixed soon. cPanelLauren if you need me to open a ticket on this, let me know.

- Scott

 

[cPanelLauren]

I couldn't find anything that directly related it to remote service IP's in my testing, but it was a good direction to check. I checked in on this and the issue is resolved in v86 of cPanel/WHM which is currently in the EDGE tier.

There is a request for it to be resolved in v84 thought that's not completed yet. I'll update here as soon as it's in a RELEASE version of cPanel/WHM

 

[LukeR]

I have the same problem

 

[WhiteDog]

We also have the same problem.

 

[cPanelLauren]

Hello,

With the transition of v86 to RELEASE this issue is marked as being resolved per the changelogs here: Change Logs - Change Logs - cPanel Documentation

Please let us know if you continue to experience issues in relation to this.

 

[Ant4res]

Hi everyone,
unfortunately we are facing the same problem.
On the "Email Deliverability" cPanel we have problems with DKIM and SPF configuration but we can't use the "Repair" function due to DNS (image).

If we try to "Manage" the domain:

"This system does not control DNS for the “xxx.com” domain. You can install the suggested “DKIM” record locally. However, this server is not the authoritative nameserver. If you install this record, this change will not be effective. Contact the person responsible for the ‘ns1.register.it’ e ‘ns2.register.it’ nameservers and request that they update the “DKIM” record with the following: "
What we can do?

Thanks

 

[4u123]

This issue is most definitely still ongoing. We are in the process of transferring accounts to new servers right now and around 50 percent of all domains come up with this same error during the transfer process.

This system is not authoritative for the zone “domain.com”. You must update the nameservers for “domain.com” from “ns3.nameserver.net”, “ns4.nameserver.net”, “ns2.nameserver.net”, and “ns1.nameserver.net” to “ns1.nameserver.net”, “ns2.nameserver.net”, “ns3.nameserver.net”, and “ns4.nameserver.net” to complete this transfer.

It's asking us to change the nameservers on the domain to the nameservers that are already set on the domain!?

The only difference I can see is the order in which they are presented in the error. The nameserver order is randomised by the registrar when applied for the first time, so it wont always be 1234. I doubt that cpanel is expecting a particular order. That would be inappropriate.

On this particular domain I checked "Email Deliverability" in cpanel and it did not show the error - but we do still see this issue happening in cpanel.

 

[cPanelLauren]

@4u123

Does this occur only right after you transfer the domain or does it persist after propagation would have completed? If this persists I'd advise that you open a ticket so it can been looked into further.

 

[dedcode]

Possible solution, hopefully your case, let's start:
Click on the News section of the WHM top menu, there you must update the server in case it asks for it, once updated, it will let you activate the DKIM

It is worth mentioning that you must have the private key to generate the DKIM
Having the TXT records that request entry into your DNS server