Are both A records and CNAMES absolutely necessary?
Today we had a missed payment issue at wix.com that shut us down.
They disconnected the domain which I knew they could do but didn't expect them to do.
Once we paid though we expected to be able to reconnect and we were not able to due to their insistence that propagation on their end for the A record could take up to 48 hours to occur.
This is disappointing to me to say the least, especially since Google Domains said that TTL (time-to-live) should be one hour or less.
At least they were nice enough to tell us how to keep it from happening in the future and those instructions were to let domains.google.com (now owned by Squarespace) manage the name servers and simply point the A record to the IP address for tptxdev.com to their primary name server at 185.230.63.107, and then change the CNAME record of www.tptxdev.com to reflect the CNAME pointing.wixdns.net instead of their old CNAME which was gcdn0.wixdns.net
To show the propagation status outside of Wix, they were also nice enough to provide this resource for both the A record propagation https://www.whatsmydns.net/#A/tptxdev.com and the CNAME propagation https://www.whatsmydns.net/#CNAME/www.tptxdev.com.
Even though propagation looks good still can't access the site at tptpxdev.com but they are insisting on 48 hours before they are even willing to look into it any deeper.
From what I have understood in previous conversations about setting up domain name structures is that the A record is all that is needed, so why would they ask for the CNAME record to be changed as well?
Is the addition of the new CNAME record really necessary and could that be one of the issues causing the tptxdev.com domain it not to come up?
# dig tptxdev.com +trace +nodnssec
; <<>> DiG 9.16.42 <<>> tptxdev.com +trace +nodnssec
;; global options: +cmd
. 392632 IN NS f.root-servers.net.
. 392632 IN NS m.root-servers.net.
. 392632 IN NS a.root-servers.net.
. 392632 IN NS b.root-servers.net.
. 392632 IN NS j.root-servers.net.
. 392632 IN NS i.root-servers.net.
. 392632 IN NS h.root-servers.net.
. 392632 IN NS d.root-servers.net.
. 392632 IN NS g.root-servers.net.
. 392632 IN NS c.root-servers.net.
. 392632 IN NS e.root-servers.net.
. 392632 IN NS k.root-servers.net.
. 392632 IN NS l.root-servers.net.
;; Received 851 bytes from 192.168.x.x#53(192.168.x.x) in 0 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
;; Received 836 bytes from 202.12.27.33#53(m.root-servers.net) in 9 ms
tptxdev.com. 172800 IN NS ns-cloud-e1.googledomains.com.
tptxdev.com. 172800 IN NS ns-cloud-e2.googledomains.com.
tptxdev.com. 172800 IN NS ns-cloud-e3.googledomains.com.
tptxdev.com. 172800 IN NS ns-cloud-e4.googledomains.com.
;; Received 334 bytes from 192.43.172.30#53(i.gtld-servers.net) in 21 ms
tptxdev.com. 3600 IN A 185.230.63.107
;; Received 89 bytes from 216.239.36.110#53(ns-cloud-e3.googledomains.com) in 34 msdig www.tptxdev.com
; <<>> DiG 9.16.42 <<>> www.tptxdev.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53355
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e3115ac314150d2c0100000065b0df4f00453a259ca3b677 (good)
;; QUESTION SECTION:
;www.tptxdev.com. IN A
;; ANSWER SECTION:
www.tptxdev.com. 3600 IN CNAME pointing.wixdns.net.
pointing.wixdns.net. 300 IN CNAME cdn1.wixdns.net.
cdn1.wixdns.net. 264 IN CNAME td-ccm-neg-87-45.wixdns.net.
td-ccm-neg-87-45.wixdns.net. 3224 IN A 34.149.87.45
;; Query time: 18 msec
;; SERVER: 192.168.x.x#53(192.168.x.x)
;; WHEN: Wed Jan 24 10:58:39 CET 2024
;; MSG SIZE rcvd: 171This doesn't look wrong to me
# curl -v https://www.tptxdev.com >/dev/zero
* Trying 34.149.87.45:443...
* Connected to www.tptxdev.com (34.149.87.45) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [15 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [4463 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server accepted h2
* Server certificate:
* subject: CN=tptxdev.com
* start date: Dec 29 00:00:00 2023 GMT
* expire date: Mar 28 23:59:59 2024 GMT
* subjectAltName: host "www.tptxdev.com" matched cert's "www.tptxdev.com"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
* SSL certificate verify ok.
} [5 bytes data]
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://www.tptxdev.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: www.tptxdev.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.4.0]
* [HTTP/2] [1] [accept: */*]
} [5 bytes data]
> GET / HTTP/2
> Host: www.tptxdev.com
> User-Agent: curl/8.4.0
> Accept: */*
>
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [251 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [251 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
< HTTP/2 200
< content-type: text/html; charset=UTF-8
< link: <https://static.parastorage.com/>; rel=preconnect; crossorigin;,<https://static.parastorage.com/>; rel=preconnect;,<https://static.wixstatic.com/>; rel=preconnect; crossorigin;,<https://static.wixstatic.com/>; rel=preconnect;,<https://siteassets.parastorage.com>; rel=preconnect; crossorigin;,
< etag: W/"abd28bac001991e7f0671c4572e013e3"
< content-language: en
< strict-transport-security: max-age=3600
< x-wix-request-id: 1706090403.7954491031194427890
< cache-control: public,max-age=0,must-revalidate
< server: Pepyaka/1.21.6
< x-content-type-options: nosniff
< accept-ranges: bytes
< date: Wed, 24 Jan 2024 10:00:03 GMT
< age: 28604
< x-served-by: cache-ams21063-AMS
< x-cache: MISS
< vary: Accept-Encoding
< server-timing: cache;desc=hit, varnish;desc=hit_miss, dc;desc=fastly_84_g
< set-cookie: ssr-caching=cache#desc=hit#varnish=hit_miss#dc#desc=fastly_84_g; max-age=20
< x-seen-by: yvSunuo/8ld62ehjr5B7kA==,yI4PPEXc3bvXNWfpzSkUarxkNjrXdwdgtu6E0yACibU=,m0j2EEknGIVUW/liY8BLLm+RUUxFrhyTYE58WvxHjklsl0ueLMGCVziLUYuJmnC9,2d58ifebGbosy5xc+FRalpwDJdx7NPfpSMB4h8D4d4BCTeav0bO/bbSPrwncx+tg33tFFdbLtmrARazvfvDAIQ==,2UNV7KOq4oGjA5+PKsX47PQEXbXFZaYW1Dg5frPZCM1YgeUJqUXtid+86vZww+nL
< via: 1.1 google
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
<
{ [31456 bytes data]About propagation.... DNS works differently from what most people expect i guess.
There is NO DNS server that has all knowledge. It is a forrest of trees of DNS servers. Where many have redundant options like the root server (dishing out .) and the gtld servers for .com , .org ... etc.
(see above traces).
If your program needs a translation from name -> number then your system will ask it "known" DNS server for this (conficured through mostly network DHCP options).
That DNS looks inside it's cache of previous answers (if it has one) and serves the value found (what ever it is)....
If it is Not in the cache then the DNS server asks it's upstream DNS server for Help... which does the same... until there is no more upstream DNS server... THAT DNS server then needs to do a recursive lookup...
Start searching for the root server (those are in Cache - preloaded during boot of the DNS server, with indefinite TTL = Time To Live),
ans ask those root servers for the DNS servers (NS+ A/AAAA) of the Last part of the name, in your case .COM, then ask those for the DNS servers (NS + A/AAAA) of the domain name (tptxdev.com) on those etc. until it reaches the actual name....
THAT DNS server that serves the name will also tell how long it is allowed to cache that name (TTL) ...
Each DNS will cleanup it's cache regularly for stale records whose TTL has expired....
If the data is still "valid"... (according to TTL) but not in the real world because a system changed IP address etc. then tough luck..., the cached data will be served.
So you maybe have moved to a new IP address, and that needs to weed out of the system. Hence the disclaimer may take 48 hours.
Some changes may take a few weeks before they materialize.
It is IMPOSSIBLE to do a top/down reset of all DNS caches of all DNS servers in the world.
The ones that are the primary/secondary server are updated immediately, all others may take a while before they update (after a cache cleanup).
It does take 'some' time for DNS propogation and 48 hours sounds like the sort of times we were quoting 5-10 years ago. The truth is you can force propogation (DNS is query based - as soon as the record is updated its resolvable - but it does take time to get 'cached' downstream
I use DNS to failover my website - I cant be wating 48 hours!!! I 'Clobber Public DNS with requests to propogate if globally a lot quicker - just use thishttps://www.whatsmydns.net/#A/www.petenetlive.com keep hitting search and it will roll thouhgh its list of global DNS servers. I can fail my site over in a couple of minutes - yes some DNS server(s) will have cached the old IP and I will need to wait for those caches to time out/expire, but I can live with that.
</P>
It also means that in stead of one query on a DNS every hour (TTL=3600) or so, it will become 60 or 6 queries / hour for the name involved.
(ie there is a tradeoff between TTL and number of queries / hour..., you mostly pay for the latter as it costs bandwidth).
Bombarding a PUBLIC DNS server with queries will NOT make the record disappear from cache, that only happens when the TTL counts down to 0... no amount of querying will help on that, unless you can force a DNS server to restart... meaning it is DDOSable. (effectively the cache has a time ordered index on all records and decrements the counters every second).
On DNS server you do control.... you can flush the cache obviously..., the first upstream one of your ISP is already out of reach.
Changing name servers can take 48 hrs before cached name server records stop being used, no matter what TTL you have. Could that be the reason for the delay?
That's correct. As I mentioned in my earlier comment, there are DNS resolvers out there that do not honor TTL values.
They are a relative minority, but it's enough that some places will just wait for 48 hours to play it safe.
ASKER
Once everything is working, what would be the repercussions for me of only having the A record and eliminating the CNAME record that the phone rep said is required?