SOLVED [CPANEL-30266] AutoSSL did not renew the certificate

stelianb

Registered
Nov 7, 2019
3
1
3
Romania, Bucharest
cPanel Access Level
Root Administrator
Hy, i have same problem - ticket open 13713117 -
DNS DCV: The system failed to determine whether “***.ro” is a registered domain because of a DNS error: (XID 6ct5yr) DNS returned “SERVFAIL” (code 2) in response to the system’s query for “***.ro”’s “NS” records.; HTTP DCV: The system failed to determine whether “***.ro” is a registered domain because of a DNS error: (XID 6ct5yr) DNS returned “SERVFAIL” (code 2) in response to the system’s query for “***.ro”’s “NS” records.

This problem occurs in all hosted areas.
 
Last edited by a moderator:
  • Like
Reactions: gosites

ciao70

Well-Known Member
Nov 3, 2006
151
34
178
Test Email Deliverability

warn [whostmgrd] The subprocess (whostmgr (partial)) exited with an error: The subprocess reported error number 1 when it ended. at /usr/local/cpanel/Cpanel/Server/Handlers/SubProcess.pm line 251.
Cpanel::Server::Handlers::SubProcess::_report_subprocess_errors(Cpanel::Server::Handlers::SubProcess=HASH(0x1b0dfc0)) called at /usr/local/cpanel/Cpanel/Server/Handlers/SubProcess.pm line 109
Cpanel::Server::Handlers::SubProcess::handler(Cpanel::Server::Handlers::SubProcess=HASH(0x1b0dfc0), "subprocess_name", "whostmgr (partial)", "subprocess_read_handle", GLOB(0x1b3a9e0), "subprocess_write_handle", GLOB(0x1b3a890), "subprocess_pid_to_reap", ...) called at cpsrvd.pl line 7267
cpanel::cpsrvd::cpHandler("app", "whostmgr", "json", 0, "document", "./shared/js/email_deliverability/views/listDomains.ptt") called at cpsrvd.pl line 6389
cpanel::cpsrvd::dodoc_whostmgrd() called at cpsrvd.pl line 1972
cpanel::cpsrvd::dodoc(HASH(0x1398720)) called at cpsrvd.pl line 1717
cpanel::cpsrvd::handle_one_connection(6) called at cpsrvd.pl line 1097
cpanel::cpsrvd::script() called at cpsrvd.pl line 425
warn [xml-api] DNS query failure (........in-addr.arpa/PTR): Cpanel::Exception::Timeout/(XID z4qdqf) DNS query (.........in-addr.arpa/PTR) timeout!
at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 366.
Cpanel::DNS::Unbound::_die_if_query_failed(HASH(0x25a8700)) called at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 355
 

morrow95

Well-Known Member
Oct 8, 2006
189
12
168
Had the same thing happen this morning for multiple domains... some of which will end up expiring in the next week. I already opened a cpanel support ticket and it just so happens the queue is extremely bad today for other reasons so still waiting. In the meantime, if you figure anything out please list it here in the thread.

I changed from BIND to PowerDNS a few days ago so I thought that might be related, but since you are having the same issue maybe it isn't.
 

cPanelLauren

Product Owner II
Staff member
Nov 14, 2017
13,266
1,304
363
Houston
Hello @stelianb

The issue you were experiencing was related to an internal case CPANEL-30266 where libunbound was timing out over IPv6 timeouts on root nameservers. Since you're utilizing CloudFlare for your domains - I'd suggest that the only way to get a request over IPv4 to workaround this issue would be to use your DNS instead of theres. You may not want to do this though and in that case until our developers resolve the issue or until an alternate workaround is provided the request will fail.

@morrow95 what's your ticket ID and I'll look to see if its the same issue


In reference to the case I will update here when there is any change to the case.

Thanks!
 

morrow95

Well-Known Member
Oct 8, 2006
189
12
168
13715961 - I was told this was related to CPANEL-30266 as well and no workaround or timeframe as of yet. I am trying to think how to approach this right now since we have certs which will expire within the week. I am hoping I can manually renew those certs somehow because if I can't and they expire then there is a lot of things I have to change to prepare our sites for not having https. Unlike most of the people on here we do not host sites for others or resell, but rather have our own company domains on the server.
 

cPanelLauren

Product Owner II
Staff member
Nov 14, 2017
13,266
1,304
363
Houston
13715961 - I was told this was related to CPANEL-30266 as well and no workaround or timeframe as of yet. I am trying to think how to approach this right now since we have certs which will expire within the week. I am hoping I can manually renew those certs somehow because if I can't and they expire then there is a lot of things I have to change to prepare our sites for not having https. Unlike most of the people on here we do not host sites for others or resell, but rather have our own company domains on the server.
Right now for affected users we're suggesting disabling IPv6 pending a more viable workaround/resolution. It looks like the analysts suggested that to you as well. Were you able to complete this?
 

stelianb

Registered
Nov 7, 2019
3
1
3
Romania, Bucharest
cPanel Access Level
Root Administrator
Hi, thanks for the answer, I changed the servers of CloudFlare to he.net yesterday. On another server where I still have he.net I am not familiar with the certificates. To me after this change, the problem persisted. Ipv6 is off.
 

tnp808

Registered
Nov 8, 2019
1
0
1
Toronto
cPanel Access Level
Root Administrator
I'm having the same issue across all my sites.

DNS DCV: The system failed to determine whether “******.com” is a registered domain because of a DNS error: (XID 9428bu) DNS returned “SERVFAIL” (code 2) in response to the system’s query for “******.com”’s “NS” records.; HTTP DCV: The system failed to determine whether “******.com” is a registered domain because of a DNS error: (XID 9428bu) DNS returned “SERVFAIL” (code 2) in response to the system’s query for “******.com”’s “NS” records.

I can't add a SSL on my new site because of this.
 

cPanelLauren

Product Owner II
Staff member
Nov 14, 2017
13,266
1,304
363
Houston
For anyone experiencing this issue, I urge you to open a ticket, we are in need of servers to replicate this - please reference this thread and internal case ID CPANEL-30266

Or, if you update here I can make those notes for you.


Thanks!
 

morrow95

Well-Known Member
Oct 8, 2006
189
12
168
I just wanted to update the thread here. In my situation we have a vpc with two vms setup (one for WHM with our domains, apache, etc and a second for our mariadb database only). With this setup we have public ips and internal ips which are nat'ed. As it turns out, our hosting provider who provisioned this years ago did not setup the dnat/snat rules so internal could connect to external if that makes sense - I am not a server guy and just know the basics and have a grasp of what was going on. Support pointed me to Hairpin NAT / NAT Hairpinning with vShield Edge as a reference to look at. I gave it a try and created some new dnat/snat rules for internal as we only had external setup prior. After doing so I tested the results :

# telnet 111.111.111.111 53

and

# nmap -sT 111.111.111.111 -p 53

for both of our private nameserver ips and they returned correctly this time around. Now that the dns was responding as it should I just went and re-checked our domains in autossl of WHM and within minutes it had retrieved new certs and installed them for the domains that were expiring.

From what I get out of this whole thing... there was a change with WHM in v84 where some dns/resolver things were changed. It no longer liked the way our server was setup and responding or was using a different method that didn't like it. Before we translated public ips to internal and vice versa for external only. We had to add those same translations for internal as well.

I'm sure I worded this badly or in a confusing way as I am not familiar with this sort of stuff, but hopefully you understand what happened in my case and what resolved it.
 

chatchail

Registered
Nov 9, 2019
1
0
1
thailand
cPanel Access Level
Root Administrator
I'm have same problem Ticket Open 13733065

DNS DCV: The system failed to determine whether “****.cloud” is a registered domain because of a DNS error: (XID pn6vtf) DNS returned “SERVFAIL” (code 2) in response to the system’s query for “****.cloud”’s “NS” records.; HTTP DCV: The system failed to determine whether “****.cloud” is a registered domain because of a DNS error: (XID pn6vtf) DNS returned “SERVFAIL” (code 2) in response to the system’s query for “****.cloud”’s “NS” records.

I can't auto renew SSL multiple domains expire and can't add SSL on new site
 

stelianb

Registered
Nov 7, 2019
3
1
3
Romania, Bucharest
cPanel Access Level
Root Administrator
Problem solved. CPanel test environment latest version + new static IP + restore backup user 1 each 1. The first 4 accounts after the restoration immediately renegotiated the certificates, the 5th NO. I deleted the data, I recreated another user (for the same domain) - I suspected that there would be something dubious in / home / user, and the same problem with AutoSSL. After a long search I found that this domain had a DNSSEC registration with the registrar. I deleted that record and AutoSSL started working immediately. !!! In the attention of cPanel: Interesting that only this user had DNSSEC, but indirectly the AutoSSL service is affected for all WHM users. With this I consider that the ticket opened by me can be closed.

PS:

It has no connection to the ipv6 (link only) connection in CentOS 7
 

live.vikas

Registered
Nov 12, 2019
2
0
1
India
cPanel Access Level
Website Owner
Getting this issue on all new created domain or on renewal

DNS DCV: The system failed to determine whether “****.com” is a registered domain because of a DNS error: (XID mbabmr) DNS query (****.com/NS) timeout!; HTTP DCV: The system failed to determine whether “****.com” is a registered domain because of a DNS error: (XID mbabmr) DNS query (****.com/NS) timeout!

Ticket No: 13757973
 

cPanelLauren

Product Owner II
Staff member
Nov 14, 2017
13,266
1,304
363
Houston
Getting this issue on all new created domain or on renewal

DNS DCV: The system failed to determine whether “****.com” is a registered domain because of a DNS error: (XID mbabmr) DNS query (****.com/NS) timeout!; HTTP DCV: The system failed to determine whether “****.com” is a registered domain because of a DNS error: (XID mbabmr) DNS query (****.com/NS) timeout!

Ticket No: 13757973
Hello,

I've updated that ticket with a note to indicate that it's associated with this thread and will update here with the outcome.
 

ciao70

Well-Known Member
Nov 3, 2006
151
34
178
Hello,

In addition:


Code:
warn [xml-api] DNS query failure (.......in-addr.arpa/PTR): Cpanel::Exception::Timeout/(XID p2jpa5) DNS query (.........in-addr.arpa/PTR) timeout!

at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 366.

    Cpanel::DNS::Unbound::_die_if_query_failed(HASH(0x25a8700)) called at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 355

    Cpanel::DNS::Unbound::recursive_query_or_die(Cpanel::DNS::Unbound=HASH(0x1ef7518), "............in-addr.arpa", "PTR") called at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 416

    eval {...} called at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 416

    Cpanel::DNS::Unbound::recursive_query(Cpanel::DNS::Unbound=HASH(0x1ef7518), "..........in-addr.arpa", "PTR") called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 341

    Cpanel::DnsUtils::ReverseDns::_validate_ptr("IP......", "........in-addr.arpa", "A", CODE(0x25afa60)) called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 329

    Cpanel::DnsUtils::ReverseDns::validate_ipv4_ptr_record("IP.......") called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 159

    Cpanel::DnsUtils::ReverseDns::validate_ptr_record("IP") called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 96

    Cpanel::DnsUtils::ReverseDns::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97

    eval {...} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88

    Try::Tiny::try(CODE(0x2586100), Try::Tiny::Catch=REF(0x251ecd0)) called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 101

    Cpanel::DnsUtils::ReverseDns::validate_ptr_records_for_ips(ARRAY(0x25869a0)) called at /usr/local/cpanel/Cpanel/DnsUtils/MailRecords.pm line 658

    Cpanel::DnsUtils::MailRecords::validate_ptr_records_for_domains(HASH(0x1db38b8)) called at /usr/local/cpanel/Whostmgr/API/1/EmailAuth.pm line 50

    Whostmgr::API::1::EmailAuth::validate_current_ptrs(HASH(0x1dbf7d8), HASH(0x1d87ef0), HASH(0x1d87e30)) called at whostmgr/bin/xml-api.pl line 3619

    whostmgr::bin::xml_api::__ANON__(HASH(0x1d87ef0), HASH(0x1dbf7d8), HASH(0x1d87e30), undef) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 219

    Whostmgr::API::1::Data::Wrapper::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97

    eval {...} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88

    Try::Tiny::try(CODE(0x1dbf7f0), Try::Tiny::Catch=REF(0x1ef75d8)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 238

    Whostmgr::API::1::Data::Wrapper::execute_internal(CODE(0x1ed5cc0), HASH(0x1dbf7d8), HASH(0x1d87e30), HASH(0x1dc0520), undef) called at whostmgr/bin/xml-api.pl line 3794

    whostmgr::bin::xml_api::runapp("validate_current_ptrs", HASH(0x1d87e30), HASH(0x1db3d20), 1, undef) called at whostmgr/bin/xml-api.pl line 3875

    eval {...} called at whostmgr/bin/xml-api.pl line 3875

    whostmgr::bin::xml_api::batch_runapp(HASH(0x18abd08), HASH(0x1d618a8), HASH(0x1d681f8)) called at whostmgr/bin/xml-api.pl line 3619

    whostmgr::bin::xml_api::__ANON__(HASH(0x1d618a8), HASH(0x18abd08), HASH(0x1d681f8), CODE(0x1d5d618)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 219

    Whostmgr::API::1::Data::Wrapper::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97

    eval {...} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88

    Try::Tiny::try(CODE(0x1d6d7f8), Try::Tiny::Catch=REF(0x1d6b600)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 238

    Whostmgr::API::1::Data::Wrapper::execute_internal(CODE(0x1d67a00), HASH(0x18abd08), HASH(0x1d681f8), HASH(0x1d616c8), CODE(0x1d5d618)) called at whostmgr/bin/xml-api.pl line 3794

    whostmgr::bin::xml_api::runapp("batch", HASH(0x1d681f8), HASH(0x17b9f08), 0, CODE(0x1d5d618)) called at whostmgr/bin/xml-api.pl line 3526

    whostmgr::bin::xml_api::script(CODE(0x1d5d618), "-json", "./batch") called at whostmgr/bin/xml-api.pl line 3472

at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 425.

    Cpanel::DNS::Unbound::_warn_query_failure(".........in-addr.arpa", "PTR", "") called at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 417

    Cpanel::DNS::Unbound::recursive_query(Cpanel::DNS::Unbound=HASH(0x1ef7518), ".............in-addr.arpa", "PTR") called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 341

    Cpanel::DnsUtils::ReverseDns::_validate_ptr("IP......", "............in-addr.arpa", "A", CODE(0x25afa60)) called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 329

    Cpanel::DnsUtils::ReverseDns::validate_ipv4_ptr_record("IP......") called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 159

    Cpanel::DnsUtils::ReverseDns::validate_ptr_record("IP........") called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 96

    Cpanel::DnsUtils::ReverseDns::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97

    eval {...} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88

    Try::Tiny::try(CODE(0x2586100), Try::Tiny::Catch=REF(0x251ecd0)) called at /usr/local/cpanel/Cpanel/DnsUtils/ReverseDns.pm line 101

    Cpanel::DnsUtils::ReverseDns::validate_ptr_records_for_ips(ARRAY(0x25869a0)) called at /usr/local/cpanel/Cpanel/DnsUtils/MailRecords.pm line 658

    Cpanel::DnsUtils::MailRecords::validate_ptr_records_for_domains(HASH(0x1db38b8)) called at /usr/local/cpanel/Whostmgr/API/1/EmailAuth.pm line 50

    Whostmgr::API::1::EmailAuth::validate_current_ptrs(HASH(0x1dbf7d8), HASH(0x1d87ef0), HASH(0x1d87e30)) called at whostmgr/bin/xml-api.pl line 3619

    whostmgr::bin::xml_api::__ANON__(HASH(0x1d87ef0), HASH(0x1dbf7d8), HASH(0x1d87e30), undef) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 219

    Whostmgr::API::1::Data::Wrapper::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97

    eval {...} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88

    Try::Tiny::try(CODE(0x1dbf7f0), Try::Tiny::Catch=REF(0x1ef75d8)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 238

    Whostmgr::API::1::Data::Wrapper::execute_internal(CODE(0x1ed5cc0), HASH(0x1dbf7d8), HASH(0x1d87e30), HASH(0x1dc0520), undef) called at whostmgr/bin/xml-api.pl line 3794

    whostmgr::bin::xml_api::runapp("validate_current_ptrs", HASH(0x1d87e30), HASH(0x1db3d20), 1, undef) called at whostmgr/bin/xml-api.pl line 3875

    eval {...} called at whostmgr/bin/xml-api.pl line 3875

    whostmgr::bin::xml_api::batch_runapp(HASH(0x18abd08), HASH(0x1d618a8), HASH(0x1d681f8)) called at whostmgr/bin/xml-api.pl line 3619

    whostmgr::bin::xml_api::__ANON__(HASH(0x1d618a8), HASH(0x18abd08), HASH(0x1d681f8), CODE(0x1d5d618)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 219

    Whostmgr::API::1::Data::Wrapper::__ANON__() called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 97

    eval {...} called at /usr/local/cpanel/3rdparty/perl/528/lib/perl5/cpanel_lib/Try/Tiny.pm line 88

    Try::Tiny::try(CODE(0x1d6d7f8), Try::Tiny::Catch=REF(0x1d6b600)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 238

    Whostmgr::API::1::Data::Wrapper::execute_internal(CODE(0x1d67a00), HASH(0x18abd08), HASH(0x1d681f8), HASH(0x1d616c8), CODE(0x1d5d618)) called at whostmgr/bin/xml-api.pl line 3794

    whostmgr::bin::xml_api::runapp("batch", HASH(0x1d681f8), HASH(0x17b9f08), 0, CODE(0x1d5d618)) called at whostmgr/bin/xml-api.pl line 3526

    whostmgr::bin::xml_api::script(CODE(0x1d5d618), "-json", "./batch") called at whostmgr/bin/xml-api.pl line 3472

The problem seems to be solved by updating to version 84.0.9

Fixed case CPANEL-30194: Change some errors on WHM's DNS Cluster page into warnings. Reverse Trust, DNSSEC and server status messages are now warnings rather than errors.
 

cPanelLauren

Product Owner II
Staff member
Nov 14, 2017
13,266
1,304
363
Houston
I checked that ticket, it does not appear to be resolved.

@ciao70

Your issues are related to libunbound, the new method of DNS resolution. It does not appear to be specifically related to DNSSEC or clustering based on the errors you're reporting.

Ticket 13760537
Same issues, sigh!
I'm sorry you're experiencing this issue, I've noted this thread in the ticket and I checked in on the case. It looks like it's just awaiting signoff and should be available in a build soon.
 

ciao70

Well-Known Member
Nov 3, 2006
151
34
178
@cPanelLauren

Unfortunately the problem has not been solved.

When doing the email delivery test from this error in the cpanel log

Code:
warn [xml-api] DNS query failure (xx.xx.xx.xx.in-addr.arpa/PTR): Cpanel::Exception::Timeout/(XID cp8gz5) DNS query (xx.xx.xx.xx.in-addr.arpa/PTR) timeout!at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line
Cpanel::DNS::Unbound::_die_if_query_failed(HASH(0x25a8700)) called at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 355
Cpanel::DNS::Unbound::recursive_query_or_die(Cpanel::DNS::Unbound=HASH(0x1ef7518), "............in-addr.arpa", "PTR") called at /usr/local/cpanel/Cpanel/DNS/Unbound.pm line 416
The PTR is still correct even if the test fails

Only once did he give the test ok, otherwise from Time out
 

sproutsystems

Registered
Nov 14, 2019
1
0
1
jhy45J-@g45
cPanel Access Level
Root Administrator
I have the same

DNS DCV: The system failed to determine whether “domain.ch” is a registered domain because of a DNS error: (XID rxs8ya) DNS returned “SERVFAIL” (code 2) in response to the system’s query for “domain.ch”’s “NS” records.; HTTP DCV: The system failed to determine whether “domain.ch” is a registered domain because of a DNS error: (XID rxs8ya) DNS returned “SERVFAIL” (code 2) in response to the system’s query for “domain.ch”’s “NS” records.
 
Last edited by a moderator: