>From what Ondřej says, if you can temporarily move the bar.example.com zone to a different set of nameservers, that would be much safer. Then you add the new records and remove the NS delegation of bar from the example.com zone, and wait for TTL's to expire. I would also turn down the TTL's everywhere during the transition, but not everyone honors that - one of the public DNS providers limits TTLs to something like the 30 second to 8 hour range, if I remember correctly.
-- Bob Harold On Tue, Dec 10, 2024 at 1:48 AM Ondřej Surý <ond...@isc.org> wrote: > Chris, that depends whether both are on the same nameservers or not. If > not then you can just fold first and then wait out the TTLs. If yes then it > can get hairy and I would suggest to reduce the TTL on the delegation > records to some small number (in the order of minutes). Perhaps also reduce > TTL on SOA and DNSKEY records just to be sure nothing stays in the cache > for too long. > > Then before the change I would change those TTLs to 0, wait out the > previous TTL, and then again just fold the data, and the resolvers should > immediately switch to new chain. > > Ondrej > -- > Ondřej Surý — ISC (He/Him) > > My working hours and your working hours may be different. Please do not > feel obligated to reply outside your normal working hours. > > On 10. 12. 2024, at 7:27, Crist Clark <cjc+bind-us...@pumpky.net> wrote: > > > We have a zone, "bar.example.com," that is all properly delegated from " > example.com." Although the subzone still has many records, " > foo.bar.example.com" and such, the administrative reasons for having it > as a separate zone are not so important anymore, and it would be convenient > to simply manage it as multi-label names all within the example.com zone. > That is, foo.bar.example.com would now just be in example.com. > > The first thing that ups the degree of difficulty is DNSSEC. example.com > is signed. bar.example.com is properly delegated and also signed. How do > we make the transition without invalidating bar.example.com and its > contents? I can't think of a way to transition bar.example.com without > going insecure, letting that propagate out, and then folding > bar.example.com into example.com. Or is there some way we could do it > without going insecure first? > > I am also a little concerned about pre-loading the multi-label names at > bar.example.com and above into example.com. example.com and > bar.example.com have the same NS records, the same servers. Could > it present any issues having those "hidden" records and their associated > NSEC3 records in example.com while the server still is serving > bar.example.com? Would we want to go insecure with example.com too, just > to be safe? > > Even without DNSSEC, there are some problems. If we manage an > instantaneous change on all of the authoritative servers at once, we can > still have cached records out there. You could still have a resolver with > the NS and SOA of bar.example.com cached. It goes to ask for " > doesntexist.bar.example.com" and gets a NXDOMAIN with an SOA for > example.com in the auth section. It's expecting the SOA for > bar.example.com. A standard-compliant resolver won't accept that. > > Am I just over-thinking this? Just lower the TTLs on the NS and DS records > for bar.example.com as far as we dare, and make the changes and hope for > the fewest inconsistencies possible? Are there some steps to take to do > this with minimal chances for inconsistencies and breakage? > > We're using BIND dnssec-policy to manage DNSSEC for the zones. > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users >
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
