Seeking advice on making authoritative custom name server trustworthy

What is the name of the domain?

example02.net.au

What is the error number?

EDE 20

What is the error message?

Not Authoritative

What is the issue you’re encountering

Authoritative custom name server not acceptable to Cloudflare

What steps have you taken to resolve the issue?

DNS Response Validation Summary for www.dolphyn-example.net.au
I’m sorry but all dots have to be converted into _ so they do not look like links.

I am running a custom authoritative name server for dolphyn-example_net_au on ns1_netfinch_com_au (139_180_169_230).
Cloudflare’s public resolver at 1_1_1_1 consistently returns:

status: SERVFAIL
EDE: 22 (No Reachable Authority)
EDE: 24 (Invalid Data: mismatched question section)

To isolate and investigate, I captured the full DNS exchange (UDP) and verified the following:
:pushpin: DNS Response Fields (Hex-Decoded)

== Header

:white_check_mark: All section counts are valid and consistent with the packet content.

== QUESTION Section

:white_check_mark: This section is byte-for-byte identical to the original query sent by Cloudflare, including casing.

== ANSWER Section

CNAME and A record
Records are canonicalized, label lengths match, and compression pointers are valid.

== AUTHORITY Section

:white_check_mark: All SOA fields conform to RFC 1035. No inconsistencies found.

== ADDITIONAL Section

:white_check_mark: OPT record is at the end of the packet. No extraneous bytes follow. Flags, payload size, and structure conform to RFC 6891.

=== Validated Compliance

No compression used in the QUESTION section (RFC 1035 §4.1.2)
DO bit correctly echoed when present in the query
Message length < 512 bytes (well under truncation threshold)
No duplicate QUESTIONs (QDCOUNT = 1)
OPT record formatting and placement is correct
No invalid TTLs or overflows
No malformed RDATA or broken pointers
No junk/padding beyond end of message

== Suspected Issue

Cloudflare resolver continues to respond with:

EDE: 24 (Invalid Data): [server IP], mismatched question section

This does not appear to match the actual wire format, as the QUESTION section is fully echoed and correct. Therefore, it’s possible:

The EDE 24 is a fallback or catch-all label for other policy failures.
Cloudflare is using cached delegation/glue pointing to a stale or unreachable IP.
A TTL-expired NS or missing DNSKEY (despite unsigned zone) is causing delegation lookup failure.

== Request

Please assist in re-evaluating this response or let me know if:

There are Cloudflare-specific validation rules not covered in RFC 1035, 6891, or 8906 that I may be missing.
A cached/stale delegation for ns2_netfinch_com_au could be the cause of SERVFAIL/EDE 22.
You can test directly from Cloudflare infrastructure and confirm the packet-level issue.

Happy to provide pcap files upon request.

Thanks in advance,
Richard

What feature, service or problem is this related to?

DNS not responding/updating

What are the steps to reproduce the issue?

dig dolphyn-example.net.au @1.1.1.1

dolphyn-example.net.au and example02.net.au and the two domains for which ns{1,2}.netfinch.com.au are authoritative, so either can be used for testing.

Those 2 nameservers appear to be unreachable (for me anyway)…

dig dolphyn-example.net.au @ns1.netfinch.com.au
;; communications error to 139.180.169.230#53: timed out
;; communications error to 139.180.169.230#53: timed out
;; communications error to 139.180.169.230#53: timed out

; <<>> DiG 9.18.33 <<>> dolphyn-example.net.au @ns1.netfinch.com.au
;; global options: +cmd
;; no servers could be reached


dig dolphyn-example.net.au @ns2.netfinch.com.au
;; communications error to 103.119.109.68#53: timed out
;; communications error to 103.119.109.68#53: timed out
;; communications error to 103.119.109.68#53: timed out

; <<>> DiG 9.18.33 <<>> dolphyn-example.net.au @ns2.netfinch.com.au
;; global options: +cmd
;; no servers could be reached


dig +trace +nodnssec dolphyn-example.net.au

; <<>> DiG 9.18.33 <<>> +trace +nodnssec dolphyn-example.net.au
;; global options: +cmd
.			54092	IN	NS	a.root-servers.net.
....
.			54092	IN	NS	m.root-servers.net.
;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

au.			172800	IN	NS	s.au.
au.			172800	IN	NS	a.au.
au.			172800	IN	NS	r.au.
au.			172800	IN	NS	q.au.
au.			172800	IN	NS	t.au.
;; Received 353 bytes from 202.12.27.33#53(m.root-servers.net) in 9 ms

dolphyn-example.net.au.	3600	IN	NS	ns2.netfinch.com.au.
dolphyn-example.net.au.	3600	IN	NS	ns1.netfinch.com.au.
;; Received 100 bytes from 65.22.197.1#53(r.au) in 227 ms

;; communications error to 139.180.169.230#53: timed out
;; communications error to 139.180.169.230#53: timed out
;; communications error to 139.180.169.230#53: timed out
;; communications error to 103.119.109.68#53: timed out
;; no servers could be reached

Yes, sorry there was a problem that has been addressed.
Google can resolve the IP but Cloudflare does not.

dig -t A dolphyn-example.net.au @8.8.8.8

; <<>> dig 9.10.8-P1 <<>> -t A dolphyn-example.net.au @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8931
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dolphyn-example.net.au. IN A

;; ANSWER SECTION:
dolphyn-example.net.au. 300 IN A 207.148.87.189

;; AUTHORITY SECTION:
dolphyn-example.net.au. 300 IN SOA ns1.netfinch.com.au. sysadmin.netfinch.com.au. 2025051501 14400 3600 1209600 3600

;; Query time: 315 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri May 16 19:37:08 AEST 2025
;; MSG SIZE rcvd: 129

dig -t A dolphyn-example.net.au @1.1.1.1

; <<>> dig 9.10.8-P1 <<>> -t A dolphyn-example.net.au @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18249
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 22 (No Reachable Authority): 61 74 20 64 65 6c 65 67 61 74 69 6f 6e 20 64 6f 6c 70 68 79 6e 2d 65 78 61 6d 70 6c 65 2e 6e 65 74 2e 61 75 2e (“at delegation dolphyn-example.net.au.”)
; EDE: 24 (Invalid Data): 31 33 39 2e 31 38 30 2e 31 36 39 2e 32 33 30 3a 35 33 2c 20 6d 69 73 6d 61 74 63 68 65 64 20 71 75 65 73 74 69 6f 6e 20 73 65 63 74 69 6f 6e (“139.180.169.230:53, mismatched question section”)
;; QUESTION SECTION:
;dolphyn-example.net.au. IN A

;; Query time: 1499 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri May 16 19:37:18 AEST 2025
;; MSG SIZE rcvd: 147

Although you are not using DNSSEC, the DNSSEC checkers don’t like something (working zones that don’t use DNSSEC don’t give this output). Whether that shows the problem or not I’m not sure.

I’ll need to poke more later, or someone with better DNS-foo may known more.

1 Like

Weird stuff going on here. There’s a DS record for net.au, but no NS record.

Might be “confusing” the resolvers?

Edit: No, other net.au domains don’t have problems.

1 Like

Does ns1.netfinch.com.au act as authoritative for any other domains to test other than these 2?

No sjr, not at the moment. I want to ensure that the server is working correctly before putting any other domains onto it.

Can you move one on (checking it works ok with 1.1.1.1 before doing so) or move one off to see if the problem stays only with your resolver?

What software are you using as the resolver?

Yes, I’ve moved glujs.dev onto ns{1,2}.netfinch.com.au
Previous successful resolution with 1.1.1.1:
dig -t A glujs.dev @1.1.1.1

; <<>> dig 9.10.8-P1 <<>> -t A glujs.dev @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21905
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;glujs.dev. IN A

;; ANSWER SECTION:
glujs.dev. 300 IN A 158.247.242.233

;; Query time: 723 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri May 16 20:57:38 AEST 2025
;; MSG SIZE rcvd: 54

Now my servers say they are authoritative for gljs.dev:
dig -t A glujs.dev @ns1.netfinch.com.au
;; Warning: query response not set

; <<>> dig 9.10.8-P1 <<>> -t A glujs.dev @ns1.netfinch.com.au
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22744
;; flags: aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;glujs.dev. IN A

;; ANSWER SECTION:
glujs.dev. 300 IN A 207.148.87.189

;; AUTHORITY SECTION:
glujs.dev. 300 IN SOA ns1.netfinch.com.au. sysadmin.netfinch.com.au. 2025051501 14400 3600 1209600 3600

;; Query time: 7 msec
;; SERVER: 139.180.169.230#53(139.180.169.230)
;; WHEN: Fri May 16 21:03:23 AEST 2025
;; MSG SIZE rcvd: 118

But it may take a little while for Epik to register the change in name servers and for Cloudflare’s cache to expire.

Yep, it’s borked…

dig glujs.dev @1.1.1.1

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 16 61 74 20 64 65 6c 65 67 61 74 69 6f 6e 20 67 6c 75 6a 73 2e 64 65 76 2e ("..at delegation glujs.dev.")
; OPT=15: 00 18 31 33 39 2e 31 38 30 2e 31 36 39 2e 32 33 30 3a 35 33 2c 20 6d 69 73 6d 61 74 63 68 65 64 20 71 75 65 73 74 69 6f 6e 20 73 65 63 74 69 6f 6e ("..139.180.169.230:53, mismatched question section")
;; QUESTION SECTION:
;glujs.dev.			IN	A

;; Query time: 3585 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri May 16 12:13:12 BST 2025
;; MSG SIZE  rcvd: 121

Seems something that your resolver does that 1.1.1.1 [add, and the DNSSEC checkers] does not like.

Yes, I don’t think its a zone configuration problem, or google and opendns would also complain. I thought it was due to the DO bit not being echoed (said to be expected by Cloudflare even though its not required by RFC) but that wasn’t enough.
I see Cloudflare queries in the logs and replies are given but there is something I’m missing - the replies are good enough for others but there is something that Cloudflare doesn’t like and I’d love to find out what it is.

This response from 1.0.0.1 gives the same reasoning as DNSViz. Likely other resolvers just ignore this…

dig glujs.dev @1.0.0.1

; <<>> DiG 9.10.6 <<>> glujs.dev @1.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55007
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 0a 66 61 69 6c 65 64 20 74 6f 20 76 65 72 69 66 79 20 73 69 67 6e 61 74 75 72 65 73 20 66 6f 72 20 67 6c 75 6a 73 2e 64 65 76 2e 20 6f 70 74 2d 6f 75 74 20 70 72 6f 6f 66 ("..failed to verify signatures for glujs.dev. opt-out proof")
; OPT=15: 00 16 61 74 20 64 65 6c 65 67 61 74 69 6f 6e 20 67 6c 75 6a 73 2e 64 65 76 2e ("..at delegation glujs.dev.")
; OPT=15: 00 18 31 30 33 2e 31 31 39 2e 31 30 39 2e 36 38 3a 35 33 2c 20 6d 69 73 6d 61 74 63 68 65 64 20 71 75 65 73 74 69 6f 6e 20 73 65 63 74 69 6f 6e ("..103.119.109.68:53, mismatched question section")
;; QUESTION SECTION:
;glujs.dev.			IN	A

;; Query time: 3268 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Fri May 16 12:26:51 BST 2025
;; MSG SIZE  rcvd: 182

I’m trying to flag for someone to take a look.

Found it after taking another look at dnsviz.

dig dolphyn-example.net.au cname @ns1.netfinch.com.au

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> dolphyn-example.net.au cname @ns1.netfinch.com.au
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65454
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dolphyn-example.net.au.                IN      CNAME

;; ANSWER SECTION:
dolphyn-example.net.au. 300     IN      CNAME   visi.netfinch.com.au.

;; AUTHORITY SECTION:
dolphyn-example.net.au. 300     IN      SOA     ns1.netfinch.com.au. sysadmin.netfinch.com.au. 2025051501 14400 3600 1209600 3600

;; Query time: 288 msec
;; SERVER: 139.180.169.230#53(ns1.netfinch.com.au) (UDP)
;; WHEN: Fri May 16 18:29:02 CEST 2025
;; MSG SIZE  rcvd: 132

A CNAME for the zone apex, I’m pretty sure that’s what causing the problems.

1 Like

Thank you sjr for your kind help.
Having a CNAME at the apex was wrong and I fixed that. Although it was not enough to fix the problem, it set me on the path of comparing my responses to a standard authoritative server (gdnsd). My server was incorrectly setting flags in the responses. When that was fixed, global resolvers were successful.

3 Likes

Thanks for your help, Laudian - much appreciated.

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