No valid A or AAAA records found (and no TXT record found)

My domain is: gabedev.chat

I am running acme-client to retrieve certs via either http-01 or dns-01 using a song940/dns2 as my DNS server, serving DNS over UDP and TCP.

I have an SOA and NS setup for gabedev.chat pointing to ns-a1.bizi.ly which is running dns2; while the challenge is running, I am able to query my server through various means for the records and find them (I've queried through 8.8.8.8, 1.1.1.1, checked propagation through DNS Propagation Checker - Global DNS Testing Tool; so far the only tests that have failed consistently are https://letsdebug.net and https://unboundtest.com)

I am not sure why Unbound is unable to resolve DNS records from my server, but these are the test results:
https://unboundtest.com/m/A/gabedev.chat/FWNYTAFR

I need to run this custom DNS server for business purposes and cannot switch to using a server that I do not control entirely.

Any assistance would be great, I've tried advice from several answers on this forum for posts seeking help with both issues (No valid A or AAAA records found and no TXT record found) and followed the steps to resolve/debug most of the problems (most of them seem to come down to wrong DNS configurations; I am pretty sure these are correct DNS configurations)

ETA: I ran the acme-client on buypass (using dns-01) and this works; it did not work in buypass production until I added DoT (prior, I was only listening on UDP, and buypass staging was the only directory/environment I could get certs from)

ETA: I've run it for buypass (dns-01) a few times with the following results:

  • If I wait only 15 seconds after creating the DNS record, it will fail (actually buypass will list errors but stay in pending forever until you get a 500 respones... which is wrong, but whatever, a fail is a fail)
  • if I wait 60 seconds after creating the DNS record, it succeeds every time.

What's strange however is the A record for gabedev.chat has been up and present for days now, and yet when I run http-01 challenge on LetsEncrypt, I always get "No valid A or AAAA records for gabedev.chat" (something like that)

The server(s) did not respond authoritatively for the namespace. (35.184.32.156)

looks like you have broken DNS server setting?
https://dnsviz.net/d/gabedev.chat/dnssec/

4 Likes

is DNSSEC required? I don't have it enabled at all

eta: currently looking into the aa flag thing

not required to have DNSSEC but can't be bogus (like upper zone say you have than you should have) but most likely AA thing

6 Likes

Fingers crossed. Deploying a change that will set the aa flag on all responses to queries for records in zones we have on file.

Your DNS server gives different responses to different case queries, which is pretty broken.

$ dig +norecurse A gabedev.chat. @ns-a1.bizi.ly.

; <<>> DiG 9.16.27-RH <<>> +norecurse A gabedev.chat. @ns-a1.bizi.ly.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23910
;; flags: qr aa ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gabedev.chat.                  IN      A

;; ANSWER SECTION:
gabedev.chat.           300     IN      A       104.154.194.252

;; Query time: 39 msec
;; SERVER: 35.184.32.156#53(35.184.32.156)
;; WHEN: Tue Jan 03 12:10:39 UTC 2023
;; MSG SIZE  rcvd: 58

$ dig +norecurse A Gabedev.chat. @ns-a1.bizi.ly.

; <<>> DiG 9.16.27-RH <<>> +norecurse A Gabedev.chat. @ns-a1.bizi.ly.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37472
;; flags: qr ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;Gabedev.chat.                  IN      A

;; Query time: 39 msec
;; SERVER: 35.184.32.156#53(35.184.32.156)
;; WHEN: Tue Jan 03 12:10:45 UTC 2023
;; MSG SIZE  rcvd: 30

That is, queries for all-lowercase work, but queries that are in mixed case just return no records.

DNS is required to query case-insensitively, and ideally will echo that case in the response (though it's not as clear that's actually required, many systems assume it). Let's Encrypt's DNS queries use what's called 0x20 case randomization, where each character in the query is randomly capital or lowercase, in order to help protect against certain DNS attacks. It looks like your custom DNS server isn't properly case-insensitive and gives different results for differently cased queries, which doesn't comply with the DNS standards.

8 Likes

Thank you! I just came back to report that setting the aa flag did not help, but I will deploy this change next!

ETA: Hey! This worked! Thank you so much, I've been working at this for like 3 days straight now xD didn't even celebrate the new year

5 Likes

Glad to hear you've got things working. Yeah, DNS has a lot of subtle points, between all the various flags, and which error exactly is supposed to be returned for what, not to mention the challenges even large DNS providers seem to have with implementing DNSSEC. It seems like "how hard can returning an A record for my domain be", but it turns out that when you stray from the usual DNS software it can get messy fast.

Celebrating having a working DNS is more worth doing than celebrating that the Earth has once more made it around the sun, if you ask me. :nerd_face:

10 Likes