TL;DR Don't do this. It is not going to work as the origin of the RRSIG would
different.
gitlab.isc.org. 7200 IN A 52.201.58.154
gitlab.isc.org. 7200 IN RRSIG A 13 3 7200 (
20241222045850 20241208044609 27566 isc.org.
V1qzQZGbfd7XiEjcylcTESXkMF1D7+nRh3MocRAOqtkS
X+75a/sojGkDmoaaxYpZoJzU9GHkzmnilrz/3k5b0A== )
See the little 'isc.org'? That needs to match the zone, and it is going to
contain bar.example.com <http://bar.example.com/> instead of example.com
<http://example.com/> if the subdomain is correctly signed.
Ondrej
--
Ondřej Surý (He/Him)
[email protected]
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 20:07, Nick Tait via bind-users
> <[email protected]> wrote:
>
> 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?
> (BTW just check that example.com ZSK lifetime is long enough to implement all
> this before you start.)
>
> Nick.
>
>> On 10 Dec 2024, at 10:12 PM, Petr Špaček <[email protected]> wrote:
>>
>> Hello Chris.
>>
>> 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.
>>
>> 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.
>>
>> 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 ...)
>>
>>
>> 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.
>>
>> 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!)
>>
>> HTH.
>> Petr Špaček
>> Internet Systems Consortium
>>
>>
>>> On 10. 12. 24 7:48, Ondřej Surý 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 <[email protected]> wrote:
>>>>
>>>>
>>>> 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>.
>>>>
>>>> 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?
>>>>
>>>> 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?
>>>>
>>>> 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.
>>>>
>>>> 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?
>>>>
>>>> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
