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.