Good morning (well for me) @jsha & @LeonA , It was a mystery to me how I had 2 other sites with Netregistry and they had worked fine about 2 weeks ago and then this week my main domain would not! But I would say your guess “My guess is that something changed routing-wise, and this went from an “everyone” problem to a “sometimes” problem.” is spot on as my main domain vpscloud.biz and gone through fine this morning! Lets hope it will renew fine in the future!
Regards to all,
Mark.
Anyone else try it recently and had success?
Yes I just renewed our main domain. Now to try the others. I was about to switch my domains to another domain host so it has happened just in time…
I’ve now renewed 4. The mobile one (m.domainname.com.au) initially failed just now, but worked when I tried again. The other three worked straight up today.
Problems I was seeing seem to be resolved as of this morning. and can successfully receive UDP responses from netregistry DNS servers.
dig CAA rest-stops.computerpros.com.au. @ns1.netregistry.net. +notcp
Cert is now being successfully issues.
Seems all good here as well
I can also confirm that all of the domains that were failing DV renewal due to CAA check via UDP have successfully passed and their respective certs renewed.
Looks like we may not be completely out of the woods yet.
I have a new case that popped up today for domains hosted by ezyreg.com, another Netregistry reseller.
The same CAA via UDP timeout issue remains there.
Here’s the example…
This CAA check via UDP fails with timeout
dig CAA drumdigital.com.au. @ns-1.ezyreg.com. +notcp
; <<>> DiG 9.10.2 <<>> CAA drumdigital.com.au. @ns-1.ezyreg.com. +notcp
;; global options: +cmd
;; connection timed out; no servers could be reached
This CAA check via TCP works
dig CAA drumdigital.com.au. @ns-1.ezyreg.com. +tcp
; <<>> DiG 9.10.2 <<>> CAA drumdigital.com.au. @ns-1.ezyreg.com. +tcp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33240
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;drumdigital.com.au. IN CAA
;; AUTHORITY SECTION:
drumdigital.com.au. 86400 IN SOA ns-1.ezyreg.com. cpanel.netregistry.com.au. 2017050100 86400 7200 3600000 86400
;; Query time: 315 msec
;; SERVER: 180.235.128.119#53(180.235.128.119)
;; WHEN: Wed May 03 15:12:49 Eastern Daylight Time 2017
;; MSG SIZE rcvd: 117
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
Revisiting this thread, I wanted to update the above statement, which I discovered is inaccurate. Unbound never falls back to TCP due to timeouts, only when it receives a truncated ANSWER. See this reply I got on the Unbound mailing list: Trust rules and DNSSEC signatures