dnssec-policy default - where/how to determine what all its settings are?
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
Re: dnssec-policy default - where/how to determine what all its settings are?
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 - -- 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: dnssec-policy default - where/how to determine what all its settings are?
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 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
MDLZ user activation
Hi Nick Tait via bind-users, A new MDLZ account has been created for you. Click the url below to activate your account and select a password! https://mdlz.freshdesk.com/register/hanfOQBn6m2H8fUkSOSI If the above URL does not work try copying and pasting it into your browser. If you continue to have problems, please feel free to contact us. Regards, MDLZ -- 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: dnssec-policy default - where/how to determine what all its settings are?
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. 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. 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. 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 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 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
Re: Problem with a certain domain
Am 2024-06-04 15:28, schrieb Greg Choules: Firstly, I doubt you actually need to kill and restart `named`. Flushing the cache would probably work, either all of it or just selected names. Secondly, take a packet capture of this happening and analyse what BIND is really doing, in Wireshark. - If it shows up that certain NS are causing the problem you can avoid them, in config. - If it's a DNSSEC issue, you can get around that on a per-domain basis, if needed. - If it turns out that qname minimization is the issue, you can play with settings for that, too. In short, there are plenty of tools in the kit bag. But understand what the problem is first and to do that, gather data (pcaps and logs) that can be used to paint a picture of what's really happening. On 04.06.24 19:17, Thomas Barth via bind-users wrote: The newsletter is only sent out once a day, so I would have to wait until tomorrow. I'll record it then. I have already experimented with tshark and recorded port 53. What I noticed as a network layman is that a certain response takes much longer on server 1 with the problems than on server 2. if the problem happens again, you can call 'rndc dumpdb' to dump named's cache and see all records your named remembers about mallorcazeitung.es and epi.es perhaps they can help to explain why named can't resolve anything. It's the message: No such name NS _domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es Here is a part of the recording of server 1 with the problem, almost a delay of 2 seconds! (tshark -w dns-mx1-l5.pcap -i eth0 -f "src port 53") [...] 6 18:35:38,719369034 216.239.32.106 213.136.83.xxx DNS 141 Standard query response 0x69ac A ns3.prensaiberica.net A 34.175.122.60 OPT 7 18:35:40,333128992 34.175.122.60 213.136.83.xxx DNS 162 Standard query response 0xf393 No such name NS _domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es 8 18:35:40,370838540 194.69.254.1 213.136.83.xxx DNS 1219 Standard query response 0xaadc DS mallorcazeitung.es NSEC3 RRSIG SOA ns1.nic.es RRSIG NSEC3 RRSIG OPT 9 18:35:40,402465454 34.175.171.102 213.136.83.xxx DNS 165 Standard query response 0x7bfa A s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es Here is the part of the recording of server 2 (tshark -w dns-mx2-l5.pcap -i eth0 -f "src port 53") 5 18:32:03,019743724 213.4.119.2 167.86.126.xxx DNS 139 Standard query response 0x36bf A ns4.prensaiberica.net A 34.175.171.102 NS ns1.epi.es NS ns2.epi.es 6 18:32:03,052680383 194.69.254.1 167.86.126.xxx DNS 1219 Standard query response 0x5643 DS mallorcazeitung.es NSEC3 RRSIG SOA ns1.nic.es RRSIG NSEC3 RRSIG OPT 7 18:32:03,087003657 34.175.122.60 167.86.126.xxx DNS 162 Standard query response 0x3d78 No such name NS _domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es 8 18:32:03,120746561 34.175.171.102 167.86.126.xxx DNS 165 Standard query response 0x3a41 A s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es I therefore suspect that the delay will be even greater tomorrow again when the newsletter arrives, so that the "communication error" will occur again. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. If Barbie is so popular, why do you have to buy her friends? -- 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: dnssec-policy default - where/how to determine what all its settings are?
Ah, thanks! Yeah, that's what I was looking to find: 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 Alas, not in the ISC distribution tarballs, and the documentation refers to doc/misc/dnssec-policy.default.conf without indicating where to find that. On Thu, Jun 6, 2024 at 8:31 AM Andrew Latham 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 > 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 - -- 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: dnssec-policy default - where/how to determine what all its settings are?
> On 7 Jun 2024, at 02:27, Al 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 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 >> 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 sou
Re: MDLZ user activation
Hi list. I received the email below, which on the face of it looks pretty bogus (especially since this supposed 'list' email is personalised with my name). But the message headers show that this email was relayed to my MX server from the same MTA that relays legitimate emails from the bind-users list: Received: from lists.isc.org (lists.isc.org [149.20.2.23]) by mx.tait.net.nz (Postfix) with ESMTPS id E42DBA08D5 for; Fri, 7 Jun 2024 04:20:02 +1200 (NZST) So either the email below is valid, but if so I have no idea what it is for (and hence haven't clicked the link), or the email below is bogus and they have exploited the list MTA to distribute spam? Can anyone shed any light on this? Happy to share all the mail headers if that helps? Thanks, Nick. On 07/06/2024 04:19, gustavojavi...@gmail.com wrote: Hi Nick Tait via bind-users, A new MDLZ account has been created for you. Click the url below to activate your account and select a password! If the above URL does not work try copying and pasting it into your browser. If you continue to have problems, please feel free to contact us. Regards, MDLZ -- 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: MDLZ user activation
Hi Nick, I did put the user who sent the message on the moderation queue. Ondřej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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
