> On 7 Jun 2024, at 02:27, Al <awsisc...@sunnyside.com> wrote: > > Michael, > There are several layers to respond to your question. > (Looking at ISC source code can at times be fairly easy, but sometimes it's > challenging, if for example the author included some private new undocumented > macro system.) > > First, the official definitions are at IANA: > https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml > https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml > > Second, in working with BIND and DNSSEC over the years, it is not my > impression that BIND restricts the algorithm number in any way. > I don't think it even knows which types have sub-types, but I could be wrong > about that.
Named is aware of DNSSEC algorithms with sub types to the extent that parsing DNSKEY records check that use PRIVATEDNS(253) or PRIVATEOID(254) have well formed identifiers. Until there are actual DNSSEC algorithms implemented in BIND that use algorithms with multiple sub-types there is no need to use identification beyond the algorithm type. i.e. disabling all PRIVATEOIDs would be sufficient for validation until there are two DNSSEC algorithms using PRIVATEOID . That said part of implementing PRIVATEOID or PRIVATEDNS algorithms would require examining every place where the algorithm value is checked. Note: using PRIVATEDNS or PRIVATEOID requires IETF work for DS as the current specification does not work with them as there is no way currently specified to identify sub-types in DS records. See https://datatracker.ietf.org/doc/html/rfc4034#section-5. It would not be hard to add support by specifying a digest type which includes the sub-type identifier at the beginning of the digest field when the algorithm field is PRIVATEDNS or PRIVATEOID > > Third, the real list is whatever the TLD is taking these days. There was a > time that one TLD (IIRC .us) didn't take DNSSEC, and some orgranizations were > refusing until the DS-delete option was more widely implemented. A > complicated landscape. The easiest way I've found is to go to a large > registrar and look at the drop-down options it thinks that particular TLD > will accept. It used to be everyone was advised to move to 8/2 but now the > move is on to 13, but it's not 100% with everyone. TLD’s should have zero say about what algorithms you choose to sign with. If a registry or a registrar is restricting algorithms they don’t know what they are doing. What matters is what is supported in validators. If an algorithm is not supported in validators it’s not worth signing with it as the RRSIGs will be ignored. > A side not on a complication of choosing an algorithm. BIND s/w developers > have focused more on automatic-everything, so if you don't want to be > involved in choosing anything, BIND will take care of everything. For those > of us that want BIND to maintain re-signing RRs automatically ala version > 9.16 but don't want the expanded automatic part of redoing KSKs and ZSKs and > choosing algorithms, there is considerable opposition within ISC to adding an > option to disable the new behavior and distinguish between the two functions. > While there is a limited feature to give unlimited lifetime to a key, there > is no way to disable the relatively opaque and subject-to-change decision > process of whether the chosen keys are not appropriate in some way and should > be replaced. Trying to specify different default algorithms and control that > behavior gets difficult, especially for those of us with a large portfolio of > domains and disparate TLDs.o Different defaults has cognitive dissonance. Named will do what you tell it to do. > regards > Al > > On 6/6/2024 08:46, Andrew Latham wrote: >> Link for the Debian packaged version you mentioned is at >> https://bind9.readthedocs.io/en/v9.18.24/reference.html#namedconf-statement-dnssec-policy >> >> >> On Thu, Jun 6, 2024 at 9:31 AM Andrew Latham <lath...@gmail.com> wrote: >> I took a quick look >> >> * >> https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf >> * >> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf >> >> On Thu, Jun 6, 2024 at 8:19 AM Michael Paoli via bind-users >> <bind-users@lists.isc.org> wrote: >> dnssec-policy default - where/how to determine what all its settings are? >> Documentation >> doc/bind9-doc/arm/reference.html#dnssec-policy-default >> https://bind9.readthedocs.io/en/v9.18.27/reference.html#dnssec-policy-default >> says: >> A verbose copy of this policy may be found in the source tree, in the >> file doc/misc/dnssec-policy.default.conf >> But I'm not finding that in source nor elsewhere. >> There doesn't even seem to be an rndc command that can list >> defined dnssec-policy sets that are in place, nor that >> can list how they're configured. This information should be much more >> visible/findable, so ... where is it? I'm sure it must be present >> somewhere in the source, but haven't easily located it by searching. >> Shouldn't be necessary to run debugging to track down where this is >> and where in the source it comes from. So ... where does one find it? >> >> I've been looking at Debian BIND9 packages: >> bind9 1:9.18.24-1 >> bind9-doc 1:9.18.24-1 >> and also ISC BIND 9.18.24 source and 9.18.27 source and documentation. >> -- >> 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 >> >> >> -- >> - Andrew "lathama" Latham - >> >> >> -- >> - Andrew "lathama" Latham - >> > > -- > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- 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
