On Tue, Aug 10, 2021 at 11:24:31AM -0500, Tim Daneliuk via bind-users <bind-users@lists.isc.org> wrote:
> On 8/10/21 10:07 AM, Matthijs Mekking wrote: > >> So just to be sure I'm doing the right thing, I've added this to my > >> options stanza: > >> > >> dnssec-policy "default"; > >> > >> Then restarted named and now all the signing magic is taken care of for > >> me for all zones? (I was not previously using signing.) > > > > Correct. > > > > But you still need to manually submit the DS record to your > > registrar/parent and if you see the DS published run: > > > > rndc dnssec -checkds published <zone>. > > I've never done any of the signing work before (other than for master/slave). > Could you kindly point me to something like > > "DS Record Creation And Implementation For Dummies"? > > Thanks, > > ---------------------------------------------------------------------------- > Tim Daneliuk tun...@tundraware.com > PGP Key: http://www.tundraware.com/PGP/ > _______________________________________________ Hi Tim, Here goes! My NOVICE understanding is that bind will create CDS (and CDNSKEY) records automatically to match the (KSK or CSK) DNSKEY records that it also creates automatically. Use dig cds ZONE to see them. The CDS record is the child version of the DS record and it contains same information. The CDS/CDNSKEY records reside in your zones, and they exist to facilitate the automatic uploading of DS records to parent zones, but registrars (or TLDs?) haven't implemented this yet. Even when they do, the first time will be manual. Until they do, it's always manual (if you do key rollovers - but that's not the default). So, that DS information MUST be manually conveyed to the registrar so that they can get it published and signed in the parent/TLD zone. How you do this is determined by each registrar. Hopefully, they will have a web interface for adding/removing DS records. Or it might be via email. If your registrar can't accept DS records, consider transferring to a registrar that does (and maybe let them know why you are leaving). Once you can see that the DS record has been published in the DNS (dig ds ZONE), you then tell bind that this has happened by running: rndc dnssec -checkds -key ID published ZONE The ID is the first number in the DS record (e.g. 12345). If using dnssec-policy default, that's it, because the key lasts forever. But if you have your own policy that involves key rollover, you will need to monitor for the future appearance of new KSK DNSKEY/CDS/CDNSKEY records as they get created by bind in the lead up to a rollover (dig cds ZONE). When they appear, you repeat the above process to convey the new DS information to the registrar, and you also manually delete the old DS record via the registrar (at the same time is OK, or afterwards, but NOT before), and when you see that the old DS has been removed from the DNS, you then tell bind that this has happened by running: rndc dnssec -checkds -key ID withdrawn ZONE I think that causes bind to delete the records related to the old KSK (i.e. DNSKEY/CDS/CDNSKEY), and to eventually delete the keys from disk. At least, that's what I'm planning to do. :-) And I'm setting up a cronjob to monitor for changes in DNSKEY/CDS records and email me when it happens. But that's not needed with the default policy. Here's Matthijs's short version: 1. Monitor, look for new KSKs 2. Upload the DS once the CDS/CDNSKEY for the KSK is published. 3. Request the old DS to be removed. 3. Wait for the new DS to appear (the old DS should be replaced). 4. Run "rndc dnssec -checkds -key ID published ZONE" 5. Run "rndc dnssec -checkds -key ID withdrawn ZONE" 6. Done. cheers, raf _______________________________________________ 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