NS change stuck after 4+ days

[user13684]

On 12/3 @10:30 PM Eastern, NS were adjusted to Cloudflare per settings in my dashboard; these changes haven’t propagated yet, and I’m trying to figure it out.

There are plenty of posts to review on this topic, I used this one as a guide prior to posting.

This shows the problem: DNS Checker - DNS Check Propagation Tool

I got as far as running this on my own, but I don’t understand the implication:

Command: dig thinkbiglittleone.com @1.1.1.1 NS +short
Result: maya.ns.cloudflare.com.
santino.ns.cloudflare.com.

Command: thinkbiglittleone.com @1.1.1.1 NS +trace
Result: (trimmed due to length)
I see the requests bouncing to my old NS’s and then getting the Cloudflare, which I assume is part of the problem - but I don’t know why.

I used the purge cache feature here in order to see if I could fix it without posting here but that didn’t seem to fix it either from CF’s perspective.

If it helps, I created a test A record that only exists at Cloudflare - cf.thinkbiglittleone.com and it’s resolving at 1.1.1.1 and 8.8.8.8 - yet Cloudflare’s tools says I haven’t updated my NS yet.

What am I missing in order to be able to get my NS fully out in the wild?

[sdayman]

It looks like you only update NS records in existing DNS. As your domain is registered at AWS, you need to update WHOIS at Amazon for the new name servers.

[user13684]

Thank you! I’ll take that on.

I updated the Route 53 hosted zone for the domain which I thought was enough, but I can see those name servers at the domain registry section.

FWIW, I did the below dig command to one of those listed NS’s, and it did give me the expected result - so it’s odd to me that it’s working at all!

dig @ns-1242.awsdns-27.org thinkbiglittleone.com ns

; <<>> DiG 9.16.1-Ubuntu <<>> @ns-1242.awsdns-27.org thinkbiglittleone.com ns
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58104
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;thinkbiglittleone.com.         IN      NS

;; ANSWER SECTION:
thinkbiglittleone.com.  600     IN      NS      maya.ns.cloudflare.com.
thinkbiglittleone.com.  600     IN      NS      santino.ns.cloudflare.com.

;; Query time: 20 msec
;; SERVER: 205.251.196.218#53(205.251.196.218)
;; WHEN: Wed Dec 08 12:17:54 EST 2021
;; MSG SIZE  rcvd: 105

[user13684]

That was what the missing piece of the puzzle was - thanks @sdayman !

It was fixed in a few minutes after updating R53 domain level NS’s and then asking CF to update.

[garret]

This is a very common gotcha when onboarding your zone (domain) to Cloudflare. The tl;dr is we require you set Cloudflare nameservers as authoritative (e.g. at your domain registrar) when using a full setup. You effectively delegated thinkbiglittleone.com to Cloudflare (instead of making us authoritative zone wide). Thus the site won’t activate.

You can check this using whois (as @sdayman did):

whois thinkbiglittleone.com
...
Name Server: maya.ns.cloudflare.com
Name Server: santino.ns.cloudflare.com

Alternatively you can use dig but make sure to set +trace so you can see the entire chain including the actual authoritative NS for the zone (not just see the delegated ones as you showed).

For example, below you can query for you zone currently where we see that the authoritative NS for thinkbiglittleone.com are now your assigned Cloudflare nameservers:

$ dig thinkbiglittleone.com ns +trace +nodnssec

; <<>> DiG 9.10.6 <<>> thinkbiglittleone.com ns +trace +nodnssec
;; global options: +cmd
.			509911	IN	NS	a.root-servers.net.
.			509911	IN	NS	b.root-servers.net.
.			509911	IN	NS	c.root-servers.net.
.			509911	IN	NS	d.root-servers.net.
.			509911	IN	NS	e.root-servers.net.
.			509911	IN	NS	f.root-servers.net.
.			509911	IN	NS	g.root-servers.net.
.			509911	IN	NS	h.root-servers.net.
.			509911	IN	NS	i.root-servers.net.
.			509911	IN	NS	j.root-servers.net.
.			509911	IN	NS	k.root-servers.net.
.			509911	IN	NS	l.root-servers.net.
.			509911	IN	NS	m.root-servers.net.
;; Received 811 bytes from 192.0.2.2#53(192.0.2.2) in 55 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.
;; Received 846 bytes from 192.58.128.30#53(j.root-servers.net) in 12 ms

thinkbiglittleone.com.	172800	IN	NS	maya.ns.cloudflare.com.
thinkbiglittleone.com.	172800	IN	NS	santino.ns.cloudflare.com.
;; Received 369 bytes from 192.41.162.30#53(l.gtld-servers.net) in 40 ms

thinkbiglittleone.com.	86400	IN	NS	maya.ns.cloudflare.com.
thinkbiglittleone.com.	86400	IN	NS	santino.ns.cloudflare.com.
;; Received 105 bytes from 2803:f800:50::6ca2:c301#53(santino.ns.cloudflare.com) in 19 ms

Hopefully that helps explain why it appears everything was set correctly but Cloudflare didn’t activate the zone. I always recommend using whois to ensure you know you are looking at authoritatively set nameservers.