<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">TL;DR Don't do this. It is not going to work as the origin of the RRSIG would different.<div><br></div><div><div>gitlab.isc.org.<span class="Apple-tab-span" style="white-space:pre"> </span>7200 IN<span class="Apple-tab-span" style="white-space:pre"> </span>A 52.201.58.154</div><div>gitlab.isc.org.<span class="Apple-tab-span" style="white-space:pre"> </span>7200 IN<span class="Apple-tab-span" style="white-space:pre"> </span>RRSIG A 13 3 7200 (</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>20241222045850 20241208044609 27566 isc.org.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>V1qzQZGbfd7XiEjcylcTESXkMF1D7+nRh3MocRAOqtkS</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>X+75a/sojGkDmoaaxYpZoJzU9GHkzmnilrz/3k5b0A== )</div></div><div><br></div><div>See the little 'isc.org'? That needs to match the zone, and it is going to contain <a href="http://bar.example.com">bar.example.com</a> instead of <a href="http://example.com">example.com</a> if the subdomain is correctly signed.</div><div><br></div><div>Ondrej<br id="lineBreakAtBeginningOfMessage"><div>
<meta charset="UTF-8"><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">--</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Ondřej Surý (He/Him)</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">ondrej@isc.org</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.</div></div></div></div>
</div>
<div><br><blockquote type="cite"><div>On 10. 12. 2024, at 20:07, Nick Tait via bind-users <bind-users@lists.isc.org> wrote:</div><br class="Apple-interchange-newline"><div><div>Just an idea, but what if you copy the current ZSK key files from the example.com zone and rename the files (i.e. add “bar” into the filenames) so it will be picked up by the bar.example.com zone? In theory that should populate bar.example.com with the correct RRSIG records prior to removing the split?<br>(BTW just check that example.com ZSK lifetime is long enough to implement all this before you start.)<br><br>Nick.<br><br><blockquote type="cite">On 10 Dec 2024, at 10:12 PM, Petr Špaček <pspacek@isc.org> wrote:<br><br>Hello Chris.<br><br>My take is that the *will* be some sort of breakage even if you do everything right with shortest possible TTLs - because this is the DNS, eventually consistent by design, and wildly misimplemented in practice. So don't feel bad when some breakage occurs :-) It will very much depend on your client population, which presumably you don't have control over.<br><br>Anyway, I would say that going to 1 second TTL for NS/SOA/DNSKEY/DS/NSEC* RRs first is a good idea - for the records below the (to-be-removed) zone cut.<br><br>In theory RRs above the cut can have the "target" TTLs right away, but if you are concerned about breakage you might want to lower TTLs just in case, so you have flexibility to react. (But be prepared for clients which don't respect TTL ...)<br><br><br>To your questions about names which are in the parent zone but (currently) below (the old) zone cut - these will not get signed and not show up in the NSEC* chains because they are occluded/not authoritative in the parent zone.<br><br>Let us know how it vent, maybe there will be a lesson to learn for everyone! (Also if it just works - that's useful information as well!)<br><br>HTH.<br>Petr Špaček<br>Internet Systems Consortium<br><br><br><blockquote type="cite">On 10. 12. 24 7:48, Ondřej Surý wrote:<br>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.<br>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.<br>Ondrej<br>--<br>Ondřej Surý — ISC (He/Him)<br>My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.<br><blockquote type="cite"><blockquote type="cite">On 10. 12. 2024, at 7:27, Crist Clark <cjc+bind-users@pumpky.net> wrote:<br></blockquote><br><br>We have a zone, "bar.example.com <http://bar.example.com>," that is all properly delegated from "example.com <http://example.com>." Although the subzone still has many records, "foo.bar.example.com <http://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 <http://example.com> zone. That is, foo.bar.example.com <http://foo.bar.example.com> would now just be in example.com <http://example.com>.<br><br>The first thing that ups the degree of difficulty is DNSSEC. example.com <http://example.com> is signed. bar.example.com <http:// bar.example.com> is properly delegated and also signed. How do we make the transition without invalidating bar.example.com <http:// bar.example.com> and its contents? I can't think of a way to transition bar.example.com <http://bar.example.com> without going insecure, letting that propagate out, and then folding bar.example.com <http://bar.example.com> into example.com <http://example.com>. Or is there some way we could do it without going insecure first?<br><br>I am also a little concerned about pre-loading the multi-label names at bar.example.com <http://bar.example.com> and above into example.com <http://example.com>. example.com <http://example.com> and bar.example.com <http://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 <http:// example.com> while the server still is serving bar.example.com <http://bar.example.com>? Would we want to go insecure with example.com <http://example.com> too, just to be safe?<br><br>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 <http:// bar.example.com> cached. It goes to ask for "doesntexist.bar.example.com <http://doesntexist.bar.example.com>" and gets a NXDOMAIN with an SOA for example.com <http://example.com> in the auth section. It's expecting the SOA for bar.example.com <http:// bar.example.com>. A standard-compliant resolver won't accept that.<br><br>Am I just over-thinking this? Just lower the TTLs on the NS and DS records for bar.example.com <http://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?<br><br>We're using BIND dnssec-policy to manage DNSSEC for the zones.<br></blockquote></blockquote>--<br>Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list<br><br>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.<br><br><br>bind-users mailing list<br>bind-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/bind-users<br></blockquote>-- <br>Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list<br><br>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.<br><br><br>bind-users mailing list<br>bind-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/bind-users<br></div></div></blockquote></div><br></div></body></html>