Skip to main content

AutoSSL Error domain is unmanaged

Comments

20 comments

  • cPRex Jurassic Moderator
    Hey there! Usually this issue happens when your local server can't retrieve information from the nameservers being used for the domain. You can get a full list of the nameservers for the domain with this command: dig +short NS domain.com
    You can try manually pulling your DNS records from those nameservers with "dig domain.com @name.server.com" to see if you can reach each of those. You can also run this command to get information on the domain the same way AutoSSL does: /scripts/cpdig cpanel.net A --verbose
    as that may give you additional details.
    0
  • dstana
    Hey there! Usually this issue happens when your local server can't retrieve information from the nameservers being used for the domain. You can get a full list of the nameservers for the domain with this command: dig +short NS domain.com
    You can try manually pulling your DNS records from those nameservers with "dig domain.com @name.server.com" to see if you can reach each of those. You can also run this command to get information on the domain the same way AutoSSL does: /scripts/cpdig cpanel.net A --verbose
    as that may give you additional details.

    I have this same issue. Dig returns the nameservers for the domain and the IP of those nameservers as well as the website just fine. The issue is the way cpanel does the check with /scripts/cpdig cpanel.net A --verbose
    This is what some of the response looks like: [1611786316] libunbound[7537:0] info: resolving ns2.nameserver.com. AAAA IN [1611786316] libunbound[7537:0] info: resolving ns1.nameserver.com. AAAA IN [1611786316] libunbound[7537:0] info: error sending query to auth server 2001:503:a83e::2:30 port 53 [1611786316] libunbound[7537:0] info: error sending query to auth server 2001:502:7094::30 port 53 [1611786316] libunbound[7537:0] info: error sending query to auth server 2001:503:a83e::2:30 port 53 [1611786316] libunbound[7537:0] info: error sending query to auth server 2001:503:39c1::30 port 53 [1611786316] libunbound[7537:0] info: error sending query to auth server 2001:502:7094::30 port 53 [1611786316] libunbound[7537:0] info: response for ns1.nameserver.com. AAAA IN [1611786316] libunbound[7537:0] info: reply from 192.31.80.30#53 [1611786316] libunbound[7537:0] info: query response was REFERRAL [1611786316] libunbound[7537:0] info: response for ns2.nameserver.com. AAAA IN [1611786316] libunbound[7537:0] info: reply from 192.5.6.30#53 [1611786316] libunbound[7537:0] info: query response was REFERRAL
    Both my nameservers are ec2s on AWS running cPanel DNSonly in a dns cluster. Everything else seems to work fine except cpanel. Any thoughts?
    0
  • Irksome73
    Mine was simply that the domain registration took longer than usual to propagate - the next day it worked. However we still see huge quantities of libunbound errors, all relating to IPv6 lookups, it seems not to like running on a server without IPv6 enabled.
    0
  • cPRex Jurassic Moderator
    These issues mentioned seem specific to the IPv6 configuration on the system. Can you work through the guide here to see if that helps you find any issues?
    0
  • Irksome73
    My server reports that an IPv6 address is configured for eth0 but I can't ping6 any host (network is unreachable).
    0
  • cPRex Jurassic Moderator
    That sounds like the issue then. You'd want to speak with your host to see why those outbound requests aren't working well and that should take care of the issue.
    0
  • dstana
    That sounds like the issue then. You'd want to speak with your host to see why those outbound requests aren't working well and that should take care of the issue.

    This isn't an ipv6 issue. my ipv6 was enabled but not configured to work. I turned it off on my system. The issue still persists, Seems like a cpanel issue, not the system. cpdig still tries to resolve ipv6 addresses. ipv6 is disabled on my system and all dns to the server is ipv4. Is ipv6 required to use autossl or whm/cpanel in general? My other servers are all configured the same way, ipv6 is enabled on the system but not configured. None of them have these issues with not being able to issue autossl certs.
    0
  • dstana
    Anything on this? After looking I'm also having issues with a bunch of certs backed up in the queue that are actually good to issue from 3 days ago.
    0
  • cPRex Jurassic Moderator
    The IPv6 connection isn't necessarily required, but it seems to be what the nameservers in question responded with in your output: [1611786316] libunbound[7537:0] info: resolving ns2.nameserver.com. AAAA IN [1611786316] libunbound[7537:0] info: resolving ns1.nameserver.com. AAAA IN [1611786316] libunbound[7537:0] info: error sending query to auth server 2001:503:a83e::2:30 port 53 [1611786316] libunbound[7537:0] info: error sending query to auth server 2001:502:7094::30 port 53 [1611786316] libunbound[7537:0] info: error sending query to auth server 2001:503:a83e::2:30 port 53 [1611786316] libunbound[7537:0] info: error sending query to auth server 2001:503:39c1::30 port 53 [1611786316] libunbound[7537:0] info: error sending query to auth server 2001:502:7094::30 port 53
    Can you let me know what happens when you run the following command on your system? dig +trace A google.com
    0
  • eLIANT
    Same AutoSSL failure problem: Domain "is unmanaged. Verify this domain"s registration and authoritative nameserver configuration to correct this problem." Here's what I got from dig +trace A google.com I have NO IPV6 addresses assigned. (This all started after V92. This is the first domain I've tried to set up since then. It's fully propagated as of yesterday, but today AutoSSL fails. ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 <<>> +trace A google.com ;; global options: +cmd . 461894 IN NS e.root-servers.net. . 461894 IN NS g.root-servers.net. . 461894 IN NS m.root-servers.net. . 461894 IN NS a.root-servers.net. . 461894 IN NS l.root-servers.net. . 461894 IN NS i.root-servers.net. . 461894 IN NS j.root-servers.net. . 461894 IN NS k.root-servers.net. . 461894 IN NS h.root-servers.net. . 461894 IN NS b.root-servers.net. . 461894 IN NS d.root-servers.net. . 461894 IN NS c.root-servers.net. . 461894 IN NS f.root-servers.net. . 461894 IN RRSIG NS 8 0 518400 20210210230000 20210128220000 42351 . A4BA/TsDBQXzYCv3Xrnlw81ZbRmx/VhJpqcx59AaAo9nJGWQ/0kyKrCN N0hAmRSl4i5SLQYbKH2n+ihylehYWgMAT0sg4eTWJyFX+mJGXVKMnSQF qQsUWcMZG7LNCooLjvbrGllXqn1nynnwRTKYyzI3P/VDxhf1Jke3r2aT hFB+OSt3B4GVxyN4XdgC3qrqP0wJKFeXsE4HQKpGNHT5M+bo/IOOgj+2 XHXcQKuTDgLDtFAg2ZDJggxCTidMinilFUtWX7vPuwt/2nb/BUlBxWVe /2jb0xkdexRCL94itOXWpOC00HvoeLuEq4Dy8VJL3CNu4ttxpulUa0YX C/005w== ;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20210211050000 20210129040000 42351 . P218EmxC7xpY/FcWzenA1emWi6swrjzLHaQjt06xgLXVT28/a+MnyyRz CjC3I8+88E/aTCFE8Php+5K8ziAcNjxO4unClNh2qMQpTz5VlEIDKbS9 KlHrCx8IAhS2J1xwYvEKEUdR+BfJvJ4uwAKN3kYVisSgx7azZmXtP8F9 0YVQKsyKSS6uj3J9+VBDKzTCDF/F8KLL1+wu5R31NvjYvMOLM25ze/b+ 0mPI9R+NNUJtPHYRWyHJ/4ykY+PTz1jLWLbYyy0SvBQ4kbIudwjwEcqH PiLVzwbKgcVpOK8Af6mOePpXXi/9odtIrtVj2TZw9mpE8646tPVfAcdE ocdjrg== ;; Received 1170 bytes from 193.0.14.129#53(k.root-servers.net) in 66 ms google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20210205054045 20210129043045 58540 com. EH5YllUVHii00WmEGefJmO4b3orus0uDJ5fgR9v0DJ+HJHT8VcAx0a/b mRuKolppJoeUb6AfsgSX662TS3X7e+wIsGiEj6ejSuMJ09HF++F72LJM vR2SeUxTsZKhQUVgLtoJkqrmy98jC4LZvExthVNj5yYD70a3Ns/Qf3SL ata0PRkKXKVNkUAF9w7S3FfAhV1dx7glwst7uOwbbGwrKA== S84BDVKNH5AGDSI7F5J0O3NPRHU0G7JQ.com. 86400 IN NSEC3 1 1 0 - S84BUO64GQCVN69RJFUO6LVC7FSLUNJ5 NS DS RRSIG S84BDVKNH5AGDSI7F5J0O3NPRHU0G7JQ.com. 86400 IN RRSIG NSEC3 8 2 86400 20210202053438 20210126042438 58540 com. TRnJjB2qVc31zKf2Q7hQNQJmCN2qdBvf3RzPNrqPYixL4EtJxqU8DdLp b1TlKGkf+rakmVRTxxpAjj3AW/HR3cGAhIRJ58sCC82vInlpmLwNc/e2 +ZTjPfgVlr7o5mCf9H/eWZcEvW1jn9R8ypWVJKqL2BMq2yykxEsynDf4 tH77yGGeGijO+bTzXZTzAsFx611CiydcW9PXC5w+pdbHAQ== ;; Received 836 bytes from 192.5.6.30#53(a.gtld-servers.net) in 25 ms google.com. 300 IN A 172.217.12.14 ;; Received 55 bytes from 216.239.38.10#53(ns4.google.com) in 47 ms
    0
  • cPRex Jurassic Moderator
    @eLIANT - what happens when you check your domain with cpdig?
    0
  • eLIANT
    Digging an old domain yields the two private nameservers I've used for years: Digging the new domain shows same results.
    0
  • cPRex Jurassic Moderator
    If you use this specific command against the domain does that show anything out of the ordinary? /scripts/cpdig domain.com A --verbose
    0
  • eLIANT
    Yes, there's quite a bit out of the ordinary; especially when I run the same command against old domain I mentioned earlier (not included, below). I don't recognize most of these IP addresses.
    0
  • cPRex Jurassic Moderator
    Could you get a ticket submitted to our team so we can look into that for you?
    0
  • eLIANT
    Ticket submitted. I'll post later if we can identify a specific cause.
    0
  • cPRex Jurassic Moderator
    If you could post the ticket number her I can follow along and make sure everyone gets updated.
    0
  • eLIANT
    The ID is # 94182262 You all did some investigating and concluded that the data center or host service provider has a bad setup. Possibly an incorrect network firewall setting. We are still waiting for Hostgator to resolve this issue. (they sometimes take forever to deal with tickets. This one has been open 37 hours and it hasn't been assigned to a tech.)
    0
  • cPRex Jurassic Moderator
    Thanks for the information. I'm following that on my end as well now so I'll keep this updated if we have any new details on our end.
    0
  • cPRex Jurassic Moderator
    It looks like both issues you mentioned in the ticket have been resolved, but let me know if you need anything else from my end.
    0

Please sign in to leave a comment.