Re: dnssec-policy: Old DNSKEYs still in zone despite status showing hidden
torsdag 11 augusti 2022 kl. 17:47:40 CEST skrev Matthijs Mekking: > Magnus, > > On 11-08-2022 11:26, Magnus Holmgren wrote: > > onsdag 10 augusti 2022 kl. 11:21:11 CEST skrev Matthijs Mekking: > >> On 10-08-2022 11:13, Magnus Holmgren wrote: > >>> One question: Is it > >>> necessary to use rndc dnssec -checkds or is that only meant as a backup, > >>> and named is supposed to query the parent for DS records automatically? > >> > >> That depends if you have set up parental-agents. If not, then you need > >> to run 'rndc dnssec -checkds'. > > > > I see. I find the documentation a bit sparse, however. "A parental agent > > is > > the entity that is allowed to change a zone’s delegation information > > (defined in RFC 7344)."; "Parental Agent: The entity that the Child has a > > relationship with to change its delegation information." So what list of > > servers is it that I'm configuring, exactly? The "hard" part is change > > the delegation information, but that's done through CDS records, which it > > turns out our registrar supports. Verifying that the new DS record is in > > place should be a trivial matter of walking the chain from the root zone, > > should it not? Should I simply list a couple of the respective TLD's name > > servers? The registrar doesn't provide any special server(s) for the > > purpose, AFAICT. > > There are two common scenarios, I think. > > First is list all the public parent servers and add those to your > parental-agents configuration. BIND will only continue the rollover if > the new DS has been seen at all those servers. > > Second is set up a local validating resolver. When the DS is validated > by the resolver, you can assume it is published correctly in the parent. I see you suggested multiple methods in https://gitlab.isc.org/isc-projects/ bind9/-/issues/1126, with "Automatic, by walking the parents" as the default, and an option check-ds, but nothing came of that? IIUC, I have to list IP addresses of parental agents; strings are interpreted as references to other parental-agents lists. But keeping the lists of IP addresses of the TLDs' name servers up to date manually is not sustainable, so I guess I'll just point to our recursing nameserver. Regards, -- Magnus Holmgren, developer MILLNET AB, Datalinjen 1, 583 30 Linköping -- 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
Re: dnssec-policy: Old DNSKEYs still in zone despite status showing hidden
torsdag 11 augusti 2022 kl. 17:41:09 CEST skrev Matthijs Mekking: > On 10-08-2022 11:21, Matthijs Mekking wrote: > >> The last zone, milltime.se, has become stuck. sudo rndc dnssec -status > >> reports > >> that the old keys are removed from the zone and the new keys are > >> omnipresent, > >> but the log says "zone milltime.se/IN (signed): Key > >> milltime.se/RSASHA1/22971 > >> missing or inactive and has no replacement: retaining signatures." > >> > >> Never mind. I was too quick switching to NSEC3, which is incompatible > >> with the > >> old key. Switching back to NSEC allowed the rollover to complete. Still, > >> shouldn't BIND have been able to figure this out on its own? It kept > >> using > >> NSEC because of the incompatible key, and it kept the incompatible key > >> needed > >> to verify the NSEC records. Catch-22? (Yes, I've read about the > >> questionable > >> merits of NSEC3.) > > > > I think we could improve named-checkconf to error out on a policy that > > uses NSEC3 with an incompatible algorithm yes. Thanks for the suggestion. > > I jumped on this one too quickly. There is actually already a checkconf > for this. > > But your issue is slightly different. It is about configuring NSEC3 when > the previous configuration uses an incompatible DNSKEY algorithm. > > This is not easy to check with named-checkconf. But also, this is > already caught by named. > > You already witnessed some log messages indicating things are wrong: Key > milltime.se/RSASHA1/22971 missing or inactive and has no replacement: > retaining signatures." But perhaps you also saw this one: "zone > milltime.se/IN (signed): NSEC only DNSKEYs and NSEC3 chains not allowed" > which is more informative. > > You recovered from this the right way: Switch back to using NSEC, until > the old keys are gone from the zone, then you can enable NSEC3. > > At first I thought BIND9 is handling this fine, but giving it another > thought I think you are right that BIND could figure this out and rather > than blocking signing because of the erroneous state, hold off creating > NSEC3 chain until the offending DNSKEYs have been removed from the zone. Exactly. I did notice the warning about NSEC only DNSKEYs already during testing, so I didn't immediately switch to NSEC3, but then I accidentally did it prematurely anyway, but I thought that BIND would act as if the nsec3param option simply didn't exist until the old keys had been removed, and I didn't immediately connect the two warnings together. > So here is a merge request that you can try out, or you can wait until > this makes a 9.18 release: > > https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/6647 Thanks. I'll see if I find time to test it, but right now the problem doesn't exist anymore. -- Magnus Holmgren, developer MILLNET AB -- 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
