Name not resolving against 1.1.1.1 but is against others

On ~monday, several of our customers who are using Cloudflare for their DNS reported that they can’t access our application.

Sure enough, I get a SERVFAIL against 1.1.1.1 but every other public DNS provider is working (e.g. 8.8.8.8).

Big list of DNS providers correctly resolving: DNS Checker - DNS Check Propagation Tool

Result against 1.1.1.1:

dig @1.1.1.1 alleycorp-nord.woventeams.com

; <<>> DiG 9.10.6 <<>> @1.1.1.1 alleycorp-nord.woventeams.com

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7606

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

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

; OPT=15: 00 06 77 69 6c 64 63 61 72 64 20 65 78 70 61 6e 73 69 6f 6e 20 70 72 6f 6f 66 20 66 6f 72 20 61 6c 6c 65 79 63 6f 72 70 2d 6e 6f 72 64 2e 77 6f 76 65 6e 74 65 61 6d 73 2e 63 6f 6d 2e ("..wildcard expansion proof for alleycorp-nord.woventeams.com.")

;; QUESTION SECTION:

;alleycorp-nord.woventeams.com. IN A

;; Query time: 23 msec

;; SERVER: 1.1.1.1#53(1.1.1.1)

;; WHEN: Tue May 28 17:20:21 EDT 2024

;; MSG SIZE rcvd: 123

We’re using NameCheap for our domain’s nameserver. Anyone have a guess why Cloudflare would be the only DNS provider not resolving this domain?

dig reports ..wildcard expansion proof for alleycorp-nord.woventeams.com as you showed.

Do you actually have a DNS record for alleycorp-nord or are you just relying on a wildcard (*) DNS record for it? If using a wildcard, as a workaround try creating a specific record for alleycorp-nord and see if that works (as there’s no problem with resolving your domain or www).

Someone else may know what’s going on. You can try anything random to see if the underlying issue goes away…

dig hlkjhljhlun.woventeams.com @1.1.1.1

; <<>> DiG 9.10.6 <<>> hlkjhljhlun.woventeams.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9055
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 06 77 69 6c 64 63 61 72 64 20 65 78 70 61 6e 73 69 6f 6e 20 70 72 6f 6f 66 20 66 6f 72 20 68 6c 6b 6a 68 6c 6a 68 6c 75 6e 2e 77 6f 76 65 6e 74 65 61 6d 73 2e 63 6f 6d 2e ("..wildcard expansion proof for hlkjhljhlun.woventeams.com.")
;; QUESTION SECTION:
;hlkjhljhlun.woventeams.com.	IN	A

;; Query time: 94 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed May 29 20:28:44 BST 2024
;; MSG SIZE  rcvd: 117
1 Like

We are relying on wildcard expansion, yes. And it does appear to be only those wildcard domains hitting the SERVFAIL

Example of a non-wildcard CNAME that’s working with cloudflare:

dig @1.1.1.1 www.woventeams.com

; <<>> DiG 9.10.6 <<>> @1.1.1.1 www.woventeams.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31570
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.woventeams.com.		IN	A

;; ANSWER SECTION:
www.woventeams.com.	60	IN	CNAME	woventeamsprod.wpengine.com.
woventeamsprod.wpengine.com. 120 IN	A	35.233.144.70

;; Query time: 49 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed May 29 15:41:45 EDT 2024
;; MSG SIZE  rcvd: 101

The nameserver behaves a bit oddly:

dig @156.154.132.200 alleycorp-nord.woventeams.com +dnssec

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @156.154.132.200 alleycorp-nord.woventeams.com +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18110
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;alleycorp-nord.woventeams.com. IN      A

;; ANSWER SECTION:
alleycorp-nord.woventeams.com. 300 IN   CNAME   wildcard.woventeams.com.herokudns.com.
alleycorp-nord.woventeams.com. 300 IN   RRSIG   CNAME 13 2 300 20240606000000 20240516000000 37410 woventeams.com. WWocQL5hfMPPOyxA4g5kZoaAIGfv1M2kPshjKFy7+LwvfruRJAIMnzPE mwSGERtEWzHCZ41WHjLa4n9Qirbg4Q==

;; AUTHORITY SECTION:
hs2-4786084._domainkey.woventeams.com. 3601 IN NSEC em7486.woventeams.com. CNAME RRSIG NSEC
hs2-4786084._domainkey.woventeams.com. 3601 IN RRSIG NSEC 13 4 3601 20240606000000 20240516000000 37410 woventeams.com. mRNNA9yf1jcQPhZ+TjJF1ef+EBGKz/ExLviH8fv4F2wIaN8u0htNYu2V BTxxxa5HZB+m5FfkPyQ/hZRoypKoHw==

;; Query time: 28 msec
;; SERVER: 156.154.132.200#53(156.154.132.200) (UDP)
;; WHEN: Wed May 29 22:02:39 CEST 2024
;; MSG SIZE  rcvd: 392

The answer is there, but also an NSEC record that proves that the requested record does not exist.

3 Likes

I’ve just read through RFC 4034 and 4035 as this same question has come up in a different topic, and I’ve come to the conclusion that my previous conclusion was wrong.

The RRSIG of the CNAME record shows that the owner name was expanded from a wildcard. The label count in the RRSIG, 2, is one less then the actual number of labels in the owner name, 3, so the least significant label must be replaced with a wildcard (*.woventeams.com).

The NSEC record is then needed to prove that no more specific record exists for the owner name, because while we have proof that a wildcard record exists that covers the name, there could still be a record that exactly matches the requested name, which would take precedence over the wildcard.

So I’ve changed my opinion to: There is nothing wrong with the nameserver’s response, and it should work. And in fact, it is now working, so I assume Cloudflare has fixed whatever problem there was.

3 Likes