Since your private domain would be separate from the global DNS hierarchy, you would have to maintain the public key of the top level of your DNS tree (corp.) as a DNSSEC trust anchor and provision it to all DNSSEC-capable resolvers in your organization. You would also want to do the same for the highest-level applicable reverse DNS zone or zones (*.in-addr.arpa. and/or *.ip6.arpa.).
For Windows, you can apparently let Active Directory handle the distribution of the trust anchors.
For Linux, you can either rely on trusting that your resolver DNS servers validate DNSSEC for you, or if you use a DNSSEC-validating resolver at individual hosts (e.g. systemd-resolved), you would have to provide the trust anchor (one or more regular text DNS records of type DNSKEY or DS) in /etc/dnssec-trust-anchors.d/corp.positive.
If the top-level DNSSEC key needs to change, you would have to first make sure all the resolvers have the updated trust anchor available to them before actually switching the new top-level key into use. A trust anchor for a domain can include multiple public key records, one of them the active key and others either new keys waiting to be taken into use, or old keys that have been retired.
For subdomains, newer versions of BIND have built-in automation for DNSSEC key management.
For DNSSEC-validating resolvers, a DNSSEC-secured subdomain is validated by having its key provided by a parent domain's nameserver, signed with either the parent domain's key, or with the trust anchor key (at the very top of your DNSSEC hierarchy).
If a parent domain uses DNSSEC but its subdomain doesn't, the parent domain must provide a "proof of non-security" DNSSEC record for the subdomain, or else the validating resolver will assume the subdomain is a rogue one and refuse providing any information about it to the clients.
If the top of your DNS hierarchy uses DNSSEC but some delegated subdomain doesn't, that subdomain can have sub-subdomains etc. as usual, with no changes to the administration of the delegated subdomain at all.
It will be easier if the DNSSEC adoption happens in top-down fashion in the DNS hierarchy, as one trust anchor for the very top of the hierarchy will suffice; if you start bottom-up, then each DNSSEC-enabled "island" must maintain their own trust anchors until their parent domain becomes DNSSEC-enabled too (and takes up the task of maintaining a single trust anchor for itself and all its DNSSEC-secured subdomains).
