Can't resolve (over https), but it works on other servers

Cloudflare DNS (over https):

$ curl ''
{"Status": 2,"TC": false,"RD": true, "RA": true, "AD": false,"CD": false,"Question":[{"name": "", "type": 1}]}

Google DNS (over https):

$ curl ''
{"Status": 0,"TC": false,"RD": true,"RA": true,"AD": false,"CD": false,"Question":[ {"name": "","type": 1}],"Answer":[ {"name": "","type": 5,"TTL": 3599,"data": ""},{"name": "","type": 5,"TTL": 14399,"data": ""},{"name": "","type": 1,"TTL": 299,"data": ""},{"name": "","type": 1,"TTL": 299,"data": ""}],"Comment": "Response from 2620:115:c00f::c000:4b09."}

Still doesn’t work. Any ideas?

It seems like can’t get the address to the name server while can. It seems also that only Google gets that IP to the name servers, fails as well. You should check the glue records.

Asking @cs-cf for help on the backend, though!

Disclaimer this was literally the first time I’ve played with the API and I often have trouble spelling DNS… is a CNAME record so

curl ''

returns the CNAME value it points to and not specifying the record type returns the full DNS response I think you were expecting.


The Cloudflare API never gives me an answer, independently of whether I choose A or CNAME record types or whether I don’t specify the type. Note that it also fails if I try to resolve it normally (using ‘host’ command), using DNS over TLS to connect to

Please note that this hostname is not mine, I simply use it to diagnose DNS resolution issues, because it seems to fail in some DNS resolver configurations but not in others.

For example, note that works correctly, it doesn’t return a warning or error either.

I suspect it may have something to do with Path MTU issues (maybe on their end?), but I’m not really sure.

If I remember correctly, it didn’t use to resolve for me when I was using UDP to contact, but when I forced Unbound to use TCP to connect to I think it solved the issue for me (though I may be misremembering), although this would indicate the issue to be on the network path from my ISP to

However, using the Cloudflare HTTPS API (which uses TCP) rules out an issue between my ISP and, so it would probably be an issue between and the DNS nameservers.

Would you mind running dig @ id.server CH TXT and sharing the output please? It’s resolving for me so I want to pass along to the network team to see if they can examine responses at your POP.

$ dig @ id.server CH TXT

; <<>> DiG 9.11.2-P1 <<>> @ id.server CH TXT
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63486
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 1536
;id.server.			CH	TXT

id.server.		0	CH	TXT	"mad01"

;; Query time: 3 msec
;; WHEN: Thu Apr 05 20:30:36 CEST 2018
;; MSG SIZE  rcvd: 56
1 Like

I’ve logged an issue with our internal teams. Thanks!

Would you mind also doing a dig @ for and posting that here as well? TIA.

$ dig @

; <<>> DiG 9.11.2-P1 <<>> @
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24646
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 1536
;		IN	A

;; Query time: 3005 msec
;; WHEN: Fri Apr 06 22:10:05 CEST 2018
;; MSG SIZE  rcvd: 44
1 Like

Hi, it fails to resolve in several PoPs (in Europe) because it seems like we can’t reach the authoritative NSs from a couple places. We’ll try to find out whether it’s blocked intentionally or misconfigured.

$ dig NS @

; <<>> DiG 9.12.1 <<>> NS @
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63497
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512


;; AUTHORITY SECTION: 56 IN SOA 2005071858 14400 7200 604800 60

i’ve never seen anything like this…
the NS points to a CNAME?

No. The domains are set up so that and are zones, but, and are not separate zones, so they don’t have separate NS records.

You can use “dig NS” or “dig NS” to see the zones’ NS records.

I don’t think it really does, the zone break is at, is just a regular CNAME under You can ask for any type of record you want from a label which is a CNAME, you’ll get the CNAME back (and only by following the CNAME will you learn what records actually exist). But unless anything tries to use in an NS record, everything is fine.

The only real issue I see is that the two nameservers are pointing to the same IP, while the RFCs require separate servers, ideally in unique AS. But this is really just a single point of failure and might cause outages, but otherwise no big deal:


The TTLs are an odd choice, but modern resolvers should handle it without difficulty.

(And this single point of failure could easily be what caused the underlying problem here, anything from a routing issue to a firewall/misconfiguration on the authoritative NS)

Looks like their DNS server has all kinds of availability problems from multiple points on the internet, exacerbated by the fact that both nameservers point to the same IP providing no redundancy/ alternatives.

If you know the zone owner you might suggest they look to add a true secondary DNS server or move to a service with better availability.!probes

Not sure there is really anything we can do here.