Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On Wed, Aug 11, 2021 at 12:14:38PM -0500, Tim Daneliuk via bind-users wrote: > On 8/10/21 11:27 PM, raf via bind-users wrote: > > Does that help at all? > > Very much thank you. I have now discovered my DNS key and corresponding DS > record. I believe the DS record is what I have to provide my registrar > as I understand it. > -- > > Tim Daneliuk tun...@tundraware.com > PGP Key: http://www.tundraware.com/PGP/ > ___ That's great. Although it should be a CDS record that you are seeing, not a DS record (yet), and its content is what you need to convey to your registrar so they can create the DS record in the parent zone. 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
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On 8/10/21 11:27 PM, raf via bind-users wrote: > Does that help at all? Very much thank you. I have now discovered my DNS key and corresponding DS record. I believe the DS record is what I have to provide my registrar as I understand it. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On Wed, Aug 11, 2021 at 09:40:00AM +0200, Matthijs Mekking wrote: > > Syntax question: > > In https://bind9.readthedocs.io/en/latest/dnssec-guide.html > > the double quotes are never used in the zone stanza > > where the dnssec-policy is referred to. The double > > quotes sometimes (but not always) appear in the > > dnssec-policy definition stanza. > > > > Are the double quotes optional in both cases? > > Yes, the dnssec-policy defines or refers to a name that is a string, which > may be a quoted or unquoted string. > > Some additional information on the subject: When it comes to strings, the > named.conf parser expects some options to be quoted strings (usually file > paths), some options to be unquoted strings (things like algorithm and class > names), and some options to be just strings (usually names). Thanks. ___ 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
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
Syntax question: In https://bind9.readthedocs.io/en/latest/dnssec-guide.html the double quotes are never used in the zone stanza where the dnssec-policy is referred to. The double quotes sometimes (but not always) appear in the dnssec-policy definition stanza. Are the double quotes optional in both cases? Yes, the dnssec-policy defines or refers to a name that is a string, which may be a quoted or unquoted string. Some additional information on the subject: When it comes to strings, the named.conf parser expects some options to be quoted strings (usually file paths), some options to be unquoted strings (things like algorithm and class names), and some options to be just strings (usually names). ___ 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
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
Hi Tim, On 11-08-2021 04:19, Tim Daneliuk via bind-users wrote: On 8/10/21 7:32 PM, raf via bind-users wrote: To get the DS record information to convey to the registrar, after starting to use the default policy. look for the CDS record (the child version of the DS record) with dig: dig CDS EXAMPLE.ORG For the default policy, you'll only have to do this once (or until your server gets compromised and you start again). But until you've done this, it's not done. The trust chain has to go all the way to the root, so you need the involvement of your registrar (to get your DS published and signed). That's quite helpful, thanks, but still unclear about one thing. When I run the dig command above I do get a result back with a "COOKIE" value in the response. This value changes each time I run the dig. Is any one of these the "DS record" I want to convey to my registrar? Other than this I see nothing that resembles a relevant response AND the COOKIE field does not show up if I do the dig from outside the zone. Cookies are a different thing, unrelated to DNSSEC: https://datatracker.ietf.org/doc/html/rfc7873 ___ 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
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On Tue, Aug 10, 2021 at 09:19:33PM -0500, Tim Daneliuk via bind-users wrote: > On 8/10/21 7:32 PM, raf via bind-users wrote: > > To get the DS record information to convey to the > > registrar, after starting to use the default policy. > > look for the CDS record (the child version of the DS > > record) with dig: > > > > dig CDS EXAMPLE.ORG > > > > For the default policy, you'll only have to do this > > once (or until your server gets compromised and you > > start again). But until you've done this, it's not > > done. The trust chain has to go all the way to the > > root, so you need the involvement of your registrar > > (to get your DS published and signed). > > That's quite helpful, thanks, but still unclear about one > thing. When I run the dig command above I do get a result > back with a "COOKIE" value in the response. This value > changes each time I run the dig. Is any one of these the > "DS record" I want to convey to my registrar? > > Other than this I see nothing that resembles a relevant response AND > the COOKIE field does not show up if I do the dig from outside the zone. I don't know what the cookie is for (Sorry). And I haven't signed my zones yet (I'm waiting for debian-11 to come out in a few days), so I can't show you anything definite. But this is what I'd expect to see. I'll use the real example.org as an example, and use host, rather than dig, for compact output. They have DNSKEY and DS records (too many of both for some reason): > host -t dnskey example.org example.org has DNSKEY record 257 3 8 AwEAAayIYwp6ixWfhYM4THrWtVOVLbtJLekeXoNANfroGA/9R5ynPhmR V5MufCgluPCXs0xcWKMxunggLfQm87L/KkL+9W6Ux5aCWIAlVIbD+Vio VXuHbmaW0SUXApi1wIaq9yP9P0oVfbKSqlQLQPbvrOTGXAeR+XAARkgr PJQadTDw3zA7YugzoH/jJEmjK3AGVRUb13ZByUsf+aAnVJmAtBdl3772 mN2rLoaCCa6wyCrT0YZcHrxiMGo8J/KjU/1IidfufsOHH1iQ3CLoV0Kf hQDBb33S8TH30cu8WCPmKhJNWjbhLaTKTDV0GKl/GIYX3IKcNLY9TZjk wUnOcEc1MxE= example.org has DNSKEY record 256 3 8 AwEAAcRJYEt01+ODGJx7oc/1gW8ABY3AwY5QO+b0wp+HcZFq/OK2ZZ57 RBx/nIeP+lWnQGGgKFjeJm04OpY9DKXG2i9Wg2bBxm6lA/Wsa5/flCEK bM3RqTuNzcnxcYEBgqbdmDlgqsK066nbl54DiPEQrEW8ZtroUmuEkrQB WM4xe+Uz example.org has DNSKEY record 257 3 8 AwEAAZtWmbB2NyRD8oX7JeNUfmJB928LBER6l44TokqhZDOL2g6IyxLv 9Ku02X/C50iyUeK1r4lr9s9WdSSAH+Qi3ozeXvhZvzAcgQzNJ1jUj4TX ufXkml4QIy9kwL18N3jRizs+Sj8gz56UQwPL1J3M3rhYvSrF0a2zQYt8 Vt0+HGUNJnaJ7dTBbfALiUJc0ATuHKOU1Le+Pb0b/3Q6b4AG3ZNKciwy 8Hb9wroeAwv5//tffTgTQy4D4544HZCUkRW8b/+jNCpzdw6x7g4edA93 8y+f4YnOn+0bI5pSpB4IDG+GKgrFO2gAEdttujylxJxsm+slx0Qn8Wrv R/ZZvcYnXvs= Only the last DNSKEY above has corresponding DS records below. The 257 means it's a KSK and so it needs a corresponding DS for it to be trusted. > host -t ds example.org example.org has DS record 31589 8 2 3FDC4C11FA3AD3535EA8C1CE3EAF7BFA5CA9AE8A834D98FEE10085CF AEB625AA example.org has DS record 31589 8 1 7B8370002875DDA781390A8E586C31493847D9BC example.org has DS record 37780 8 2 D96AFA9022000D368B5F497877DF289A1E9A13A1AB1F97BC1BF4D5DE 16879134 example.org has DS record 37780 8 1 B4A5CCE8D82DC585E327E5896EAE82E0B9A76DC6 example.org has DS record 3397 8 2 ED1168604BC6A14068B9905401E62698BB3663B6EC2073EBD3599B88 2A785BF6 example.org has DS record 3397 8 1 DEE10345942C98711EB058B25A749EE342FCE1DC The last two DS records above correspond to the last DNSKEY further up. I think the other four are just old ones that haven't been deleted yet. They don't correspond to any other DNSKEY records further up. You can tell which DNSKEY that a DS corresponds to by looking at the first number in the DS record (e.g. 3397), and using dig to extract the key id from the DNSKEY record: > dig dnskey example.org +multi [...] example.org. 2552 IN DNSKEY 257 3 8 ( AwEAAZtWmbB2NyRD8oX7JeNUfmJB928LBER6l44Tokqh ZDOL2g6IyxLv9Ku02X/C50iyUeK1r4lr9s9WdSSAH+Qi 3ozeXvhZvzAcgQzNJ1jUj4TXufXkml4QIy9kwL18N3jR izs+Sj8gz56UQwPL1J3M3rhYvSrF0a2zQYt8Vt0+HGUN JnaJ7dTBbfALiUJc0ATuHKOU1Le+Pb0b/3Q6b4AG3ZNK ciwy8Hb9wroeAwv5//tffTgTQy4D4544HZCUkRW8b/+j NCpzdw6x7g4edA938y+f4YnOn+0bI5pSpB4IDG+GKgrF O2gAEdttujylxJxsm+slx0Qn8WrvR/ZZvcYnXvs= ) ; KSK; alg = RSASHA256 ; key id = 3397 [...] They don't have CDS or CDNSKEY records: > host -t cds example.org example.org has no CDS record > host -t cdnskey example.org example.org has no CDNSKEY record But they would if they were using a recent version of bind. In general, in the lead up to a key rollover, you can tell which CDS is new by the fact that it will have a new key id that you didn't see before. The CDNSKEY records should look like the DNSKEY records (and be a hypothetical signal to the parent zone that they could use the CDNSKEY to derive a DS record that they could then publish and sign at the parent zone level). Similarly, the CDS records (which are derived locally from the CDNSKEY record) should look like a new DS record (and be a hypothetical signal to the parent zone that they could publish and
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On 8/10/21 7:32 PM, raf via bind-users wrote: > To get the DS record information to convey to the > registrar, after starting to use the default policy. > look for the CDS record (the child version of the DS > record) with dig: > > dig CDS EXAMPLE.ORG > > For the default policy, you'll only have to do this > once (or until your server gets compromised and you > start again). But until you've done this, it's not > done. The trust chain has to go all the way to the > root, so you need the involvement of your registrar > (to get your DS published and signed). That's quite helpful, thanks, but still unclear about one thing. When I run the dig command above I do get a result back with a "COOKIE" value in the response. This value changes each time I run the dig. Is any one of these the "DS record" I want to convey to my registrar? Other than this I see nothing that resembles a relevant response AND the COOKIE field does not show up if I do the dig from outside the zone. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On Tue, Aug 10, 2021 at 11:24:31AM -0500, Tim Daneliuk via bind-users 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 . > > 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
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On Tue, Aug 10, 2021 at 08:51:04AM -0500, Tim Daneliuk via bind-users wrote: > On 8/10/21 7:51 AM, Matthijs Mekking wrote: > > Hi Klaus, > > > > On 10-08-2021 13:38, Klaus Darilion wrote: > >> Hi Matthijs! > >> > >>> We would like to encourage you to change your configurations to > >>> 'dnssec-policy'. See this KB article for migration help: > >>> > >>> https://kb.isc.org/docs/dnssec-key-and-signing-policy > >> > >> Some comments to this KB article and dnssec-policy: > >> > >> - The article should mention how to retrieve the DS record from > >> Bind. > > > 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.) > > TIA, I'm very new to this myself (so be warned) but that seems to be almost it. BUT: You also MUST convey the DS for the default Combined Signing Key (CSK) to your registrar. That will be a manual process that your registrar can tell you about. For some, there's a web interface. For others, it's via email. For others, you have to use their DNS servers and let them do it for you (but that's a dull option). To get the DS record information to convey to the registrar, after starting to use the default policy. look for the CDS record (the child version of the DS record) with dig: dig CDS EXAMPLE.ORG For the default policy, you'll only have to do this once (or until your server gets compromised and you start again). But until you've done this, it's not done. The trust chain has to go all the way to the root, so you need the involvement of your registrar (to get your DS published and signed). Syntax question: In https://bind9.readthedocs.io/en/latest/dnssec-guide.html the double quotes are never used in the zone stanza where the dnssec-policy is referred to. The double quotes sometimes (but not always) appear in the dnssec-policy definition stanza. Are the double quotes optional in both cases? > -- > > Tim Daneliuk tun...@tundraware.com > PGP Key: http://www.tundraware.com/PGP/ > ___ 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
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
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 . 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/ ___ 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
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On 10-08-2021 15:51, Tim Daneliuk via bind-users wrote: On 8/10/21 7:51 AM, Matthijs Mekking wrote: Hi Klaus, On 10-08-2021 13:38, Klaus Darilion wrote: Hi Matthijs! We would like to encourage you to change your configurations to 'dnssec-policy'. See this KB article for migration help: https://kb.isc.org/docs/dnssec-key-and-signing-policy Some comments to this KB article and dnssec-policy: - The article should mention how to retrieve the DS record from Bind. 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 . TIA, ___ 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
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On 8/10/21 7:51 AM, Matthijs Mekking wrote: > Hi Klaus, > > On 10-08-2021 13:38, Klaus Darilion wrote: >> Hi Matthijs! >> >>> We would like to encourage you to change your configurations to >>> 'dnssec-policy'. See this KB article for migration help: >>> >>> https://kb.isc.org/docs/dnssec-key-and-signing-policy >> >> Some comments to this KB article and dnssec-policy: >> >> - The article should mention how to retrieve the DS record from >> Bind. 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.) TIA, -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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
Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+
Hi Klaus, On 10-08-2021 13:38, Klaus Darilion wrote: Hi Matthijs! We would like to encourage you to change your configurations to 'dnssec-policy'. See this KB article for migration help: https://kb.isc.org/docs/dnssec-key-and-signing-policy Some comments to this KB article and dnssec-policy: - The article should mention how to retrieve the DS record from Bind. I am not sure what you are asking. Do you mean how to convert the DS from the DNSKEY record so you can submit it to the registrar? - How does Bind handle duplicate keyids when generating new keys? Will Bind ensure that there will not be any duplicate key ideas or will it just use the duplicate keys? In the latter case the " rndc dnssec -checkds -key 12345 ..." commands will be ambiguous. (From an user perspective duplicate keyids should be avoided) BIND will check for key id collision. When a conflict (for the same algorithm) is detected a new key will be generated. Best regards, Matthijs Thanks Klaus ___ 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
