CAA servfail with register.com

Is there a short-hand command and result that would show you what you are looking for? That's a lot of data to post if you want to see all of it above for each one.

You mean for @petercooperjr right? Because he got SERVFAIL but I got NOERROR

For me though the IP's for those two name servers (no AAAA)

dig +noall +answer dns101.register.com
dns101.register.com.    244     IN      A       162.159.24.117
dig +noall +answer dns102.register.com
dns102.register.com.    269     IN      A       162.159.25.158
5 Likes

Thanks, I dig get that dig info as well. But I don't know how to correct it. It may not be complicated but I don't know what the fix to pass on to my client is yet.

If register.com can't do CAA as some have said then the client may be SOL. If they have messed up their DNSSEC somehow I'm not skilled enough yet to help them fix it. I don't know if they need really the DNSSEC or if they can just remove it as some other register.com users have done when they ran into this problem (but I suspect they will report that the need it for some other project on their apex or subdomains).

Thanks for spending time trying to educate me.

1 Like

Here are the short answers first:

$ nslookup dns101.register.com
Server:         10.5.1.134
Address:        10.5.1.134#53

Non-authoritative answer:
Name:   dns101.register.com
Address: 162.159.24.117

$ nslookup dns102.register.com
Server:         10.5.1.134
Address:        10.5.1.134#53

Non-authoritative answer:
Name:   dns102.register.com
Address: 162.159.25.158

And the longer ones:

$ dig CAA www.saintjoisd.net @dns101.register.com

; <<>> DiG 9.11.36-RedHat-9.11.36-5.el8_7.2 <<>> CAA www.saintjoisd.net @dns101.register.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59000
;; 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: 1232
;; QUESTION SECTION:
;www.saintjoisd.net.            IN      CAA

;; AUTHORITY SECTION:
saintjoisd.net.         3600    IN      SOA     DNS101.REGISTER.COM. root.REGISTER.COM. 122111212 10800 3600 604800 3600

;; Query time: 34 msec
;; SERVER: 162.159.24.117#53(162.159.24.117)
;; WHEN: Tue Dec 20 23:16:29 CST 2022
;; MSG SIZE  rcvd: 107

$ dig CAA www.saintjoisd.net @dns102.register.com

; <<>> DiG 9.11.36-RedHat-9.11.36-5.el8_7.2 <<>> CAA www.saintjoisd.net @dns102.register.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9975
;; 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: 1232
;; QUESTION SECTION:
;www.saintjoisd.net.            IN      CAA

;; AUTHORITY SECTION:
saintjoisd.net.         3600    IN      SOA     DNS101.REGISTER.COM. root.REGISTER.COM. 122111212 10800 3600 604800 3600

;; Query time: 55 msec
;; SERVER: 162.159.25.158#53(162.159.25.158)
;; WHEN: Tue Dec 20 23:16:43 CST 2022
;; MSG SIZE  rcvd: 107

Interesting that dns101/102 return NOERROR, but my default servers and google's public return SERVFAIL:

$ dig CAA www.saintjoisd.net @8.8.8.8

; <<>> DiG 9.11.36-RedHat-9.11.36-5.el8_7.2 <<>> CAA www.saintjoisd.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43465
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.saintjoisd.net.            IN      CAA

;; Query time: 76 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 20 23:18:22 CST 2022
;; MSG SIZE  rcvd: 47

Thanks very much from each of you spending time trying to help me make some progress.

2 Likes

Well...
My best guess is that they are behind some unhinged DDoS protected network device.

6 Likes

Thanks for adding the detail that the dnsviz output has changed throughout the day. Yesterday when looking I only saw the one warning about SHA1 being ignored when better algorithms were available. Then when late afternoon today it was showing a large number of different errors mentioned by osiris, I thought I had just screwed up my checks yesterday. But it turns out the same checks now are back to only showing the SHA1 being ignored warning.

Between dataviz only showing the SHA1 warning and dnssec-analyzer showing all green I thought the problem lay somewhere other than DNSSEC. That was the point at which I posted my questions here.

1 Like

So many factors at play. We have multiple clients using cloudflare, so that alone probably isn't it. I was pleasantly surprised when the first cloudflare clients made it through letsencrypt ACME renewals cleanly when they started showing up.

I suspect it is the combination of register.com, cloudflare and DNSSEC that has proven too much for poor certbot...

2 Likes

For some reason AWS doesn't turn on DNSSEC checking by default, and you have to specifically turn it on. By "any DNS resolver" I meant "any DNS resolver which is at least kinda trying to comply with current standard practice", but I suppose I should have been more clear. :slight_smile:

The fix is to have the DNS provider fix their broken DNSSEC. Neither you nor your client can really do anything, you need to have the DNS provider fix it, or change the domain to use a DNS provider that isn't so broken.

You're probably running into that DnsViz only shows the result for CAA if specifically asked for in the advanced settings.

First on the Analyze tab:

Then on the DNSSEC tab:

(I don't know if you need it in both tabs, but I figure it can't hurt.) And then you can see the DNSSEC errors:

  • NSEC proving non-existence of www.saintjoisd.net/CAA: No NSEC RR matches the SNAME (www.saintjoisd.net).
  • NSEC proving non-existence of www.saintjoisd.net/CAA: No NSEC RR matches the SNAME (www.saintjoisd.net).
  • NSEC proving non-existence of www.saintjoisd.net/CAA: The following queries resulted in an answer response, even though the NSEC records indicate that the queried names don't exist: www.saintjoisd.net/A
  • NSEC proving non-existence of www.saintjoisd.net/CAA: The following queries resulted in an answer response, even though the NSEC records indicate that the queried names don't exist: www.saintjoisd.net/A
7 Likes

@petercooperjr Weird, I'm still getting 15 warnings with (or some variants with different algo's such as SHA-386):

RRSIG ./DNSKEY alg 8, id 20326: Validation of DNSSEC algorithm 8 (RSASHA256) is not supported by this code, so the cryptographic status of this RRSIG is unknown.

.. instead of the errors you're showing. Not sure why? I've tried Chrome and Edge, just in case DNSViz makes the browser to all the calculations..

6 Likes

I was seeing warnings along those lines too, but I thought the errors were a separate thing showing that the DNSSEC responses were wrong. You're just seeing the warnings, and not the errors too, when picking to look at the CAA record?

6 Likes

@petercooperjr is correct. The non-existence records on subdomains of saintjoisd.net are all broken. I had a look at this yesterday, but a short skim didn't see a huge issue. While I have no idea what's (sometimes) broken with DnsViz , the error messages are clear + reproduceable for me.

With DNSSEC, nameservers have to proof that a given record does not exist. Otherwise anyone could just truncate or convert responses into NXDOMAIN, which is a problem (it could be used to disable DNSSEC entirely). DNSSEC uses either NSEC or NSEC3 for this. Both have a slight disadvantage, as they allow zone enumeration (getting all records a given zone has), but its a bit more difficult to do so with NSEC3.

The domain in question here uses NSEC (which is actually easier to debug in cases like this), but the signing on subdomains is broken. While queries to saintjoisd.net all result in correct answers, any query to a subdomain with a type that does not exist results in a broken NSEC record.

As an example (this applies to any subdomain due to wildcards, see below):

For a given query dig CAA www.saintjoisd.net, the nameserver claims (via NSEC) that the entire subdomain does not exist (i.e. there is no www.saintjoisd.net, only saintjoisd.net), yet the response is a NOERROR one (with empty answer section, i.e. no matching records). If the entire subdomain was non-existing the response should have been NXDOMAIN instead. Actually, if we do a query dig A www.saintjoisd.net we can actually get a non-empty A response (with correct RRSIG), so the subdomain does actually exist. This is not stated by the nameserver though, resulting in a broken NSEC record and hence failing DNSSEC validation.

This issue happens with all record types that don't exist (i.e. AAAA, SSHFP...) all result in this exact same error. It is not limited to CAA records, it applies to all non-existence proofs.

A few things I discovered while testing:

  • The zone appears to be live signed, i.e. DNSSEC records are generated on the fly. This is a bit unusual, but not a problem in itself.
  • The zone uses a wildcard, i.e. dig A anysubodmain.saintjoisd.net resolves to the same IP address (www." also appears to be a part of the wildcard). The existence RRsigs are correctly signed here, unlike the NSEC for the same subdomain. This wildcard is a probable cause for the nameserver trouble, as the nameserver does not properly disclose it. With NSEC, wildcards have to be disclosed in the NSEC response*, otherwise the resolver can't possibly validate it. The nameserver here does not disclose the wildcard at all, instead pretending that no subdomains exist.

My suggestion to @TeQuilYa would be to speak with their DNS provider and see if they can fix the DNSSEC issue. If they are unable to do so, you have some more options:

  • Disable DNSSEC entirely (weakens security, but resolves the issue)
  • Try to check if the issue also appears without the wildcard. The NSEC issue might disappear, but its not guaranteed - there might be more dragons in the shadows.
  • Adding a CAA record will result in a non-empty response with RRSIG, also working around the broken NSEC response. This does not fix your other record types (AAAA for example) though, so I wouldn't recommend it.

Some more trivia: Cloudflare, which supports Extended DNSSEC errors, also complains about the NSEC records on subdomains:

# dig AAAA www.saintjoisd.net +dnssec @1.1.1.1

; <<>> DiG 9.16.33-Debian <<>> AAAA www.saintjoisd.net +dnssec @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6991
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 6 (DNSSEC Bogus): (proof of non-existence of www.saintjoisd.net. AAAA)
;; QUESTION SECTION:
;www.saintjoisd.net.            IN      AAAA

*As the zone uses live signing, it could also theoretically get away with not disclosing the wildcard (instead generating NSEC records on the fly), but at the very least it has to properly generate the NSEC records.

7 Likes

Thanks! Between the advanced dnsvis options, recent suggestions and dig using clouidflare I think I have a couple of tangible things to pass on to the client to help them talk to the DNS provider.

This dnsvis query seems to encapsulate the advanced options petercooperjr was so helpful in spelling out:
https://dnsviz.net/d/www.saintjoisd.net/dnssec/?rr=257&a=all&ds=all&ta=.&tk=
At least when I open that URL in a fresh incognito window it seems to reliably show the 4 NSEC errors. (I think I will provide the client with that url and a link to this thread for the details)

Even their apex record seems to have some NSEC issues, at least in the 'proving non-existence area):
https://dnsviz.net/d/saintjoisd.net/dnssec/?rr=257&a=all&ds=all&ta=.&tk=

5 Likes

I think it is very interesting that the same +dnssec querty using dns101 returns the NOERROR and seems to get an additional AUTHORITY record (does this indicate they aren't propagating something to other DNS servers properly?):

$ dig AAAA www.saintjoisd.net +dnssec @dns101.register.com

; <<>> DiG 9.11.36-RedHat-9.11.36-5.el8_7.2 <<>> AAAA www.saintjoisd.net +dnssec @dns101.register.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62754
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;www.saintjoisd.net.            IN      AAAA

;; AUTHORITY SECTION:
saintjoisd.net.         3600    IN      SOA     DNS101.REGISTER.COM. root.REGISTER.COM. 122111212 10800 3600 604800 3600
saintjoisd.net.         3600    IN      RRSIG   SOA 13 2 7200 20221229000000 20221208000000 21296 saintjoisd.net. E21YZ2VrSnbAb7/SME9R+3vyZZvpOMpsYjcWLlFwH7kVjltUMvb1ibqi TvneAeWzOHwKXIN8ynjL9OjZJT0uiQ==
saintjoisd.net.         3600    IN      NSEC    saintjoisd.net. A NS SOA MX TXT RRSIG NSEC DNSKEY
saintjoisd.net.         3600    IN      RRSIG   NSEC 13 2 3600 20221229000000 20221208000000 21296 saintjoisd.net. NULdu6I0JC60E6WTdYLD40M34qC4y7nFppssBunHIexjvqz6EnTkKPYe BjbWkGNQO27fQ7YAuMlueY7N9AzKBw==

;; Query time: 64 msec
;; SERVER: 162.159.24.117#53(162.159.24.117)
;; WHEN: Wed Dec 21 09:38:41 CST 2022
;; MSG SIZE  rcvd: 364

Or maybe the live signing vs wildcard items mentioned by Nummer378 is the root of the issue here...

1 Like

No, this is to be expected. When you run

dig AAAA www.saintjoisd.net +dnssec @dns101.register.com

you send the query directly to the responsible nameserver. The nameserver then replies with the data it has. A nameserver is not a [recursive] resolver, it does not validate its own DNSSEC responses (it could, but that would be fairly useless and not helpful). It's like asking a server to tell whether its own certificates are valid - it can obviously do this check, but if we're going to trust what the server says we could also stop validating altogether. The client has to perform the validation, and the nameserver is not the client - the [recursive] resolver is.

A resolver like Cloudflare is a [recursive] resolver, meaning that it retrieves the data from the domain's nameservers for you and performs DNSSEC validation. So the SERVFAIL you see is generated by Cloudflare in response to getting invalid data from the nameserver. Internally, Cloudflare got the exact same dataset you see when running the above command.

The authority section is often changed (primarily removal of irrelevant data) by recursive resolvers, so its to be expected that it looks different when asking the resolver vs the nameserver directly. Recursive resolvers also add data where they think its useful, while nameservers usually just tell you the answer to your "question" in DNS-speak.

(Also, to clarify: dig itself doesn't do any DNSSEC validation, at least not by default. I don't know if there's a switch to turn that on, +dnssec just sets the DNSSEC-OK (DO) flag, so that DNSSEC is visible in responses)

9 Likes

Uch, I selected CAA at the "Analyze" in the beginning, but for some reason it didn't give me any error previously. Manually selecting it again shows the errors now :slight_smile:

9 Likes

Thanks for the help everybody. I marked the entry that seemed most helpful as the solution.

Removing DNSSEC was finally the avenue that the client took and was the main element in fixing their issues. They got in touch with me Friday last week to resolve their remaining issues.

Details
Why DNSSEC?
The client had some sort of DNS issue 2-3 months ago where their DNS was 'hacked' (it was unclear to me if it was a typical DNS expiration / takeover or a nefarious type getting control of their login). As part of trying to prevent similar issues in the future they must have turned on DNSSEC from the register.com user interface. However, the register.com implementation doesn't seem compatible with letsecnrypt, causing issues on their next certificate renewal. They didn't seem to have any true requirement for DNSSEC and had turned it back off before I started helping Friday.

They had made some additional A record and other changes that needed reverted before I got them on track.

CAA with register.com was buggy.
The client had attempted the CAA workaround as well but mistakenly put the CAA record at the apex and didn't have letsencrypt.org in the value. Additionally, I found that when trying to add the correct www level record that register.com still doesn't seem to have proper CAA support. IE: After adding the www CAA record, the register.com UI showed two apex level records and worse, neither could be removed (it sounds like it will require a call to their tech support to resolve that issue).

Although a CNAME www record is our preferred configuration, we were able to get things working with an A record alongside the broken and now unnecessary CAA record.

6 Likes

Does that mean it has been fixed at this point in time?

3 Likes

Sorry for lack of clarity. I worked around it and moved on, I doubt they changed/fixed anything.

If some technical writer can give me the proper way I should have worded that to indicate it was buggy when I was using without implying it has been fixed maybe I can learn from my mistakes.

5 Likes

Thank you @TeQuilYa, that was my guess; but I like to know things for sure. :slight_smile:

3 Likes

@TeQuilYa
hmm...
Maybe using something more like:
... was too buggy (for me).
[which implies that you moved away from it - not that it has been fixed]

5 Likes

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