advance features of BIND DoT and DoH
Dear Admin, Has anybody implemented advance features of BIND DoT and DoH, Kindly help me to configure DoT and DoH in DNS with BIND 9.17.16+CentOS 7.9. With Regards Divya - Original Message - From: "Ondřej Surý" To: "klaus darilion" Cc: bind-users@lists.isc.org Sent: Monday, August 9, 2021 10:48:54 PM Subject: Re: Does BIND supports ANAME RR No, and there’s no strong usercase for that. The ANAME was wrong on every level from the protocol perspective and I am glad it is gone. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 9. 8. 2021, at 17:23, Klaus Darilion via bind-users > wrote: > > Does every application that uses gethostbyname have a benefit of HTTPS/SVCB? > That is what I meant. > regards > Klaus > >> -Ursprüngliche Nachricht- >> Von: Mark Andrews >> Gesendet: Montag, 9. August 2021 15:55 >> An: Klaus Darilion >> Cc: Evan Hunt ; Gaurav Kansal ; bind- >> us...@lists.isc.org >> Betreff: Re: Does BIND supports ANAME RR >> >> Every resolver on the planet already supports HTTPS and SVCB. Every >> authoritative server on the planet already supports HTTPS and SVCB via >> unknown record format. iOS is already making HTTPS queries for every >> webpage. I believe other browsers also make HTTPS queries today. Go look >> at your DNS traffic. >> >> The MR mentioned earlier allows named and the other tools to load and >> display the records in presentation format and to do the additional section >> processing. None of that it required to be able to return these records. >> It >> just makes it easier. >> >> Just about all the other DNS vendors also have code that can read and >> display presentation format. >> >> ANAME is dead. >> -- >> Mark Andrews >> >>> On 9 Aug 2021, at 21:53, Klaus Darilion via bind-users > us...@lists.isc.org> wrote: >>> >>> -Ursprüngliche Nachricht- Von: bind-users Im Auftrag von Evan Hunt Gesendet: Samstag, 7. August 2021 20:21 An: Gaurav Kansal Cc: bind-users@lists.isc.org Betreff: Re: Does BIND supports ANAME RR >> On Sat, Aug 07, 2021 at 11:05:51PM +0530, Gaurav Kansal wrote: >> I need the help in figuring out whether BIND supports ANAME ? If yes, >> then from which version on wards ? > > No, it doesn't. The effort to standardize ANAME stalled, and I doubt > it'll be coming back. > > The new HTTPS and SVCB records look like a better approach anyway. > BIND will have support for those pretty soon. >>> >>> But honestly SVCB will not solve the ANAME problem. I will take years until >> all resolvers/client would support SVCB whereas ANAME would be >> implemented in the authoritative name server and hence would work for >> every client/resolver as client/resolver never sees the ANAME but only the >> A/ record. >>> >>> regards >>> 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 > ___ > 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 ___ 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 ___ 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
Switching key types for authorizing updates
I have a zone defined in which I permit dynamic updates. Many years ago,
I defined a key per name, and added that key into the update-policy
attribute in the zone definition.
For example:
key "foo.bar.baz.com" {
algorithm hmac-md5;
secret "12345..890";
};
zone "bar.baz.com" {
type master;
update-policy {
grant "foo.bar.baz.com" selfsub foo.bar.baz.com TXT;
};
};
The theory being, the holder of the key named "foo.bar.baz.com" is able
to manipulate TXT records in foo.bar.baz.com and all of its subdomains.
But now I'd like to move away from those old md5 keys. I would like to
find a way to define a second key which will work along side, during the
transition, the existing md5 key. When everyone is using the new key,
I'd then remove the old md5 key.
But as far as I can tell, the name of the key needs to match the
hostname in the update-policy statement. I can define a new aes-256 key,
but it can't have the name "foo.bar.baz.com" while the current md5 key
is defined. Nor can I find a way to craft an update-policy statement
line to let a new key with a different name manipulate the desired TXT
records, while letting the current key continue to work.
Is there a way to get the configuration I want? or must I make a
wholesale swap of each md5 key for something newer?
--
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
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: AW: Deprecating auto-dnssec and inline-signing in 9.18+
Klaus Darilion via bind-users wrote: > > By reading this KB I do not know how the user will be informed which DS > (or DNSKEY) must be submitted to the parent zone. I know you to convert > a DNSKEY to DS, but IMO the KB is very good but missest hat point. I would expect the zone's apex CDS and CDNSKEY records to change, but neither are mentioned in the KB article. Tony. -- f.anthony.n.finchhttps://dotat.at/ a fair voting system for all elections ___ 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: AW: Deprecating auto-dnssec and inline-signing in 9.18+
Thanks, I got some more suggestions to improve the KB article, I'll include yours to that list. On 10-08-2021 15:28, Klaus Darilion wrote: 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? Yes. By reading this KB I do not know how the user will be informed which DS (or DNSKEY) must be submitted to the parent zone. I know you to convert a DNSKEY to DS, but IMO the KB is very good but missest hat point. - 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. Thanks for the info, could be mentioned somewhere 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
AW: AW: Deprecating auto-dnssec and inline-signing in 9.18+
> 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? Yes. By reading this KB I do not know how the user will be informed which DS (or DNSKEY) must be submitted to the parent zone. I know you to convert a DNSKEY to DS, but IMO the KB is very good but missest hat point. > > - 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. Thanks for the info, could be mentioned somewhere 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
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
AW: Deprecating auto-dnssec and inline-signing in 9.18+
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. - 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) 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
Re: Deprecating auto-dnssec and inline-signing in 9.18+
Le 10/08/2021 à 12:34, Matthijs Mekking a écrit :
> Hi Emannuel,
>
> Thanks for your response.
>
> On 10-08-2021 11:28, FUSTE Emmanuel via bind-users wrote:
>> Le 10/08/2021 à 10:02, Matthijs Mekking a écrit :
>>> Hi users,
>>>
>>> We are planning to deprecate the options 'auto-dnssec' and
>>> 'inline-signing' in BIND 9.18. The reason for this is because
>>> 'dnssec-policy' is the preferred way of maintaining your DNSSEC zone.
> ...
>
>> Hello,
>>
>> As today state, it looks to me very premature.
>> inline-signing and auto-dnssec maintain are about transparent signature
>> maintenance. > dnssec-policy today is about transparent key
>> maintenance/rotation on top
>> of the engine used by "inline-signing and auto-dnssec maintain"
>> These are two distinct things for me.
>
> Could you explain what you mean with distinct? You already mention
> that it is "on top of" and to me it is exactly that: the one is the
> extension of the other: 'dnssec-policy' achieves the same things as
> 'auto-dnssec' and 'inline-signing', but is capable of more (key
> maintenance and rollover). So I don't see them as so distinct.
Yes one is built on top of the other and yes automatic key management
depend on automatic signature maintenance.
But conceptually they manage two different aspects of the DNSSEC
maintenance process, the later beeing a purely political thing (key
rotation).
>
>> Please add an example showing a dnssec-policy configuration giving the
>> same result as zone configured with inline-signing and auto-dnssec
>> maintain : auto signing without automatic key maintenance/rotation. It
>> should be another default build-in policy ("default-no-auto-rotate" or
>> something like that).
>
> dnssec-policy "no-auto-rotate" {
> keys {
> csk lifetime unlimited algorithm 13;
> };
> };
>
Ok as long as I could express what I have now, I'm fine and
dnssec-policy could be considered as a supersede of 'auto-dnssec' and
'inline-signing'.
In my case I have one active zsk (hsm), one active ksk (hsm), one
published ksk(hsm) for fast rollover (hsm) and one published but offline
key (software key).
If I could express that with dnssec-policy without enabling automatic
rotation (because of lack of full HSM support), that is perfect.
>
>> HSM support for automatic key management, pkcs11 object name mapping,
>> creation, deletion and more is completely missing from dnssec-policy.
>
> This is a good point. Key creation/deletion inside the HSM for
> dnssec-policy is on the roadmap and must be implemented.
Ok. That is my main concern.
>
>
>> There is even no LTS linux distribution with the open-sc libp11 openssl
>> engine packaged to be able to use non-deprecated (non native pkcs11)
>> HSM support.
>> For now I'm stuck with 9.11 for "on the shelf" pkcs11 support with ISC
>> bind packages.
>> With 9.16 packages I'm loosing the pkcs11 support because of lack of
>> proper version of open-sc libp11 openssl engine in most/all distribs.
>> Based on the ISC package, I should rebuild it with deprecated native
>> pkcs11 enabled or try do do a proper packaging of open-sc libp11 openssl
>> engine. One or the other is on my todo stack for ages but will become
>> more and more urgent as 9.11 is approaching definitive EOL.
>> With 9.18, I should have switched to libp11 engine and use deprecated
>> 'auto-dnssec' and 'inline-signing'.
>> As today plans, with 9.20 I should abandon HSM usage.
>
> This is planned for Q1 2024. So there is time.
Yes but time flies ;-)
Thank you
Best Regards,
Emmanuel.
___
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: Deprecating auto-dnssec and inline-signing in 9.18+
Hi Emannuel,
Thanks for your response.
On 10-08-2021 11:28, FUSTE Emmanuel via bind-users wrote:
Le 10/08/2021 à 10:02, Matthijs Mekking a écrit :
Hi users,
We are planning to deprecate the options 'auto-dnssec' and
'inline-signing' in BIND 9.18. The reason for this is because
'dnssec-policy' is the preferred way of maintaining your DNSSEC zone.
...
Hello,
As today state, it looks to me very premature.
inline-signing and auto-dnssec maintain are about transparent signature
maintenance. > dnssec-policy today is about transparent key
maintenance/rotation on top
of the engine used by "inline-signing and auto-dnssec maintain"
These are two distinct things for me.
Could you explain what you mean with distinct? You already mention that
it is "on top of" and to me it is exactly that: the one is the extension
of the other: 'dnssec-policy' achieves the same things as 'auto-dnssec'
and 'inline-signing', but is capable of more (key maintenance and
rollover). So I don't see them as so distinct.
Please add an example showing a dnssec-policy configuration giving the
same result as zone configured with inline-signing and auto-dnssec
maintain : auto signing without automatic key maintenance/rotation. It
should be another default build-in policy ("default-no-auto-rotate" or
something like that).
dnssec-policy "no-auto-rotate" {
keys {
csk lifetime unlimited algorithm 13;
};
};
HSM support for automatic key management, pkcs11 object name mapping,
creation, deletion and more is completely missing from dnssec-policy.
This is a good point. Key creation/deletion inside the HSM for
dnssec-policy is on the roadmap and must be implemented.
There is even no LTS linux distribution with the open-sc libp11 openssl
engine packaged to be able to use non-deprecated (non native pkcs11)
HSM support.
For now I'm stuck with 9.11 for "on the shelf" pkcs11 support with ISC
bind packages.
With 9.16 packages I'm loosing the pkcs11 support because of lack of
proper version of open-sc libp11 openssl engine in most/all distribs.
Based on the ISC package, I should rebuild it with deprecated native
pkcs11 enabled or try do do a proper packaging of open-sc libp11 openssl
engine. One or the other is on my todo stack for ages but will become
more and more urgent as 9.11 is approaching definitive EOL.
With 9.18, I should have switched to libp11 engine and use deprecated
'auto-dnssec' and 'inline-signing'.
As today plans, with 9.20 I should abandon HSM usage.
This is planned for Q1 2024. So there is time.
Best regards,
Matthijs
___
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: Deprecating auto-dnssec and inline-signing in 9.18+
Le 10/08/2021 à 10:02, Matthijs Mekking a écrit :
> Hi users,
>
> We are planning to deprecate the options 'auto-dnssec' and
> 'inline-signing' in BIND 9.18. The reason for this is because
> 'dnssec-policy' is the preferred way of maintaining your DNSSEC zone.
>
> Deprecating means that you can still use the options in 9.18, but a
> warning will be logged and it is very likely that the options will be
> removed in BIND 9.20.
>
> 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
>
> Do you have reasons for keeping 'inline-signing' or 'auto-dnssec'
> configurations? Is there a use case that is not (yet) covered by
> 'dnssec-policy'? Any other concerns? Please let us know.
>
> Best regards,
>
> Matthijs
>
Hello,
As today state, it looks to me very premature.
inline-signing and auto-dnssec maintain are about transparent signature
maintenance.
dnssec-policy today is about transparent key maintenance/rotation on top
of the engine used by "inline-signing and auto-dnssec maintain"
These are two distinct things for me.
Please add an example showing a dnssec-policy configuration giving the
same result as zone configured with inline-signing and auto-dnssec
maintain : auto signing without automatic key maintenance/rotation. It
should be another default build-in policy ("default-no-auto-rotate" or
something like that).
HSM support for automatic key management, pkcs11 object name mapping,
creation, deletion and more is completely missing from dnssec-policy.
There is even no LTS linux distribution with the open-sc libp11 openssl
engine packaged to be able to use non-deprecated (non native pkcs11)
HSM support.
For now I'm stuck with 9.11 for "on the shelf" pkcs11 support with ISC
bind packages.
With 9.16 packages I'm loosing the pkcs11 support because of lack of
proper version of open-sc libp11 openssl engine in most/all distribs.
Based on the ISC package, I should rebuild it with deprecated native
pkcs11 enabled or try do do a proper packaging of open-sc libp11 openssl
engine. One or the other is on my todo stack for ages but will become
more and more urgent as 9.11 is approaching definitive EOL.
With 9.18, I should have switched to libp11 engine and use deprecated
'auto-dnssec' and 'inline-signing'.
As today plans, with 9.20 I should abandon HSM usage.
Something is missing for me: in real life using HSM always rhymes with
using deprecated mechanism after Bind 9.11.
Best regards,
Emmanuel.
___
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
Deprecating auto-dnssec and inline-signing in 9.18+
Hi users, We are planning to deprecate the options 'auto-dnssec' and 'inline-signing' in BIND 9.18. The reason for this is because 'dnssec-policy' is the preferred way of maintaining your DNSSEC zone. Deprecating means that you can still use the options in 9.18, but a warning will be logged and it is very likely that the options will be removed in BIND 9.20. 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 Do you have reasons for keeping 'inline-signing' or 'auto-dnssec' configurations? Is there a use case that is not (yet) covered by 'dnssec-policy'? Any other concerns? Please let us know. Best regards, Matthijs ___ 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
