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
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
dnssec-policy: Old DNSKEYs still in zone despite status showing hidden
Hi, I migrated a couple of zones from BIND 9.16.6 on SuSE to 9.16.27 on Debian and at the same time switched from auto-dnssec maintain to a dnssec-policy with RSASHA256 instead of RSASHA1 (actually, I first applied a policy matching the old keys and with unlimited lifetime to avoid confusing BIND). Though it seems to take longer than expected to finish a key rollover, even taking into account propagation delay, TTLs, and retire-safety, the old keys were eventually removed from the first zone. One zone I'm still waiting for, and that rollover started Friday. 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? 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.) -- 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
nsupdate -g always uses master from SOA to form SPN
When using GSS-TSIG, nsupdate (with the -g flag) always forms the SPN from the master server specified in the SOA record, rather than the server specified with the server command. Is that really correct behaviour, or should I report this as a bug? I've been scouring the Internet, but couldn't find any prior discussion about this particular situation. The issue arises when employing a hidden primary, and the server in the SOA record is actually a secondary, which I though was a rather common setup. In this situation, the real primary has to be specified with the server command, and I thought the SPN should represent the service and server being communicated with. I can work around the problem by adding an SPN matching the SOA primary to Kerberos, but AFAIU, BIND can only be configured (tkey-gssapi-credential) to use a single SPN to look up keys in the keytab, so all the SPNs involved have to be aliases of each other, it seems. -- Magnus Holmgren MILLNET AB -- Vid e-postkontakt med Millnet är det normalt att åtminstone vissa personuppgifter sparas om dig. Du kan läsa mer om vilka uppgifter som sparas och hur vi hanterar dem på https://www.millnet.se/integritetspolicy/ <https://www.millnet.se/integritetspolicy/>. ___ Please 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
