I run a self-hosted server at home on which I have run a bunch of personal stuff (like nextcloud etc.). To prevent pointing DNS servers at my home router, I run a reverse proxy on a VPS that I rent (from Scaleway FWIW).
Today I was trying to figure to what extent that exposes my data to my VPS provider and whether I can do something about it. Disclaimer: this is just a hobby exercise. I’m not paranoid, I just want to learn for my own self how to improve security of my setup.
My reverse proxy terminates the SSL connection and then proxies the connection over a wireguard connection to my home server. This means that (a) data is decrypted in the RAM of the VPS and (b) the certificates live unencrypted in the storage of the VPS. This means that the VPS provider, if they want to, can read all the traffic unencrypted to and from my home server.
I was thinking that I can solve both problems by using Nginx’s SSL pass-through feature. This would allow me to not terminate SSL on the VPS solving (a) and to move the certificates to my home server solving (b).
But just as I was playing around with it, I realised that SSL pass-through would not solve the problem of trying to protect my data from the VPS provider. As long as my DNS records point at the VPS provider’s servers, the VPS provider can always get their own certificates for my domains and do a MitM attack. Therefore, I might as well keep the certificates on the VPS since I still have to trust them not to make their own behind my back.
In the end I concluded that as long as I use a VPS provider to route my traffic to my home server, there is no fool-proof way to secure my data from them. Intuitively it makes sense, the data crosses their hardware physically and thus they will have access to it. The only way to stop it would be to update the DNS records to point directly at my home server which I don’t want to do.
Is this correct thinking or is there some way to prevent the VPS provider from seeing my data?
Again, I’m trying to solve this problem as a hobby exercise. The most sensitive data that I have is stored encrypted at the filesystem level and I only decrypt it locally on my own machine to work on it. Therefore, the actually sensitive data that would be cost me a lot if compromised is never available unencrypted on the VPS. Due to the overhead of this encryption and other complications, I don’t do this for all my files.
Best option is to directly NAT traffic from VPS to your home server, either directly to your IP or set up a wireguard peer and send traffic via wireguard to your local and do the SSL/TLS termination on your local.
You are best exposing just 443 port on the VPS and moving that traffic over wireguard. Server will have your local public key on the server, and you could implement a wireguard key rotation to change them frequently.
Traffic sent back will be encrypted with the certificate, and even if they get the wireguard server key, you can rotate it, but still they will see encrypted packets.
It depends what kind of things you’re doing on your local. If it is just a website thing, then reverse proxy is fine. Anything other than that, NAT would be cleanest one.
LUKS on the disks would encrypt it the data on the block storage level, and, in theory, they should not have a way of reding block storage files directly.
But since it is a VPS they can, technically, gather data from host memory.
Next step might be going down a dedi server route, Luks encryption on disks. Only thing thats needed there would be sufficient network pipe.
No problem. I’ll just go with a oversimplification.
The idea is that you just take whatever traffic hits port 443 and use iptables rules to route the traffic elsewhere, or in this case
Client --> [port 443] --> [iptables] --> [ port 443 home server]
So, it’s basically just traffic forwarding from the VPS directly to your home server, being directly to your ISP IP address, or via wireguard IP address.
So all the traffic you are sending back from the VPS is in its original state, and the actual processing happens on your local/home server.
On the home server you have a Web Server of your choice listening on port 443 with, loaded with your SSL certificates.
So, request is made to the VPS IP address, iptables just forward the packets to your home server, and there is where the SSL/TLS termination happens. The client negotiates the TLS connection directly with your home server, and web server on your home server then sends the request where you tell it to ( reverse proxy to a docker container, or it serves the content directly).
With this, you basically turn the VPS into a passtrough for traffic.
Here’s a quick test I did… the two servers are connected with Wireguard mesh.
On the VPS you need have net.ipv4.ip_forward=1 .
net.ipv4.ip_forward=1
Your iptables rules should be. Obviously on the home server you can run the webserver on any port you like, doesn’t have to be 443. But let’s keep it 443 for the sake of argument.
iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to-destination HOME_SERVER_IP:443
iptables -t nat -A POSTROUTING -j MASQUERADE
Thank you for the answer. I was hoping that I could implement a DNAT on the VPS box and then have HAProxy on my router do the SSL termination and serve requests. Just to be sure, that would be possible, yes? I understood how the system works, thanks a bunch!
Yes, that would be possible with this setup. Port on which HAProxy listens just needs to be publicly accessible, and just DNAT traffic from the VPS to your $IP:$PORT .
Technically everything is possible, I just don’t have context if you have a static IP with your ISP or it changes every so often (daily, weekly, every n months). If it’s not, you might consider using a VPN connection between VPS and your router to keep the connection open at all times, and also not exposing HAProxy directly to the live internet.
Hi, I’m behind CGNAT. I’m definitely going to connect my router to my VPS instance using Wireguard.
I will be using a domain name for my VPS to connect to it via Wireguard.
Just to summarise: hold SSL certificates within HAProxy, and use DNAT on the VPS to direct traffic towards the Wireguard tunnel. When traffic reaches my router, it is passed into HAProxy, which terminates SSL and sends the traffic to my applications.
Yes, thats exactly it.
Make sure your HAProxy is listening on the wireguard interface as well.
Once you have the wireguard tunnel working, do a quick test, like curl -H "Host: domain.tld" https://router_wireguard_ip/ and if that works, add in the iptables roules and you should be all set.
Something else to consider is Cloudflare tunnels. They are free and quite handy.
Essentially, it creates a secure wiregiard connection between you and cf so you don’t need to open any ports or have a reverse proxy on your side. Then, cf becomes the end point and where dns points.
Cf essentially hosts your reverse proxy for you and you so all the config on their site once you get the tunnel setup. The Cloudflared docker is all that I had to set up.
Its essentially what you are doing with the vps, but purpose built and free.
DNS is very leaky no matter where you run it, unless you run DNS over HTTPS (DoH). Full stop.
I’m no fan of DoH because it scales poorly. Nevertheless, a combination of Tailscale (or tailscale-like securort overlay mesh network) and an in-mesh DoH DNS relay going to be more secure than most other setups. Relay the DNS out through Tor at your own (performance) peril, but that’s going to he very secure.
I’m not a practitioner of this method, but it’s how I would approach it if I needed to.
It sounds like you’re doing something very similar to me. I run my Lemmy and Mastodon server out of my home. I have a wireguard tunnel between that server and my cloud VPS. The cloud VPS handles reverse proxying. The information that I am most likely leaking is metadata. Metadata is surprisingly useful. In an ideal world we could secure and obfuscate everything. For the most part though, your traffic is secure and your cloud provider won’t be able to really get more than your metadata.
I don’t think it’s just metadata that’s leaking though. I would say it’s the entire content of the connection. If the reverse proxy terminates the secure connection it will decrypt the data which will be available unencrypted in the VPS. Outside of the VPS instance the traffic remains entirely encrypted.
Admittedly this decrypted data is not easy to access - you would need to have root access and be able to capture the traffic from within the VPS. But a VPS provider has this kind of access - as they run the hypervisor, they have direct access to the RAM (and possibly even a much easier way to just log in as root into the VPS itself). I think you do have to trust the VPS provider not to peek into the VPS itself. As long as you’re paying for the service, that’s probably a safe assumption.
There is no easy way to just log into the VPS as root just because you run the host. There are probably exploits that could do it but there is no simple included tool to do so.
It would probably be easier to just hook into the (likely known) VPS kernel doing something similar to the sslsniff tool from the bpfcc-tools package (hook into the openssl, gnutls,… ssl decryption functions basically).
I’m using a SSH tunnel to connect a port on my vps to a port on my home server. I have rhevssl certificates both on the vps and the home server (I trust the vps provider), but I’m pretty sure (correct me if I’m wrong!) that this would work with the certificates only on the home server. Could the vps provider do a mitm then? I’m not sure, the packets go in one port and are directly forwarded to my home server.
Can the vps provider get their own certificates? That’s a good question. I guess you could check the certificate when connecting to prevent tampering. Datetime of issue alone should be enough since vps providers can’t fake that. Unless you don’t trust CAs either :)
They will always be able to see the peer’s IP and port, the time packets are sent and the amount of data of course. They will also be able to see the SNI field of the client hello TLS packet, telling them which domains the client is trying to reach.
I am sad, and ashamed, that you had to continuously point towards it being “a hobby exercise” - without which the only answers you would get are “change your VPS provider bro” or “you’re too scared bro”. Paranoid or not, these questions are important to understand and answer (network security is not easy when you get into such concepts), regardless where they are coming from. I am positively dismayed; aggravated even, that even in such a community where people know so much, the first thought that would come to their mind is “just trust them bro”.
That said, you are correct. The VPS can absolutely inspect your storage + RAM and scrape the keys/certificates. Considering that Cloudflare tunnels are much worse, I’d rather stick with a VPS, but the problems remain.
I wonder if LUKS can be used for the underlying storage hosting these certificates. Although, will that help if the RAM of the device is compromised?
If it was just storage/RAM scraping then that could be solved with SSL pass-through though. That way the reverse proxy would not decrypt the traffic and would forward the encrypted traffic further to the home server. I was actually setting that up a few hours ago. However, since the VPS provider owns the IP address of the VPS, they can simply obtain their own certificate for the domain. After all, Let’s Encrypt verifies your ownership of the domain by your ability to control the DNS entries. Therefore, even if the certificates weren’t on the VPS, the fact that I am redirecting traffic via their IP address makes me vulnerable to a malicious provider.
The “hobby exercise” was just to indicate that this is not for work and that I’m interested in an answer beyond “you need to trust your provider” which I do :) I agree, these are important questions! And they’re also interesting!
the VPS provider can always get their own certificates for my domains and do a MitM attack.
You can limit which CA’s will offer certificates for your domain with the CAA record in DNS. You can also at least detect if someone else creates a certificate for your domain if you watch the certificate transparency logs.
CAA can also be used to disable http verification, meaning you would have to have control of DNS to be able to get a certificate (which the VPS ideally wouldn’t have).
I didn’t know about that extensions. Thanks for mentioning it. Apparently you can also select which CA account should be the only one allowed to issue certificates for a domain via DNS too.
Terminate the ssl connection at a reverse proxy hosted in your home server, and instead useiptables to redirect the traffic through the wireguard interface
Thanks for the suggestion! That is also doable with Nginx’s SSL pass-through. However, that is still vulnerable to the VPS provider obtaining a certificate. But indeed, it does appear that a combination of redirecting encrypted traffic (SSL passthrough or iptables) with cert monitoring appears to be emerging as a solution.
BTW, I prefer SSL pass-through over iptables, because I do keep one endpoint on the VPS and that’s my static website which also needs a cert. With SSL pass-through I can terminate connections to the static website while redirecting all other connections as it can pre-read the destination domain. With iptables I would need two IP addresses to distinguish the connections.
You are correct. The provider owns the IP and also VPS. They theoretically have the ability to do anything within those confines. Same thing with your nameserver provider with your DNS records and the domain itself with the registrar. There’s a certain level of trust that needs to be accepted for anything that goes outside the confines of your house. The good thing is those companies have more to lose than you by breaking that level of trust.
Well, technically you only have to trust your DNS registrar minimally if you use DNSSEC and only use your DNS hoster’s servers as slave servers. The registrar could always DoS you of course by not entering new DNSSEC zone signing keys into the parent zone and the hoster by removing your zone from their servers but they can not technically publish any records in your name in that case or prevent individual records from being published (unless those are new and they just keep serving an old version of your zone).
Could you explain more about this? I’m very new to DNS, and cannot grasp how using DNSSEC prevent the VPS from tampering with DNS and how we only “minimally” rely on the DNS provider?
I actually made a mistake in my previous post by writing zone signing keys when I meant key signing keys.
Basically in DNSSEC there is a hierarchy of keys all the way from the DNSSEC root zone keys. Each DNSSEC-enabled domain has some key signing keys which have a signature signed by the parent zone’s keys stored in the parent zone as DS records similar to the way NS records are stored in the parent zone. This is done by the registrar for your domain. So e.g. the DS records for itjust.works would be stored in the works zone and the ones for works would be stored in the DNS root zone.
The domain owner can then use the key signing key to sign a regularly changing zone signing key (e.g. KSK might be valid for a year and ZSK for a month with some overlap to avoid outages). Both KSKs and ZSKs are stored in the zone itself as DNSKEY records.
The zone signing key is then used to sign each individual record in the zone. There is also a mechanism to certify that all the names in between and the records of other types do not exist but I don’t know the details of that. It is specifically designed to prevent enumeration of all existing records though.
So if you do all your zone signing on, say, your home server and only publish the zone via zone transfer on some DNS slave servers the organisation or person running your DNS slave servers will not be able to do anything other than publish it as is, publish an outdated version they received from you before (in which case you could switch out your DNSSEC keys to make that invalid) or not publish it at all (Denial of Service) but they could not publish their own records or modify the records you published.
Of course the caveat with that is that it only works if the clients actually validate the DNSSEC signatures of the zone/records but more and more do in recent years.
I don’t think I know enough about DNSSEC (and DNS in general) to understand what you have just mentioned. My apologies, I’ll get back to you once I’m comfortable with these technologies
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
Best option is to directly NAT traffic from VPS to your home server, either directly to your IP or set up a wireguard peer and send traffic via wireguard to your local and do the SSL/TLS termination on your local.
You are best exposing just 443 port on the VPS and moving that traffic over wireguard. Server will have your local public key on the server, and you could implement a wireguard key rotation to change them frequently.
Traffic sent back will be encrypted with the certificate, and even if they get the wireguard server key, you can rotate it, but still they will see encrypted packets.
It depends what kind of things you’re doing on your local. If it is just a website thing, then reverse proxy is fine. Anything other than that, NAT would be cleanest one.
LUKS on the disks would encrypt it the data on the block storage level, and, in theory, they should not have a way of reding block storage files directly. But since it is a VPS they can, technically, gather data from host memory.
Next step might be going down a dedi server route, Luks encryption on disks. Only thing thats needed there would be sufficient network pipe.
Hi, could you explain the concept of DNAT, SSL termination and how using DNAT lets us terminate TLS at our home? I’m a bit confused
No problem. I’ll just go with a oversimplification.
The idea is that you just take whatever traffic hits port 443 and use iptables rules to route the traffic elsewhere, or in this case
Client --> [port 443] --> [iptables] --> [ port 443 home server]
So, it’s basically just traffic forwarding from the VPS directly to your home server, being directly to your ISP IP address, or via wireguard IP address.
So all the traffic you are sending back from the VPS is in its original state, and the actual processing happens on your local/home server.
On the home server you have a Web Server of your choice listening on port 443 with, loaded with your SSL certificates. So, request is made to the VPS IP address, iptables just forward the packets to your home server, and there is where the SSL/TLS termination happens. The client negotiates the TLS connection directly with your home server, and web server on your home server then sends the request where you tell it to ( reverse proxy to a docker container, or it serves the content directly).
With this, you basically turn the VPS into a passtrough for traffic.
Here’s a quick test I did… the two servers are connected with Wireguard mesh.
On the VPS you need have net.ipv4.ip_forward=1 .
Your iptables rules should be. Obviously on the home server you can run the webserver on any port you like, doesn’t have to be 443. But let’s keep it 443 for the sake of argument.
If you want to drop the rules:
Thank you for the answer. I was hoping that I could implement a DNAT on the VPS box and then have HAProxy on my router do the SSL termination and serve requests. Just to be sure, that would be possible, yes? I understood how the system works, thanks a bunch!
Yes, that would be possible with this setup. Port on which HAProxy listens just needs to be publicly accessible, and just DNAT traffic from the VPS to your $IP:$PORT .
Technically everything is possible, I just don’t have context if you have a static IP with your ISP or it changes every so often (daily, weekly, every n months). If it’s not, you might consider using a VPN connection between VPS and your router to keep the connection open at all times, and also not exposing HAProxy directly to the live internet.
Hi, I’m behind CGNAT. I’m definitely going to connect my router to my VPS instance using Wireguard.
I will be using a domain name for my VPS to connect to it via Wireguard.
Just to summarise: hold SSL certificates within HAProxy, and use DNAT on the VPS to direct traffic towards the Wireguard tunnel. When traffic reaches my router, it is passed into HAProxy, which terminates SSL and sends the traffic to my applications.
Did I get it right?
Yes, thats exactly it. Make sure your HAProxy is listening on the wireguard interface as well. Once you have the wireguard tunnel working, do a quick test, like
curl -H "Host: domain.tld" https://router_wireguard_ip/and if that works, add in the iptables roules and you should be all set.@dr_robot
Something else to consider is Cloudflare tunnels. They are free and quite handy.
Essentially, it creates a secure wiregiard connection between you and cf so you don’t need to open any ports or have a reverse proxy on your side. Then, cf becomes the end point and where dns points.
Cf essentially hosts your reverse proxy for you and you so all the config on their site once you get the tunnel setup. The Cloudflared docker is all that I had to set up.
Its essentially what you are doing with the vps, but purpose built and free.
DNS is very leaky no matter where you run it, unless you run DNS over HTTPS (DoH). Full stop.
I’m no fan of DoH because it scales poorly. Nevertheless, a combination of Tailscale (or tailscale-like securort overlay mesh network) and an in-mesh DoH DNS relay going to be more secure than most other setups. Relay the DNS out through Tor at your own (performance) peril, but that’s going to he very secure.
I’m not a practitioner of this method, but it’s how I would approach it if I needed to.
It sounds like you’re doing something very similar to me. I run my Lemmy and Mastodon server out of my home. I have a wireguard tunnel between that server and my cloud VPS. The cloud VPS handles reverse proxying. The information that I am most likely leaking is metadata. Metadata is surprisingly useful. In an ideal world we could secure and obfuscate everything. For the most part though, your traffic is secure and your cloud provider won’t be able to really get more than your metadata.
I don’t think it’s just metadata that’s leaking though. I would say it’s the entire content of the connection. If the reverse proxy terminates the secure connection it will decrypt the data which will be available unencrypted in the VPS. Outside of the VPS instance the traffic remains entirely encrypted.
Admittedly this decrypted data is not easy to access - you would need to have root access and be able to capture the traffic from within the VPS. But a VPS provider has this kind of access - as they run the hypervisor, they have direct access to the RAM (and possibly even a much easier way to just log in as root into the VPS itself). I think you do have to trust the VPS provider not to peek into the VPS itself. As long as you’re paying for the service, that’s probably a safe assumption.
There is no easy way to just log into the VPS as root just because you run the host. There are probably exploits that could do it but there is no simple included tool to do so.
It would probably be easier to just hook into the (likely known) VPS kernel doing something similar to the sslsniff tool from the bpfcc-tools package (hook into the openssl, gnutls,… ssl decryption functions basically).
I’m using a SSH tunnel to connect a port on my vps to a port on my home server. I have rhevssl certificates both on the vps and the home server (I trust the vps provider), but I’m pretty sure (correct me if I’m wrong!) that this would work with the certificates only on the home server. Could the vps provider do a mitm then? I’m not sure, the packets go in one port and are directly forwarded to my home server.
Can the vps provider get their own certificates? That’s a good question. I guess you could check the certificate when connecting to prevent tampering. Datetime of issue alone should be enough since vps providers can’t fake that. Unless you don’t trust CAs either :)
Technically you’re correct: your VPS provider can inspect your network traffic, the contents of RAM and anything on the disk.
Bluntly: you have to trust your VPS provider, and if you’re unsure they’re trustworthy you shouldn’t use them.
(Scaleway is legitimate, bound by actual useful data protection laws, and has a comprehensive privacy and security policy.)
You could try destination NAT with netfilter/iptables (DNAT) and terminate TLS on your home server.
This way packets will be forwarded to the home server without beign decrypted on the VSP.
deleted by creator
That’s an interesting solution. But could the cloud VPS provider still see the metadata?
They will always be able to see the peer’s IP and port, the time packets are sent and the amount of data of course. They will also be able to see the SNI field of the client hello TLS packet, telling them which domains the client is trying to reach.
I am sad, and ashamed, that you had to continuously point towards it being “a hobby exercise” - without which the only answers you would get are “change your VPS provider bro” or “you’re too scared bro”. Paranoid or not, these questions are important to understand and answer (network security is not easy when you get into such concepts), regardless where they are coming from. I am positively dismayed; aggravated even, that even in such a community where people know so much, the first thought that would come to their mind is “just trust them bro”.
That said, you are correct. The VPS can absolutely inspect your storage + RAM and scrape the keys/certificates. Considering that Cloudflare tunnels are much worse, I’d rather stick with a VPS, but the problems remain.
I wonder if LUKS can be used for the underlying storage hosting these certificates. Although, will that help if the RAM of the device is compromised?
Cheers
If it was just storage/RAM scraping then that could be solved with SSL pass-through though. That way the reverse proxy would not decrypt the traffic and would forward the encrypted traffic further to the home server. I was actually setting that up a few hours ago. However, since the VPS provider owns the IP address of the VPS, they can simply obtain their own certificate for the domain. After all, Let’s Encrypt verifies your ownership of the domain by your ability to control the DNS entries. Therefore, even if the certificates weren’t on the VPS, the fact that I am redirecting traffic via their IP address makes me vulnerable to a malicious provider.
The “hobby exercise” was just to indicate that this is not for work and that I’m interested in an answer beyond “you need to trust your provider” which I do :) I agree, these are important questions! And they’re also interesting!
Is there a way to be notified when certificates for a particular domain are created?
Apparently yes! Based on another comment in this thread: https://certificate.transparency.dev/monitors/.
You can limit which CA’s will offer certificates for your domain with the CAA record in DNS. You can also at least detect if someone else creates a certificate for your domain if you watch the certificate transparency logs.
CAA can also be used to disable http verification, meaning you would have to have control of DNS to be able to get a certificate (which the VPS ideally wouldn’t have).
I didn’t know about that extensions. Thanks for mentioning it. Apparently you can also select which CA account should be the only one allowed to issue certificates for a domain via DNS too.
Thank you, this is most helpful
Yea, I already have that.
Did not know this before today, but now I have it switched on!
If you’re concerned that you VPS provider is replacing your certificates you need to find another provider.
You should also look in to certificate transparency monitoring. I get notified anytime a certificate gets issued for one of my domains.
No, I’m not concerned. This is just a theoretical exercise so that I can understand the trade-offs I’m making.
Edit: The certificate transparency monitoring sounds interesting. Did not know about that.
Terminate the ssl connection at a reverse proxy hosted in your home server, and instead useiptables to redirect the traffic through the wireguard interface
Thanks for the suggestion! That is also doable with Nginx’s SSL pass-through. However, that is still vulnerable to the VPS provider obtaining a certificate. But indeed, it does appear that a combination of redirecting encrypted traffic (SSL passthrough or iptables) with cert monitoring appears to be emerging as a solution.
BTW, I prefer SSL pass-through over iptables, because I do keep one endpoint on the VPS and that’s my static website which also needs a cert. With SSL pass-through I can terminate connections to the static website while redirecting all other connections as it can pre-read the destination domain. With iptables I would need two IP addresses to distinguish the connections.
You are correct. The provider owns the IP and also VPS. They theoretically have the ability to do anything within those confines. Same thing with your nameserver provider with your DNS records and the domain itself with the registrar. There’s a certain level of trust that needs to be accepted for anything that goes outside the confines of your house. The good thing is those companies have more to lose than you by breaking that level of trust.
Well, technically you only have to trust your DNS registrar minimally if you use DNSSEC and only use your DNS hoster’s servers as slave servers. The registrar could always DoS you of course by not entering new DNSSEC zone signing keys into the parent zone and the hoster by removing your zone from their servers but they can not technically publish any records in your name in that case or prevent individual records from being published (unless those are new and they just keep serving an old version of your zone).
Could you explain more about this? I’m very new to DNS, and cannot grasp how using DNSSEC prevent the VPS from tampering with DNS and how we only “minimally” rely on the DNS provider?
Also, could you explain more zone signing keys?
I actually made a mistake in my previous post by writing zone signing keys when I meant key signing keys.
Basically in DNSSEC there is a hierarchy of keys all the way from the DNSSEC root zone keys. Each DNSSEC-enabled domain has some key signing keys which have a signature signed by the parent zone’s keys stored in the parent zone as DS records similar to the way NS records are stored in the parent zone. This is done by the registrar for your domain. So e.g. the DS records for itjust.works would be stored in the works zone and the ones for works would be stored in the DNS root zone.
The domain owner can then use the key signing key to sign a regularly changing zone signing key (e.g. KSK might be valid for a year and ZSK for a month with some overlap to avoid outages). Both KSKs and ZSKs are stored in the zone itself as DNSKEY records.
The zone signing key is then used to sign each individual record in the zone. There is also a mechanism to certify that all the names in between and the records of other types do not exist but I don’t know the details of that. It is specifically designed to prevent enumeration of all existing records though.
So if you do all your zone signing on, say, your home server and only publish the zone via zone transfer on some DNS slave servers the organisation or person running your DNS slave servers will not be able to do anything other than publish it as is, publish an outdated version they received from you before (in which case you could switch out your DNSSEC keys to make that invalid) or not publish it at all (Denial of Service) but they could not publish their own records or modify the records you published.
Of course the caveat with that is that it only works if the clients actually validate the DNSSEC signatures of the zone/records but more and more do in recent years.
I don’t think I know enough about DNSSEC (and DNS in general) to understand what you have just mentioned. My apologies, I’ll get back to you once I’m comfortable with these technologies