Re: dnssec-policy: Old DNSKEYs still in zone despite status showing hidden
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. Is the idea that you query the parental agent to see that they've picked up the CDS and then you trust that the parent zone will be updated within the parent-propagation-delay? That doesn't seem right; you'd want to make sure that the new DS is visible to the world, right? Not really. BIND will query the parental agent to see if they published the DS (corresponding to the CDS, yes). So it knows for sure it is visible to the world. The parent-propagation-delay is a safety delay to ensure that the DS has been published to all parent secondaries. Best regards, Matthijs Thanks, -- 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
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. 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 Best regards, Matthijs -- 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
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. Is the idea that you query the parental agent to see that they've picked up the CDS and then you trust that the parent zone will be updated within the parent-propagation-delay? That doesn't seem right; you'd want to make sure that the new DS is visible to the world, right? Thanks, -- 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
onsdag 10 augusti 2022 kl. 11:21:11 CEST skrev Matthijs Mekking: > The subject of the mail seems to indicate a different problem than the > body, or am I missing something? Thanks for the reply. I probably should have changed the subject after I solved the problem midway. -- Magnus Holmgren, utvecklare MILLNET AB, Datalinjen 1, 583 30 Linköping Direkt: 013-470 40 09 Växel: 013-470 40 00 Support: 013-470 40 19 -- 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