Migration to inline-signing

[Crist Clark]

I tried it again to get the logs,

*21-May-2025 20:57*:12.064 general: zone sub.example.com/IN/internal:
(primary) removed

*21-May-2025 20:57*:12.064 general: reloading configuration succeeded

*21-May-2025 20:57*:12.064 general: scheduled loading new zones

*21-May-2025 20:57*:12.511 zoneload: zone sub.example.com/IN/internal
(unsigned):
loaded serial 462767 (DNSSEC signed)

*21-May-2025 20:57*:12.600 general: zone sub.example.com/IN/internal (signed):
CDS/CDNSKEY consistency checks failed

*21-May-2025 20:57*:12.600 zoneload: zone sub.example.com/IN/internal (signed):
not loaded due to errors.

*21-May-2025 20:57*:12.600 general: zone sub.example.com/IN/internal (signed):
receive_secure_db: bad CDS

I wanted to reduce it to a minimum configuration to reproduce and present
that, but I also was working on the approach of purging the zone file of
DNSSEC records. Didn't have time to do both. Removing the records wasn't as
bad as I thought, simple awk script seems to work,

{

       sub(/;.*/,"")

}

/\s(DNSKEY|CDNSKEY|DS|CDS|RRSIG|NSEC|TYPE65534)/ {

       if (/\(/) {

              while (!(/\)/)) {

                     getline

              }

       }

       next

}

{

       print

}

Although I can imagine some cases where that logic is too simple.

Purging the records and then loading the zone worked, but still wasn't as
smooth as I liked, I tried,

1. freeze
2. sync -clean
3. Copy the de-DNSSECed fzone file over the old one
4. thaw

But that would write the zone back with DNSSEC records in the file. The
only way I got it to work was to kill and restart named.

Given the actual primary is a hidden master, brief named outages for a
restart are not a big concern. That's probably good enough.


On Tue, May 20, 2025 at 1:45 AM Matthijs Mekking <matthijs at isc.org> wrote:

>
>
> On 17-05-2025 06:39, Crist Clark wrote:
> > Tired of looking at the log messages warning me that inline-signing will
> > be the default in 9.20. I want to convert my 9.18 to using
> > inline-signing. Right now all of the zones use dnssec-policy and are
> > dynamic.
> >
> > I tried just simply adding the "inlien-signing yes" line to a zone with
> > dynamic updates that has the DNSSEC records in the file, but it flat out
> > stopped the zone from loading at all when I issued a reconfig.
>
> Can you tell me the error message? I would not expect the zone stopping
> from loading, but it's hard to tell without full configuration.
>
> Note that when switching, signatures and NSEC records from the dynamic
> zone would be removed and moving to inline-signing requires a full
> re-sign of the zone.
>
> - Matthijs
>
> > I assume I could freeze, sync, clean DNSSEC records in the file, and
> > reload with inline-signing. But manually cleaning the zone file isn't
> > trivial. Not hard, but takes some work to get right.
> >
> > Is there a right way to just reconfigure named.conf to make this work
> > without messing with the zone file directly? Even if it maybe takes
> steps?
> >
> > If this really takes cleaning the DNSSEC from the zone file, is there a
> > way to coax the existing BIND tools to do this? Took a quick look at
> > named-compilezone, dnssec-signzone, etc. None seem to have the
> capability.
> >
> --
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250523/8a620c3b/attachment.htm>