Inexplicable "Invalid Domain" Error on Synology (subdomain of cloudflare NS domain)

I've been attempting to secure my Synology and all the services I run with Let's Encrypt certificates and a reverse proxy. So I changed the A records, and AAAA records on my host's DNS settings and most of them work except for one specific domain and I have absolutely no idea why.

Some of the services are in Docker containers, others are just simply Synology DSM services. And all of them run fine, except on this specific domain. Namely,, and

The weirder thing is that I also got another domain name ( with exactly the same setting, routing to exactly the same Synology OS, which works perfectly fine. I'm not kidding, the DNS and routing settings are identical.

I keep getting the "Invalid Domain, please make sure this domain can be resolved into a public IP address" Error. Which is somewhat hilarious because when I go into my host's Plesk DNS page I can literally see a screenshot of the service loading so how would that possibly be there if the domain does not resolve?

According to the domain resolves to the right IP address too on all DNS servers.

How can I solve this issue?

My domain is:

I ran this command: Get a let's encrypt certificate button :slight_smile:

It produced this output: Invalid Domain Error.

My web server is (include version): Synology DSM 6.

The operating system my web server runs on is (include version): Synology DSM 6.

My hosting provider, if applicable, is: Some random Dutch webhost.

I can login to a root shell on my machine (yes or no, or I don't know): Yes perfectly fine.

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Plesk.

Strange, that isn't the case for me:

 dan@Dan-Mac-Mini-2  ~  host
Host not found: 2(SERVFAIL)
 ✘ dan@Dan-Mac-Mini-2  ~  dig

; <<>> DiG 9.10.6 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20963
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
;		IN	A

;; Query time: 0 msec
;; WHEN: Mon Jun 27 06:55:33 EDT 2022
;; MSG SIZE  rcvd: 48

It looks like there's a DNSSEC issue:

Edit: Indeed, DNSSEC is the issue:


Strangely enough DNSViz thinks everything is A-OK: | DNSViz

Wait, not that strange: DNSSEC Analyzer also marks things with a red cross if DNSSEC is not available, even though that isn't an error per se: it's just less safe than with DNSSEC, but shouldn't hamper with resolving the hostname.

There aren't much hits on the Unbound error "NSEC RRset for the referral proved not a delegation point".. I see @_az had this error back in 2017. Maybe he knows how he dealt with this? In this case it might perhaps be due to the NSEC resource records for both the FQDN as wel as the wildcard? I dunno.. Google fails me with this error.

1 Like

Is it possible that having the same domain name in .nl extention is causing some sort of error? I also own

No, different TLD wouldn't have any effect on DNSSEC troubles.

1 Like

Customer ended up disabling DNSSEC in that case. I don't have any details on what their setup was, other than the subdomain was further delegated without DNSSEC.

The nameserver is just not signing responses for the subdomain, same in this instance.

The records for the base domain are signed:

$ dig +noall +answer +dnssec        86353   IN      RRSIG   A 13 2 86400 20220707000000 20220616000000 28737 vQlPzjnWwP6RAX0Q9B4CAtmemmmgNR7jGHh5j3yASj6eLAA3TAvoKTE+ 1Ex4J+6GBu/K6BS2ue3OBdEMC1vvHA==        86353   IN      A

Subdomain's records are not:

$ dig +noall +answer +dnssec    86340   IN      A

So this is going to be something about the nameserver/zone configuration, no idea what though.


Hm, but DNSViz clearly shows NSEC resource records being available, why wouldn't that be enough to make DNSSEC at least "valid" without actual RRSIG RRs?

If I look at the Unbound code responsible for the log entry I mentioned earlier:

it looks like its not an error but more a warning? It clearly only triggers when the status is "sec_status_insecure", which should be just fine.. It's not "sec_status_bogus". So not sure why Unbound complains with SERVFAIL..

It seems Unbound really wants to see the non-existance of a DS RR proven:

(Also see the rest of that function for more info.)

However, I'm still not sure that it's actually an error as the function resulting in the "sec_status_insecure" state earlier returns a 1 for ds_response_to_ke() which should be parsed as "True" in C and which should be a good thing in the code calling ds_response_to_ke():

So I still don't know if this is a warning or an error.......

That said, Unbound behaves differently between NSEC and NSEC3 RR. If you look at the NSEC3 code, you see that the state sec_status_insecure and sec_status_secure are treated similar!:

While the code for NSEC as seen earlier behaves differently...

Maybe switching NSEC to NSEC3 (which is a good idea anyway) might do the trick?

1 Like



The zone seems to fail the NS-bit requirement:



Could be. Although it seems the Unbound code in val_nsec.c seems to be checking for a NS RR (LDNS_RR_TYPE_NS) and not an NS bit? But as I said earlier, I'm not sure if the code I've quoted above is even an error or just a warning...

1 Like

Thank you guys so much for looking at this, teaching me how this works, and giving me ideas.

I solved the problem by taking a closer look at my top-level domain records and found that the NS records were directed to CloudFlare. I Changed those back to my host and the subdomains started working.

Thank you!

1 Like

Could I ask you to take down the personally identifiable info in that image, I see now that maybe it wasn't such a great idea to get those certificates on my personal mail :slight_smile: Learning a lot today.

You mean the GMail email address? That's not from any certificate, but from your DNS. It's accessible for anyone running the command dig SOA.


LOL, that explains a thing or two. Thank you, I'll go learn how to change those SOA records haha.

1 Like

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