Thanks for sharing the message. That definitely helps a lot. Also it's really interesting that this fails on unboundtest consistently. That at least makes it easier to figure out than an inconsistent failure.
BTW, it's worth reading https://letsencrypt.org/docs/caa/ for details about why we look up CAA even for domains that don't use CAA.
Looking at https://unboundtest.com/m/CAA/infoblox.com/L6YULUQY, it seems that Unbound is repeatedly trying to resolve your nameservers (
ns1.infoblox.com etc) and getting what it considers a referral.
However, it shouldn't need to resolve your nameservers, because they are in-domain, and the referral from
<.com> contains glue for them:
$ dig a iNfobloX.com @c.gtld-servers.net
; <<>> DiG 9.16.1-Ubuntu <<>> a iNfobloX.com @c.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4870
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 9
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;iNfobloX.com. IN A
;; AUTHORITY SECTION:
iNfobloX.com. 172800 IN NS ns1.iNfobloX.com.
iNfobloX.com. 172800 IN NS ns2.iNfobloX.com.
iNfobloX.com. 172800 IN NS ns3.iNfobloX.com.
iNfobloX.com. 172800 IN NS ns4.iNfobloX.com.
iNfobloX.com. 172800 IN NS ns5.iNfobloX.com.
iNfobloX.com. 172800 IN NS ns6.iNfobloX.com.
;; ADDITIONAL SECTION:
ns1.iNfobloX.com. 172800 IN A 18.104.22.168
ns2.iNfobloX.com. 172800 IN A 22.214.171.124
ns2.iNfobloX.com. 172800 IN AAAA 2620:10a:6001:fffe::11
ns3.iNfobloX.com. 172800 IN A 126.96.36.199
ns3.iNfobloX.com. 172800 IN AAAA 2620:10a:6001:fffe::10
ns4.iNfobloX.com. 172800 IN A 188.8.131.52
ns5.iNfobloX.com. 172800 IN A 184.108.40.206
ns6.iNfobloX.com. 172800 IN A 220.127.116.11
My next thought was that some component might not be honoring caps-for-id, which our Unbound config uses, but that's clearly not the case as you can see above. Another thought is a DNSSEC misconfiguration, which can lead to SERVFAILs. But according to https://dnsviz.net/d/infoblox.com/dnssec/ your DNSSEC looks fine.
My next recommended step would be to do some winnowing down of the problem: Set up an Unbound instance with the default config, and see if it resolves your hostname. If it doesn't, we may have found a general problem with Unbound. If it does, the difference is probably between the default Unbound config and the config on unboundtest.com (which is pretty close to our prod config, modulo performance tweaks). Try changing individual settings and re-testing to see if you get a successful resolution. I'll let you know if I think of anything else. This is a bit of a stumper, I'm afraid.