kdig @ NS +nsid
;; ->>HEADER<<- opcode: QUERY; status: SERVFAIL; id: 49097
;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1

;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR
;; NSID: 33316D3533 "31m53"
;; EDE: 22 (No Reachable Authority)

;;                 NS

;; Received 55 B
;; Time 2021-11-05 11:55:32 CET
;; From [email protected](UDP) in 23.2 ms

It’s not like their authoritative servers behave ideally, but I haven’t noticed any real reason for SERVFAIL and e.g. our Knot Resolver instances have no issues when resolving this directly (without forwarding through CloudFlare).

The problem seems to be consistent. Practical issues happen when forwarding to CloudFlare with QNAME minimization.

I am also not able to get a result on Google DNS, Quad9 or OpenDNS. The only difference is that Cloudflare returns a SERVFAIL when it receives an empty response and the other resolvers return NOERROR but with an empty answer.

Yes, NOERROR with empty answer is what I desire from in this case :wink:

I noticed the same behaviour here too: SERVFAIL for - #2 by milk
I suppose it’s up to the resolver to reply with a SERVFAIL or an empty NOERROR, as in the end it should not really make a difference. I’d personally prefer the latter like you as well. Perhaps @mvavrusa could look into this?

No no, the difference is rather significant on DNS protocol level. (and I’m confident that @mvavrusa will agree on that point)

The final delegation is “lame”, it doesn’t make me happy to add a workaround here, but what can we do I guess.

$ kdig @ NS
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 3742
;; Flags: qr rd ra; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 0

;;        		IN	NS

;; Received 29 B
;; Time 2021-11-05 10:21:18 PDT
;; From [email protected](UDP) in 187.2 ms

Ah, thanks; I see you deployed it already. I was mainly relying on DnsViz and missed this piece.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.