In my own experience, DNS Resolvers are really good at caching answers and retrying, even when your actual nameservers are very flakey and not answering correctly.
The root of your issue seems to be your nameservers, ns63.worldnic.com. and ns64.worldnic.com.
They seem very “flakey” and only resolve sometimes, servfail others.
dig a apsnet.org @ns63.worldnic.com
; <<>> DiG 9.16.33-Debian <<>> a apsnet.org @ns63.worldnic.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52282
Using the various recursive resolvers
dig a apsnet.org @1.1.1.1
; <<>> DiG 9.16.33-Debian <<>> a apsnet.org @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11572
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
dig a apsnet.org @8.8.8.8
; <<>> DiG 9.16.33-Debian <<>> a apsnet.org @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 215
dig a apsnet.org @9.9.9.9
; <<>> DiG 9.16.33-Debian <<>> a apsnet.org @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16466
1.1.1.1 and 9.9.9.9 work, 8.8.8.8 doesn’t, but it did work properly later.
So it looks like your status monitoring using Cloudflare was just a red herring, guessing you don’t use any other monitoring platforms that use different recursive resolvers to see the issue.
Edit: Using a third party tool here, DNS Check | Ping.Sx, make sure you specify the node resolver as the IP of your nameserver, ns63.worldnic.com, 162.159.26.185
You can see that most of them are servfail. Although it does seem a bit better now?