Cloudflare DNS validation for GitHub Page

To bypass local DNS settings using dig, you can query an external DNS server directly or use a tracing method to resolve the domain from the root. 

1. Specify a Specific DNS Server 

By default, dig uses the resolvers configured in your system’s resolv.conf. You can override this by adding @ followed by the IP address of a public or external DNS server. 

• Google DNS: dig @8.8.8.8 example.com
• Cloudflare DNS: dig @1.1.1.1 example.com
• Quad9 DNS: dig @9.9.9.9 example.com 

2. Use DNS Tracing 

If you want to bypass your ISP or local resolver entirely and see the resolution path from the internet’s root servers down to the authoritative server, use the +trace flag. This effectively bypasses local caching. 

• Command: dig example.com +trace 

3. Query Authoritative Servers Directly 

If you know the authoritative name servers for a domain, you can query them directly to ensure you are getting the most up-to-date record rather than a cached version from a recursive resolver. 

1. Find the authoritative name servers: dig example.com NS
2. Query one of those servers directly: dig @ns1.example.com example.com 

Important Context for 2026

• Application-Level DNS: Some modern applications (like browsers) may use DNS over HTTPS (DoH), which ignores system-level tools like dig.
• Local Caching Daemons: If your system uses local caching daemons like systemd-resolved, nscd, or dnsmasq, dig might still see cached results unless you specify an external server or use +trace. 

** Notice the following only shows two A & AAAA records **

 dig remote-tech.us +noall +answer -t A
                                                                                                                                         
remote-tech.us.		300	IN	A	104.21.74.121
remote-tech.us.		300	IN	A	172.67.158.91
----------------------------------------------------------------------------------
~/work/myBASH/devops-bash-lib (main*) » dig remote-tech.us +noall +answer -t AAAA                                                                                                                                      

remote-tech.us.		300	IN	AAAA	2606:4700:3033::6815:4a79
remote-tech.us.		300	IN	AAAA	2606:4700:3032::ac43:9e5b

Cloudflare “Proxy” (Orange Cloud) vs. “DNS Only” (Grey Cloud) 

When a record is Proxied (Orange Cloud) in Cloudflare, Cloudflare hides your actual server IP and replaces it with its own Anycast IPs. 

• The 172.x and 104.x IPs in your dig output are Cloudflare’s edge IPs, not your origin server’s IPs.
• Cloudflare typically returns two A records and two AAAA records for a proxied site to ensure high availability. 

Why you don’t see your “Real” IP

Because your Cloudflare settings have the Proxy Status set to “Proxied” (Orange Cloud), Cloudflare replaces your origin server’s IP addresses with their own Anycast addresses. This provides DDoS protection and CDN benefits.

How to see the “Real” IP via dig

If you want dig to show your actual server IP instead of Cloudflare’s, you have two options:

Option A: Change Cloudflare Settings (Not recommended for production)
In the Cloudflare DNS dashboard, change the records from Proxied to DNS Only (Grey Cloud). Wait ~5 minutes for the 300-second TTL to expire, and dig will then show your real IP.

Option B: Query the Authoritative Server directly to bypass Google’s Cache
Even though you are bypassing local DNS by using @8.8.8.8, Google might still be holding a cached version. To get the “freshest” data possible directly from the source, query your assigned Cloudflare nameservers directly:

dig @grant.ns.cloudflare.com remote-tech.us A
dig @grant.ns.cloudflare.com remote-tech.us AAAA

Note: Even when querying Cloudflare directly, if the “Orange Cloud” is enabled, Cloudflare will still return their proxy IPs. This is the intended behavior of the service.

I CONFIRMED DNS RECORDS WERE SET TO ORANGE CLOUD (DNS-PROXY)

The Conflict: “Proxied” vs. “DNS Only”

In Cloudflare, if you have multiple records for the same name (e.g., remote-tech.us), Cloudflare applies a “Proxied” (Orange Cloud) logic to all of them if even one of them is toggled to Proxied.

In your current setup:

• A Record 185.199.109.153 is set to Proxied.
• AAAA Records are all set to Proxied.

Because of this, Cloudflare’s edge network intercepts the request for remote-tech.us. Instead of returning your four specific GitHub A records, it returns its own Anycast IPs (172.67.158.91 and 104.21.74.121) to act as a middleman.

How to fix it (Two Options)

Option 1: You want Cloudflare Protection (Recommended)

If you want to keep the “Orange Cloud” features (DDoS protection, SSL, etc.), dig will never show your 185.199.x.x IPs to the public. This is working as intended.

• To fix your dashboard inconsistency, change the other three A records (110.153, 111.153, 108.153) to Proxied so they match the first one.

Option 2: You want dig to show your Real IPs

If you want the world to see your GitHub IPs directly and bypass Cloudflare’s proxy:

1. Go to the Cloudflare DNS dashboard.
2. Change all A and AAAA records for remote-tech.us from Proxied to DNS Only (Grey Cloud).
3. Wait about 5 minutes.
4. Run dig @8.8.8.8 remote-tech.us again. You will then see all four 185.199.x.x addresses.

Summary of why dig showed what it did:

• The A records: Cloudflare saw you had one record proxied, so it hid all your A records and gave dig the Cloudflare IPs (172.67...).
• The AAAA records: Since all your AAAA records were proxied, Cloudflare gave dig its own IPv6 addresses instead of your 2606:50c0... addresses.

To verify what Cloudflare is “seeing” internally without the proxy interference, use this specific dig command:
dig @grant.ns.cloudflare.com remote-tech.us +trace

GitHub Pages generally works best with Grey Cloud (DNS Only), especially during the initial setup and certificate renewal phases. 

Use Grey Cloud (DNS Only) if:

• You are setting up the domain for the first time: GitHub needs to see your DNS records directly to verify ownership and issue an SSL certificate.
• You want GitHub to manage your SSL: GitHub uses Let’s Encrypt for custom domains. If the Orange Proxy is on, GitHub’s automated renewal process will fail because it cannot “see” the origin server through Cloudflare’s proxy.
• You want to “Enforce HTTPS” in GitHub settings: This setting often remains disabled or fails if the proxy is active during the verification check. 

Use Orange Cloud (Proxied) if: 

• You want Cloudflare’s specific features: This includes DDoS protection, Web Application Firewall (WAF), and Cloudflare’s global caching.
• You have already generated a GitHub SSL certificate: You can technically turn the proxy on after the certificate is live, but you must remember to turn it back to Grey every 3 months for renewal. 

Recommended 2026 Strategy

1. Set all A and AAAA records to Grey Cloud (DNS Only) in Cloudflare.
2. Go to your GitHub Repository Settings > Pages and add your custom domain.
3. Wait for the DNS check and TLS certificate to show as successful/issued in GitHub.
4. Keep it Grey permanently to avoid manual renewal issues every 3 months. 

Note: Since GitHub Pages already uses a global CDN (Fastly), you still get high performance even with Cloudflare set to “DNS Only”

dig @8.8.8.8 remote-tech.us                                                                                                                                                

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> @8.8.8.8 remote-tech.us
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58459
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;remote-tech.us.			IN	A

;; ANSWER SECTION:
remote-tech.us.		300	IN	A	172.67.158.91
remote-tech.us.		300	IN	A	104.21.74.121

;; Query time: 32 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Jan 23 13:38:40 EST 2026
;; MSG SIZE  rcvd: 75

dig <strong><mark style="background-color:rgba(0, 0, 0, 0)" class="has-inline-color has-black-color">@1.1.1.1</mark></strong> remote-tech.us                                                                                                                                                    

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> @1.1.1.1 remote-tech.us
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21762
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;remote-tech.us.			IN	A

;; ANSWER SECTION:
remote-tech.us.		300	IN	A	104.21.74.121
remote-tech.us.		300	IN	A	172.67.158.91

;; Query time: 28 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Fri Jan 23 13:39:17 EST 2026
;; MSG SIZE  rcvd: 75

dig @1.1.1.1 remote-tech.us +trace                                                                                                                                             

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> @1.1.1.1 remote-tech.us +trace
; (1 server found)
;; global options: +cmd
.			516286	IN	NS	a.root-servers.net.
.			516286	IN	NS	b.root-servers.net.
.			516286	IN	NS	c.root-servers.net.
.			516286	IN	NS	d.root-servers.net.
.			516286	IN	NS	e.root-servers.net.
.			516286	IN	NS	f.root-servers.net.
.			516286	IN	NS	g.root-servers.net.
.			516286	IN	NS	h.root-servers.net.
.			516286	IN	NS	i.root-servers.net.
.			516286	IN	NS	j.root-servers.net.
.			516286	IN	NS	k.root-servers.net.
.			516286	IN	NS	l.root-servers.net.
.			516286	IN	NS	m.root-servers.net.
.			516286	IN	RRSIG	NS 8 0 518400 20260205050000 20260123040000 21831 . gjZLuUiQ+GE7iLdyBGDDn4Jx4arz7IEhl5kaLLsS09Uy7smf+pKgUYnG 5EGO35njT1osOpIctv91rEm+wlxx0uG8mm/1i4R0Fu4H/CPUNTarnMAi m9odIxuXkqSHSH/HLYAsRCdxUSzsK7rjhoAmZSUzvkNkH656rhbYOqYE zbgOydVFVE/kkLOx7PJPP5Spf0I7O59flwl6H+ZJnL70lxvVGsLVBQUF UwI68yCj0y9dE6OjZtyksVKB/kUex7VuetpPcEkfSgOPuLEsXn5C3o9V tOyYqvqJx4NdX6gh8UbyxwRQPjDk/R55d7lFk8i1ZbuT0+7LxNXURBMb HhrI1w==
;; Received 525 bytes from 1.1.1.1#53(1.1.1.1) in 16 ms

us.			172800	IN	NS	b.cctld.us.
us.			172800	IN	NS	f.cctld.us.
us.			172800	IN	NS	k.cctld.us.
us.			172800	IN	NS	m.cctld.us.
us.			172800	IN	NS	n.cctld.us.
us.			172800	IN	NS	w.cctld.us.
us.			172800	IN	NS	x.cctld.us.
us.			172800	IN	NS	y.cctld.us.
us.			86400	IN	DS	59017 8 2 7DAF469D42B5D8E5537FD4DD4B6057710E9A61F72C32EB7FB6526F52 277EC2B0
us.			86400	IN	RRSIG	DS 8 1 86400 20260205170000 20260123160000 21831 . dUHHAMOJiJ7+reGyz1NkHhpASDxwyRXBeRrsr5iW/5U49aDZynau7K4n jdjTBl48GAD2ef3Zb/nxi0p3DmVz6HYNIb52qaYVF6YcIfMKTx7WOGd1 KKha8szHq9fd3gkHaXL8MD7ByXFOJZehenlgLOHCDdvSkLkGzlePxdQd 6MZVMhXDj+OvZk4JmZTgUkX51tNwf2oE+pEhIZ/mOjoamJU1HnIlaLE+ BdiSj50YoqiuT6RYlqaqku8uU8m4wdRbpA8zyebzMN5r7txCspLC8GZ0 kyBdQvYjEtnTp6gtqgGcLRcA0+Op9Rwh6FcQZfXCHaphAmUl26RIqPAm PUhYpw==
;; Received 864 bytes from 199.7.91.13#53(d.root-servers.net) in 28 ms

remote-tech.us.		3600	IN	NS	grant.ns.cloudflare.com.
remote-tech.us.		3600	IN	NS	rosalyn.ns.cloudflare.com.
remote-tech.us.		3600	IN	DS	2371 13 2 F7130FC1787D11AF9D24A9C37A8829A452CB696928884A71473F3B74 5CD49D3F
remote-tech.us.		3600	IN	RRSIG	DS 8 2 3600 20260203183000 20260120181919 54159 us. HcVGqxKLQ+vrHW7GdvG8NW9B1zWu+hTcAxxmi4l9K9we+tuK5bF+kiU/ 6Z9gd0qNuSvZSFj1x0587M/0aMRqol1K8Yh0eZr+V9V0KoVtPmQ+B94y mZsmGv0RFxuTszzAbo3K87GgJC+43E9DGMefI0CxDslI9/oEqzqNXdGK UGOf1pUVk+RgOBJp9rfN72hRwpeV0vG2MkaSpSmoORP6Zw==
;; Received 372 bytes from 204.74.107.1#53(n.cctld.us) in 32 ms

;; UDP setup with 2606:4700:50::a29f:263b#53(2606:4700:50::a29f:263b) for remote-tech.us failed: network unreachable.
;; no servers could be reached
;; UDP setup with 2606:4700:50::a29f:263b#53(2606:4700:50::a29f:263b) for remote-tech.us failed: network unreachable.
;; no servers could be reached
;; UDP setup with 2606:4700:50::a29f:263b#53(2606:4700:50::a29f:263b) for remote-tech.us failed: network unreachable.
;; UDP setup with 2803:f800:50::6ca2:c23b#53(2803:f800:50::6ca2:c23b) for remote-tech.us failed: network unreachable.
;; UDP setup with 2a06:98c1:50::ac40:2382#53(2a06:98c1:50::ac40:2382) for remote-tech.us failed: network unreachable.
remote-tech.us.		300	IN	A	172.67.158.91
remote-tech.us.		300	IN	A	104.21.74.121
remote-tech.us.		300	IN	RRSIG	A 13 2 300 20260124193935 20260122173935 34505 remote-tech.us. JKsJEFZ3XTK+/fyByAkg4E9/R73LClqoIKw+wFDk0PzFL1VvMYCKFLEI +3AEXzz4x3mOiD42/P0exrQpbIqYuQ==
;; Received 185 bytes from 172.64.34.59#53(rosalyn.ns.cloudflare.com) in 16 ms

dig @8.8.8.8 remote-tech.us NS                                                                                                                                           

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> @8.8.8.8 remote-tech.us NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59389
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;remote-tech.us.			IN	NS

;; ANSWER SECTION:
remote-tech.us.		21600	IN	NS	grant.ns.cloudflare.com.
remote-tech.us.		21600	IN	NS	rosalyn.ns.cloudflare.com.

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Jan 23 13:41:50 EST 2026
;; MSG SIZE  rcvd: 102

dig @8.8.8.8 remote-tech.us AAAA

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> @8.8.8.8 remote-tech.us AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60267
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;remote-tech.us. IN AAAA

;; ANSWER SECTION:
remote-tech.us. 300 IN AAAA 2606:4700:3033::6815:4a79
remote-tech.us. 300 IN AAAA 2606:4700:3032::ac43:9e5b

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Jan 23 13:42:44 EST 2026
;; MSG SIZE rcvd: 99

AFTER CHANGING DNS RECOREDS TO GREY CLOUD (DNS-ONLY)

dig @8.8.8.8 remote-tech.us AAAA                                                                                                                                               

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> @8.8.8.8 remote-tech.us AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16780
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;remote-tech.us.			IN	AAAA

;; ANSWER SECTION:
remote-tech.us.		300	IN	AAAA	2606:50c0:8001::153
remote-tech.us.		300	IN	AAAA	2606:50c0:8003::153
remote-tech.us.		300	IN	AAAA	2606:50c0:8000::153
remote-tech.us.		300	IN	AAAA	2606:50c0:8002::153

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Jan 23 13:50:50 EST 2026
;; MSG SIZE  rcvd: 155

dig @8.8.8.8 remote-tech.us A                                                                                                                                                  

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> @8.8.8.8 remote-tech.us A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42916
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;remote-tech.us.			IN	A

;; ANSWER SECTION:
remote-tech.us.		300	IN	A	185.199.109.153
remote-tech.us.		300	IN	A	185.199.108.153
remote-tech.us.		300	IN	A	185.199.110.153
remote-tech.us.		300	IN	A	185.199.111.153

;; Query time: 20 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Jan 23 13:50:53 EST 2026
;; MSG SIZE  rcvd: 107

dig @8.8.8.8 remote-tech.us CNAME                                                                                                                                              

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> @8.8.8.8 remote-tech.us CNAME
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17772
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;remote-tech.us.			IN	CNAME

;; AUTHORITY SECTION:
remote-tech.us.		1800	IN	SOA	grant.ns.cloudflare.com. dns.cloudflare.com. 2394679852 10000 2400 604800 1800

;; Query time: 20 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Jan 23 13:52:14 EST 2026
;; MSG SIZE  rcvd: 106

Yes, this is now showing correctly for a GitHub Pages configuration on an apex domain (remote-tech.us).

Analysis of your results:

1. The A Records (Success):
   Your query for remote-tech.us returned the four GitHub Anycast IPs (185.199.108.153 through .111.153). This confirms the Grey Cloud is active and the records are propagating.
   • Note: Even though you typed ALIAS in your command, dig defaulted to an A record lookup because ALIAS is a virtual record type used by providers (like Cloudflare) but is not a standard DNS query type recognized by public resolvers like 8.8.8.8.
2. The CNAME Record (Correctly Empty):
   Your query for a CNAME at remote-tech.us returned 0 answers. This is correct.
   • The Reason: Per DNS RFC standards, you cannot have a CNAME on an apex domain (the root domain without www). If you tried to add one, Cloudflare would use “CNAME Flattening” to turn it into A records anyway.
   • For GitHub Pages, the apex domain (remote-tech.us) should always use A records (as you have now), while the sub-domain (www.remote-tech.us) should usually be a CNAME pointing to your GitHub username (e.g., username.github.io).

What to do next:

1. Check IPv6: Run dig @8.8.8.8 remote-tech.us AAAA to ensure your four 2606:50c0... records are also showing correctly as Grey Cloud.
2. Verify in GitHub:
   • Go to your GitHub Repository Settings.
   • Under GitHub Pages, click the Check DNS or Save button.
   • Wait for the “DNS check successful” message.
   • Enforce HTTPS: Once the certificate is issued (can take up to 24 hours, but usually 10-15 minutes), check the Enforce HTTPS box.

Your DNS is now perfectly “transparent,” allowing GitHub to verify your domain and issue the SSL certificate without Cloudflare’s proxy interfering.

Final Verification

• A Records: Pointing to GitHub’s IPv4 range (185.199.x.x).
• AAAA Records: Pointing to GitHub’s IPv6 range (2606:50c0:8000::153 through 8003).
• Proxy Status: Cloudflare’s proxy is successfully bypassed (Grey Cloud), as evidenced by the return of these specific GitHub IPs rather than Cloudflare’s 172.x or 104.x addresses.

Next Step in GitHub

You should now head to your GitHub Pages Settings for this repository:

1. Click “Verify” or “Save” on your custom domain.
2. Wait for the “DNS check successful” banner.
3. Ensure “Enforce HTTPS” is checked (this may be greyed out for a few minutes while the certificate is issued).

Warning: Since you are using an apex domain (remote-tech.us), ensure you have also set up a CNAME for the www subdomain pointing to your GitHub Pages URL (e.g., yourusername.github.io) in Cloudflare. This ensures that visitors typing www.remote-tech.us also reach your site

A Note on the “www” Subdomain

If you plan to use www.remote-tech.us as well, ensure you have a CNAME record in Cloudflare for www pointing to remote-tech-us.github.io. GitHub will actually issue a single certificate that covers both the apex and the www subdomain, but only if both DNS records are correctly pointing to GitHub.

Once the certificate is issued, the “Enforce HTTPS” checkbox will automatically become clickable. You should check it immediately at that point to ensure all traffic is secure.

Why you should switch to Grey Cloud

• SSL Generation: GitHub needs to verify ownership of both remote-tech.us (the apex) and www.remote-tech.us to issue a single certificate that covers both. If the www record is proxied (Orange), GitHub’s verification probe will see Cloudflare’s IP instead of the intended GitHub target, which can cause the certificate request to hang or fail.
• Enforcing HTTPS: Once you have both records as Grey Cloud, GitHub will be able to verify your DNS and enable the “Enforce HTTPS” checkbox. 

Recommended Workflow for 2026

1. Set to Grey Cloud: Change the www CNAME to DNS Only.
2. Wait for SSL: Refresh your GitHub Pages settings until the “Enforce HTTPS” checkbox becomes active (usually 15–60 minutes).
3. Check the Box: Enable “Enforce HTTPS” in GitHub.
4. Optional – Re-Proxy: Once the site is live and HTTPS is enforced, you can toggle both back to Orange Cloud if you want Cloudflare’s CDN/WAF features.
   • Note: If you re-proxy, you may need to repeat the “Grey Cloud” process every 3 months when the GitHub certificate expires, as the proxy can block automated renewals. Many users prefer to keep it Grey Cloud permanently for GitHub Pages to avoid this maintenance. 

Summary of DNS in Cloudflare