the use case: to use a reverse proxy I need subdomains on my account. The used reverse proxy (synology nas) does not allow for path based proxy-ing.
In case I use a cname I point to the domain and at the end to a certificate on my domain. So the validation fails since subdomain.domain.dedyn.io does not match to my domain.dedyn.io on the certificate, even when I request a certificate for subdomain_domain_dedyn.io at let’s encrypt this points to domain_dedyn_io. So I am out of luck here. Or someone has more knowledge and I did something incorrect.
So I went to us an A record but this forces me to update the IP individually. What is possible but not nice when you end up in 10 subdomains this is a lot of bloated config.
Do you have a suggestion to:
have subdomains
get validating let’s encrypt certificats per subdomain
have only one ddns updater
Thanks a lot !
Michael
Ps I had to use _ in the url’s since a new user can only put in 2 “links”
Are you trying to terminate the SSL/TLS connections at the service behind the reverse proxy or at the proxy itself?
Hint: the former will not work
deSEC or even more generally DNS or CNAMEs have nothing to do with that.
BTW: Using a certificate in combination with a CNAME is no problem at all. (It does not really matter whether your are pointing <subdomain>.<domain>.dedyn.io at <domain>.dedyn.io or at some other name, even in a completely different TLD, as long as the result is the correct IP. For DNSSEC to work correctly though, all of the zones must be secured. So <subdomain>.<domain>.dedyn.io CNAME <unsecured>.<tld> will cause problems!)
thanks for the answer, it seems that there is/was a further source of pain: I set this all up on a Synology NAS and it seems that they keep certificates even when they are delete. What is ok, but they seem also to link back to them when I re-request a certificate. After deleting the all unneeded certificates in the UI and on the file system I could successfully request a certificates for <subdomain>.<domain>.dedyn.io and <domain>.dedyn.io. The DDNS update refers to <domain>.dedyn.io. I took no further action. everything seems to be ok…
Your note makes me think:
For DNSSEC to work correctly though, all of the zones must be secured. So <subdomain>.> <domain>.dedyn.io CNAME <unsecured>.<tld> will cause problems!)
What do you mean with “must be secured”? Which actions should be taken?
Thanks a lot for your hint, that made me redo the stuff and led to the first success
Michael
I just did an experiment which a CNAME in a zone secured by DNSSEC pointing to a hostname in a zone not using DNSSEC. And unless my testing is off, it unexpectedly works. I thought it shouldn’t but apparently I was wrong.
So please just ignore my comment about CNAMEs and unsecured destination zones.
DNSSEC only guarantees the integrity of the specific record for which there is a signature + validation chain. In your case, it only guarantees integrity of the CNAME record; the DNSSEC status of the CNAME target is an entirely different matter. (It’s also possible to have an insecure CNAME record and a secure A record at the target, etc.) This is expected behavior.
If this was different, it would mean that DNS lookup failures would depend on the joint configuration of all zones involved, which is generally outside the control of each individual zone administrator, so breakage would occur unexpectedly. For example, if the CNAME target’s administrator disables DNSSEC for a day or two to perform a poor-man’s key algorithm change (without knowing that you have a CNAME), that would break look-ups on your domain for that period of time.
