I am trying to create a subdomain using DirectAdmin. The subdomain will be finance.nickputman.com
I appear to have successfully created the subdomain in that there are A records for finance and www.finance showing under 'DNS management', and when I carry out an online DNS propagation check for the A records, all reports come back as successful.
And yet when I try to visit http://finance.nickputman.com I get a server not found error. http://nickputman.com/finance works OK.
Is there another step I need to take to get this working?
It takes some time before new/changed dns records are fetched by your local dns cache (depending on the TTL values of the old records). Manually clear the dns cache to force an update.
Related
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.
We have a website that we recently revamped.
The domain it lived on use to have a CNAME record for # and www pointing to a different domain while the site was being developed.
We have now deployed the site (48+ hours ago) and chrome users who have previously visited the site are still being redirected to the domain the old CNAME pointed to.
The new DNS configuration is an # record pointing to the server and the a CNAME for www that also points to the same server (but a proxy).
We cannot figure out how to get existing users on chrome to pick up these DNS changes, if a user is to clear their browser cache, the site will work just fine. That said we cannot tell thousands of users to clear their cache.
Does anyone know how we can get users to pick up the new records?
The original TTL on the site was set to AUTO on cloudflare through the cloudflare proxy. I'm told this makes the TTL around 5 mins however its been over 48 hours and users are still having this issue. We have also purge the cache on cloudflare multiple times.
The answer was the TTL on each record, you just have to wait it out
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.
I deployed my node js app properly on heroku and it's working fine with the heroku provided domain name.
Now, I'm trying to link it with my personal domain name. On the heroku website, in the settings section of my app hosted by heroku, I have setup the domain name to be my-app.com and my heroku dns is set to my-app.com.herokudns.com
In 1&1, I have registered a domain name my-app.com that I redirect to www.my-app.com
Still in 1&1, I have then created a sub-domain called www.my-app.com, in which I have set the DNS CNAME to my-app.com.herokudns.com
I saved everything but when I go to www.my-app.com, the url shows www.my-app.com/defaultsite in which the content shows a heroku generic page telling me There's nothing here, yet. Build something amazing.
Could anyone has a clue on what may be missing to connect to my app ?
DNS changes take time to propagate through the network. Very often you'll have to wait before seeing them take effect.
This can be somewhat mitigated by setting your records' time to live (TTL). This value specifies an expiry time for your records after which cached values should be re-fetched from the authoritative server:
Shorter TTLs can cause heavier loads on an authoritative nameserver, but can be useful when changing the address of critical services like Web servers or MX records, and therefore are often lowered by the DNS administrator prior to a service being moved, in order to minimize disruptions.
Note that if you are planning to change a DNS record its TTL should be lowered far enough before the change is made that old values will already have expired. For example, if the record you plan to change has a TTL of 86400 seconds (24 hours) you should decrease it at least 24 hours before modifying its value.
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