On Tue, Aug 10, 2021 at 09:19:33PM -0500, Tim Daneliuk via bind-users <bind-users@lists.isc.org> 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 sign the CDS record data as a DS record, if the CDS record is validly signed). At least, that's my understanding based on reading the DNSSEC Guide and asking on this mailing list. I'll probably have a better idea in a few weeks when I can see for myself what it looks like. I don't know if there's any time delay between DNSKEY creation and CDS/CDNSKEY creation. Maybe there is. Does that help at all? 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