Plesk Error - Failed domain creation - Serial Number update limit - dns

I have an issue with my Plesk instance which really doesn't make sense to me.
I am creating a lot of subdomain for my clients on my main domain.
I don't handle any DNS on my server, service is disabled in Plesk and my 2 DNS servers for that main domain are my domain/vps provider ones (OVH).
I use then to create a subdomain as a zone DNS for each of my client in OVH backend, but know I chose to simply use a wildcard to avoid having 100s of entry.
Then I go to plesk and add a subdomain (vhost) with the associated folder where the subdomain (or domain) needs to go. It use to work fine but unfortunately now I have an error saying:
Error: Failed domain creation: Unable to update the domain data: The
serial number update limit was reached. No further change on the DNS
zone can be done today.
I really don't get it as, on my provider, I can create as many DNS zone as I want, and I really don't see the link between my server/Plesk vhosts/domains/subdomains and the DNS! I don't handle any DNS on my server and I thought creating a subdomain or domain on Plesk was just creating a vhost.
I am stuck on that one, would be great if any of you ever encounter that issue could help me.
PS: Couldn't find anything online ...
PS2: Called my provider and talked to me about SOA limitations, But again I can't see the link here. As the error is not when I try to create a DNS zone but when I try to set a new vhost.

This is a plesk bug know for me as PPPM-2590.
As workaround you can uncheck 'Use serial number format recommended by IETF and RIPE' on parent domain where you have a lot of subdomains or server-wide in 'Tools & Settings > DNS Templates > SOA record Template' and sync template with domains.
You can try this custom fix
Make sure that you have latest update #68
Backup original file:
cp /usr/local/psa/admin/plib/Dns/Zone/Abstract.php /usr/local/psa/admin/plib/Dns/Zone/Abstract.php.ORIG
Download https://docs.google.com/uc?authuser=0&id=0B7Nx66lufdvpSkxxeHpqaGtvWTg&export=download and place it to /usr/local/psa/admin/plib/Dns/Zone/Abstract.php

Related

How can I point my domain from Godaddy to another web server without using # and losing email services?

I have access to a Godaddy account where the company has all their domains. One of those I need to point to another web server running Apache. The person that used to work here before me solved this pointing to the new server IP using the record:
A # the.ip.addr.ess 1 hour
and in the webserver end I get it with Apache and as far as the webserver goes, it runs flawlessly. I even have some subdomains using the same A record structure.
But...now I have two issues. First, I lost email reception. I can send via smtp and webmail but anything sent to my domain gets bounced back after 24 hours, even if sent to an alias or forwarder.
The second issue is that I need to verify the domain with Firebase and even thou I created the TXT record, it cannot be found by Google. I'm sure it's because of the same reason.
What can I do? I understand a little about DNS and records, but not enough for this. I just want all html traffic to reach my webserver as it is now and keep the emails and other domain services working as they were.
As contacting Godaddy support, they said it is not their purview as it is external. I think they just don't know. Go figure.
Are you using GoDaddys NameServers? If not and these are pointing elsewhere no matter what DNS records you set in GoDaddy won't be picked up during DNS lookips. This may explain why the TXT record verification is failing. However if this was true changing the A record wouldn'd disrupt DNS.
# just means the root domain so no subdomain/prefix, mydomain.com.
www is a common subdomain used so you could have an A record which like:
A www the.ip.addr.ess 1 hour
so www.mydomain.com would resolve to the.ip.addr.ess
MX records are used to direct emails to your mail server. Make sure this is pointing to the mail server. If it's pointing at your A record then updating the A record will disrupt this.
Set the MX record to point to the.ip.addr.ess rather then mydomain.com, or an A/CNAME record other then your root domain (which you are updating)
Other considerations may need to be taken, if you have an SPF record (TXT record) this may also need updating, depending on it's current value.
I finally found what I had to do. I needed an A record named 'mail' pointing to the original Godaddy server IP address.
A mail my.ip.add.ress. 1 hour
ThankĀ“s for all the help.

Setting up DNS record in Ionos hosted domain for SquareSpace

There seems to be a conflict between the DNS settings SquareSpace needs in order to set up a connection to the SquareSpace Analytics Search Console and what DNS settings Ionos will allow.
On Square Space the relevant setting are found at Home > Analytics > Connect followed by logging in with a gmail account and then clicking on Allow. At which we get the error message
Something went wrong
Sorry, something went wrong there. Please try again
I raised a query with SquareSpace and their response boils down to
There's one DNS record missing. You'd need to go into your domain's
DNS settings in your domain provider's end and then add the following
record:
Type: CNAME
Host: www
Points To: ext-cust.squarespace.com
Over to IONOS where the domain is registered and into the DNS settings which are currently
MX # mx00.1and1.co.uk
MX # mx01.1and1.co.uk
TXT # "v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de -all" -
CNAME _domainconnect _domainconnect.1and1.com Standard Record
CNAME autodiscover adsredir.1and1.info Standard Record
A ftp 198.185.159.144
and attempt to add a new record as per SquareSpace's instructions above, only to get the error message
A CNAME record can only be set for a subdomain. To alias your main domain please use Redirect
But looking at redirect I'm worried that, if I set this up, all the email addresses that use the same domain and Ionos' mail servers will fail. I seem to remember trying this exercise about 2 years ago, but managed to kill everyone's email accounts (!) until I removed it again.
Has anyone had this problem and solved it? It seems specific to SquareSpace / Ionos as they both give a standard set of instructions which they expect to work.
Later
After working with Ionos' customer service desk, they managed to add the required Squarespace DNS entry and they now read
TYPE HOST NAME VALUE SERVICE ACTIONS
CNAME autodiscover.www adsredir.1and1.info Standard Record
CNAME www ext-cust.squarespace.com -
CNAME autodiscover adsredir.1and1.info Standard Record
CNAME _domainconnect _domainconnect.1and1.com Standard Record
TXT # "v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de -all" -
MX # mx01.1and1.co.uk -
MX # mx00.1and1.co.uk -
A # 198.185.159.144
But the problem persists, something is still wrong when I try to attach the Google search console (AKA Squarespace Analytics Search Console -
Squarespace call it two different names in different parts of their site).
Having fixed the DNS entries to satisfy Squarespace, the "allow" error still persisted.
Squarespace customer service then suggested clearing the browser cache or using a different browser. Clearing the Chrome cache didn't work, but switching from Chrome to MS Edge did. Logging into our Squarespace account on Edge finally let the process run to completion.
I presume there must have been some information still cached in Chrome that Squarespace didn't like, I only cleared the temporary files, not the cookies or the history as I wanted to keep these for other sites.
The cause of the problem remains a mystery.

GitHub Pages: setting up custom domain

I've got an organization page set up and running in GitHub and things seem to be working...but I'm a little confused. I'd like to actually understand the process since the GitHub Help article refers to taking advantage of their CDN and DoS services, so bear with me.
Step 1: Created CNAME file in repo with domain 'example.com'
Step 2: Grabbed IP from dig example.github.io +nostats +nocomments +nocmd
Step 3: Entered IP from Step 2 into the 'A' record (see image below)
I decided to stop here and see where it got me, and to my surprise it seems to have done the trick. The example.github.io domain correctly redirects to the example.com domain and displays the content from the repo.
However I was informed that after the DNS props, you can dig example.com and see the CNAME record pointing to example.github.io. I do not see this, and I dislike thinking that I didn't set things up correctly. Any thoughts/comments/tips welcome, thanks!
In order to take advantage of the CDN and DoS services provided by GitHub Pages, you'll need to set up a Subdomain (eg www.example.com or blog.example.com) instead of an Apex domain (example.com).
From the GitHub Help page you referenced:
If you are using an apex domain (example.com) instead of a subdomain
(www.example.com) and your DNS provider does not support ALIAS
records, then your only option is to use A records for your DNS. This
will not give you the benefit of our Content Delivery Network.
Here's a setup (looks like you're using GoDaddy for DNS) that would work to get your Organization Pages working as desired:
This is actually for a Project Page within an Organization, but for either one, you'll set the CNAME record for www to organization.github.io, not something like organization.github.io/project. Don't change the A record for # (mine is the default from GoDaddy).
If you want to get your Apex domain (example.com) to redirect to the new subdomain (www.example.com), then you can point your Apex to your subdomain with Domain Forwarding like this:
With that setup, you'll get to take advantage of GitHub's CDN, which you may notice is provided through fastly. Here's how my domain looks to dig:
It is also possible to use a CNAME record for an APEX domain using the free DNS service provided by CloudFlare in which case you can also use your domain without the www (or any other subdomain) and still benefit from CDN & DoS.
I've written a step-by-step guide here: Speed up your GitHub Pages website with CloudFlare
PS: Apparently using ALIAS records is a bad idea... click here to see why.
DNS records are publicly available. There's no way of masking them in this instance. From the way you describe it, you have done everything right. There is nothing that makes me thing you set this up incorrectly.

domain name does not open the website, redirects to default IP instead of opening www

I recently changed NS of one domain to another host and created a domain using Helm Control Panel.
The problem is that when I type domain name (ie. www.MyDomain.com) instead of opening the coresponding website, it opens host webmail page which is served by smarter mail.
I have cleared dns cache, rebuilt and updated it. also I removed the domain and added it again.
Pinging the domain name returns server's IP address and it's up.
The hosting OS is windows server 2003.
I appreciate any comments to solve the problem.
Edit 1:
Though this was a long last headache, I solved the problem by removing domain's DNS entry alongside with all alias domains attached to it directly in DNS Server console, restarting server and then rebuilding DNS Zone via Helm Control Panel. I'm not sure if this was the best practice but it seems there was a mix of domain's DNS, alias domains' DNS, Hosting software, Caching problems.
Edit 2:
Actually this error was not about the DNS stuff, it is a failure of Helm Control Panel adding/removing alias domains. To share the experience, I Add a answer to this question.
This was not a DNS error.
I found the answer when examining IIS where i noticed the website was stopped.
Forcing the website to start, this error message poped up:
IIS was unable to start the site, another site may already be using the port you configured for this site.
Further investigation revealed that one same domain alias has previously added to another domain/host.
Removing this alias from IIS > Website Properties > Website > Advanced > Advanced Website Identification, fixed the problem.
What led me to assume a dns problem mistakenly was that default IP of server is set to mail server by default. so, when a website is stopped the domain points to mail server.
Hope this help for future.

Setup CNAME alias from one domain to another

I'm attempting to satisfy the Cookieless domain suggestion of Google's Page Speed plugin and am running into a wall with my host who can't be bothered with the details of why it's not working. Accessing st1.dgcstatic.com should be the same as accessing st1.defunctgames.com; however, this is not the case.
Have I missed a step of configuration? Do I need to wait for DNS propagation? You can see below my steps of experimentation.
DNS Setup:
Created CNAME of st1.dgcstatic.com to point to st1.defunctgames.com on dgcstatic.com
Created A record of st1.defunctgames.com on defunctgames.com
Created sub-domain of st1.defunctgames.com on defunctgames.com
When I run a tracert st1.dgcstatic.com it produces the following result:
C:\Users\Patrick>tracert st1.dgcstatic.com
Tracing route to st1.defunctgames.com [50.22.11.10]
When I run a host st1.dgcstatic.com it produces the following result:
patrick:~ patrick$ host st1.dgcstatic.com
st1.dgcstatic.com is an alias for st1.defunctgames.com.
st1.defunctgames.com has address 50.22.11.10
And finally, using this site it seems to produce the same results of showing things configured correctly.
http://www.mxtoolbox.com/SuperTool.aspx?action=mx%3ast1.dgcstatic.com
According to all these results, the world can see my DNS changes, my host on the other hand gave me the "Wait for propagation" rigmarole When asked why this isn't working.
It looks to me that your domain names are set up correctly (st1.dgcstatic.com is an alias of st1.defunctgames.com), but the web host needs to have a mapping or configuration to know how to serve st1.dgcstatic.com content.
Both domains are resolving to 50.22.11.10, but that is most likely a shared IP address host. (Visiting http://50.22.11.10 demonstrates that it's shared - it can't resolve to your site just by the IP address.)
You'll need to configure through your webhost provider the second domain. Hosting companies do this differently; in my case it's just a matter of adding a new domain to my account (extra $1/mo), and configuring the path for HTML source files.

Resources