I had a good time with deSEC so far. The other day though, I did a little fuck up by temporarily changing the NS for my domain to Route53 and back to deSEC, ignoring the fact I had DNSSEC active for that domain. After ensuring the DNSSEC setup was valid again, I was unable to access a single subdomain, which should be covered by my wildcard. Every other random (i.e. non existing) subdomains are correctly being resolved according to the wildcard A record, but not that singe one that points to my Nextcloud instance. So as of now I’m stuck with a static record pointing to my Nextcloud, while all other services still are properly handled by the wildcard.
As it looks, it seems somehow the specific subdomain in question (“nc.subdomain.domain.net”) explicitly does not get resolved, while “lol.subdomain.domain.net” or “anythingelseliterally.subdomain.domain.net” work just as they should. I tried removing my wildcards alltogether and recreating them, but to no avail. Is there anything left I could try, or do I indeed need some support?
Do you have other record types set for that subdomain? For example, a TXT record for nc.subdomain.domain.net (or any subdomain thereof) makes an A wildcard record for *.subdomain.domain.net inapplicable for the nc subdomain.
You may also have a good old-fashioned cache issue. Try asking the deSEC nameservers directly, without a caching resolver in front of them. Negative responses are cached too.
I have no other record types set for that specific subdomain. I had manually created DNS challenges, but even those were for subdomains one level deeper (i.e. “_acme_challenge.nc.subdomain.domain.net”) and thus shouldn’t affect the wildcard. I since deleted them anyway, just to be sure. To also ensure it’s not caching or similar, I waited 2 days before even starting to bother. All my TTLs are at most 3600 seconds, so I guess that shouldn’t be an issue as well.
EDIT: I’m puzzled. I just tried to remove my specific A records I created as a workaround to test if the issue persists and it didn’t. Now it just properly resolves. How can this be? If this would have been caching related, why would setting an explicit record help with that? I would expect to not get an answer regardless (or at least the wrong one).
Note the “or any subdomain thereof” in my response. Any reason for the subdomain to “exist” excludes the wildcard. If you have a record on a subdomain to a domain that has no records of its own, and then look up the empty parent domain, you won’t get an NXDOMAIN error, just no records. The domain exists because a subdomain exists. A TXT record on the _acme-challenge subdomain makes a wildcard not apply to its parent domain. Wildcards are tricky.
Big ooof That means any service only available via wildcard won’t be resolvable during a DNS challenge in general? If so, I really gotta hurry fixing the automation, as I don’t want to break availability of my services
Yes, you are exactly right - that’s how the DNS standards define it (RFC 4592 Section 4.9):
If a source of synthesis is an empty non-terminal, then the response will be one of no error in the return code and no RRSet in the answer section.
(For the definition of “empty non-terminal”, see Section 2.2.2. Essentially it’s a domain name that has no subdomains with records, but no records itself.)
That means any service only available via wildcard won’t be resolvable during a DNS challenge in general? If so, I really gotta hurry fixing the automation, as I don’t want to break availability of my services 
