月度归档： 2026 年 4 月

发布于

Weird Default Zone Settings by ClouDNS

This site was recently migrated to ClouDNS from DNSMadeEasy. Everything went smoothly, especially with Claude’s help automating the migration script via zonefile and API.

However, during post-migration testing, I found a weird behavior with ClouDNS’ Premium plan nameservers: they return 127.0.0.1 as an authoritative answer for domains that are not hosted on their system.

For example, querying pns1.cloudns.net for google.com – a domain that obviously has nothing to do with ClouDNS:

~$ dig google.com @pns1.cloudns.net. +noedns +norec

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> google.com @pns1.cloudns.net. +noedns +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7556
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             120     IN      A       127.0.0.1

;; AUTHORITY SECTION:
.                       120     IN      NS      localhost.

;; Query time: 12 msec
;; SERVER: 185.136.96.111#53(pns1.cloudns.net.) (UDP)
;; WHEN: Fri Apr 10 21:32:38 JST 2026
;; MSG SIZE  rcvd: 66

Note the aa (authoritative answer) flag in the response. This server is claiming to be authoritative for google.com, returning 127.0.0.1 with a nonsensical authority section delegating the root zone to localhost.. The correct behavior would be to return REFUSED for domains not configured on the server.

Even more weirdly, ClouDNS’ free nameservers correctly return REFUSED for domains they don’t host:

~$ dig google.com @ns4.cloudns.net. +noedns +norec

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> google.com @ns4.cloudns.net. +noedns +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64552
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; Query time: 251 msec
;; SERVER: 185.206.180.171#53(ns4.cloudns.net.) (UDP)
;; WHEN: Fri Apr 10 21:34:22 JST 2026
;; MSG SIZE  rcvd: 28

No aa flag, no bogus answer — just a clean REFUSED.

The exception is ns1.cloudns.net, which returns a false authoritative answer pointing to an actual working IP 185.105.32.123 instead – a catch-all landing page by ClouDNS:

~$ dig google.com @ns1.cloudns.net. +noedns +norec

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> google.com @ns1.cloudns.net. +noedns +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30787
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             120     IN      A       185.105.32.123

;; AUTHORITY SECTION:
.                       120     IN      NS      localhost.

;; Query time: 272 msec
;; SERVER: 85.159.233.17#53(ns1.cloudns.net.) (UDP)
;; WHEN: Fri Apr 10 21:36:56 JST 2026
;; MSG SIZE  rcvd: 66

Note: As of April 2026, ClouDNS support replied: “At this time, the current behavior of our Premium nameservers is expected and no changes are planned.”