Re: [DNSSEC] when remove KSK from file system

You can set 'purge-keys' to a value you feel comfortable with. By default it is set to 90 days, so after 90 days the key is completely hidden, it will be removed from disk. Best regards, Matthijs On 19-03-2025 09:29, adrien sipasseuth wrote: Hello, I use Bind 9.20.4, with KASP policy to set

Re: DNSSEC, OpenDNS and www.cdc.gov - DNS Compliance checker?

DNS... > > Thanks in advance for any thoughts you can provide. > > Robert Wagner > From: bind-users on behalf of Robert > Edmonds > Sent: Friday, November 1, 2024 4:16 PM > To: Robert Mankowski > Cc: bind-users@lists.isc.org > Subject: Re: DNSSEC, OpenDNS and w

Re: DNSSEC, OpenDNS and www.cdc.gov - DNS Compliance checker?

for proper configuration. Kind of a SSL checker for DNS... Thanks in advance for any thoughts you can provide. Robert Wagner From: bind-users on behalf of Robert Edmonds Sent: Friday, November 1, 2024 4:16 PM To: Robert Mankowski Cc: bind-users@lists.isc.org Subject: Re: DNSSEC, OpenDNS and

Re: DNSSEC, OpenDNS and www.cdc.gov - DNS Compliance checker?

From: bind-users on behalf of Robert Edmonds Sent: Friday, November 1, 2024 4:16 PM To: Robert Mankowski Cc: bind-users@lists.isc.org Subject: Re: DNSSEC, OpenDNS and www.cdc.gov This email originated from outside of TESLA Do not click links or open attachments unless you recognize

Re: DNSSEC, OpenDNS and www.cdc.gov

This is a problem with the operational configuration of the cdc.gov nameservers. The gov nameservers publish the following NS records for cdc.gov: cdc.gov.10800 IN NS auth00.ns.uu.net. cdc.gov.10800 IN NS auth100.ns.uu.net. cdc.gov.

Re: DNSSEC with views and shared zone files

On 10/21/2024 9:35 AM, Bowie Bailey via bind-users wrote: On 10/18/2024 6:19 PM, Nick Tait via bind-users wrote: On 19/10/2024 05:50, Bowie Bailey via bind-users wrote: On 10/18/2024 12:07 PM, Bob Harold wrote: On Fri, Oct 18, 2024 at 11:33 AM Bowie Bailey via bind-users wrote: The seco

Re: DNSSEC with views and shared zone files

On 10/18/2024 6:19 PM, Nick Tait via bind-users wrote: On 19/10/2024 05:50, Bowie Bailey via bind-users wrote: On 10/18/2024 12:07 PM, Bob Harold wrote: On Fri, Oct 18, 2024 at 11:33 AM Bowie Bailey via bind-users wrote: The first issue is that my server uses a few views to give dif

Re: DNSSEC with views and shared zone files

Bowie Bailey via bind-users wrote: > The first issue is that my server uses a few views to give different IPs > based on which network the request comes from.  I found that if I point the > zones in the different views to the same key directory, there are no errors > and all vie

Re: DNSSEC with views and shared zone files

You can’t do this. The signatures are unique per zone and thus the files need to be unique as well. Just write a small provisioning on your side that duplicates the files. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligate

Re: DNSSEC with views and shared zone files

On 19/10/2024 05:50, Bowie Bailey via bind-users wrote: On 10/18/2024 12:07 PM, Bob Harold wrote: On Fri, Oct 18, 2024 at 11:33 AM Bowie Bailey via bind-users wrote: I am finally getting around to setting up DNSSEC on my server (Bind 9.16).  I found some instructions online and was ab

Re: DNSSEC with views and shared zone files

I am running this setup, it works. My 2 zones are internal and external, so testing from outside can only show one side. Thanks Sten > On 18 Oct 2024, at 18.07, Bob Harold wrote: > > > On Fri, Oct 18, 2024 at 11:33 AM Bowie Bailey via bind-users > mailto:bind-users@lists.isc.org>> wrote: >

Re: DNSSEC with views and shared zone files

-- Best regards Sten Carlsen A pessimist is a person that can find a problem for every solution. > On 18 Oct 2024, at 18.50, Bowie Bailey via bind-users > wrote: > > On 10/18/2024 12:07 PM, Bob Harold wrote: >> >> On Fri, Oct 18, 2024 at 11:33 AM Bowie Bailey via bind-users >> mailto:bi

Re: DNSSEC with views and shared zone files

On 10/18/2024 12:07 PM, Bob Harold wrote: On Fri, Oct 18, 2024 at 11:33 AM Bowie Bailey via bind-users wrote: I am finally getting around to setting up DNSSEC on my server (Bind 9.16).  I found some instructions online and was able to set up one of my zones and confirm that t

Re: DNSSEC with views and shared zone files

On Fri, Oct 18, 2024 at 11:33 AM Bowie Bailey via bind-users < bind-users@lists.isc.org> wrote: > I am finally getting around to setting up DNSSEC on my server (Bind > 9.16). I found some instructions online and was able to set up one of > my zones and confirm that the keys are being returned. H

RE: DNSSEC, OpenDNS and www.cdc.gov

Thanks Greg. That is very helpful. Sorry I didn't find that article on my own. Bob From: Greg Choules Sent: Wednesday, October 16, 2024 10:10 AM To: Robert Mankowski Cc: bind-users@lists.isc.org Subject: Re: DNSSEC, OpenDNS and www.cdc.gov Hi Bob. See if this article helps any first, b

Re: DNSSEC, OpenDNS and www.cdc.gov

Hi Bob. See if this article helps any first, before we get into configs: https://kb.isc.org/docs/the-umbrella-feature-in-detail Cheers, Greg > On 16 Oct 2024, at 14:55, Robert Mankowski > wrote: > > I recently implemented a forward only BIND server for home. I was forwarding > to OpenDNS Fam

Re: DNSSEC algo rollover fails to delete old keys

dy yet, then please keep these standards in mind for future direction when available. RW From: bind-users on behalf of Matthijs Mekking Sent: Wednesday, October 16, 2024 4:03 AM To: bind-users@lists.isc.org Subject: Re: DNSSEC algo rollover fails to delete ol

Re: DNSSEC algo rollover fails to delete old keys

If you provide the output of `rndc dnssec -status` it might give a hint why the keys are still published. I suspect that BIND needs to be told that the DS has been withdrawn for the parent zone (assuming you don't have parental-agents set up). For future algorithm rollovers: You can just chan

Re: DNSSEC algo rollover fails to delete old keys

Restore the keys from backups and let named MANAGE the removal of the old keys. People really need to stop being impatient with DNSSEC key management. It is a SLOW process as there are interactions with the parent zone that need to be co-ordinated and WAIT TIMES that need to be observed. Named h

named -C, ...: Re: dnssec-policy default - where/how to determine what all its settings are?

Excellent, thanks, looks like that very well covers it (and also the "insecure" policy too). And https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/9092/diffs looks good ... including Suzanne Goldlust's additional suggestions too. Thanks! On Fri, Jun 7, 2024 at 1:08 AM Petr Špaček wrote:

Re: dnssec-policy default - where/how to determine what all its settings are?

Hello, and thank you for reaching out. I agree this was poorly documented. In recent versions you can use command `named -C` which prints out default configuration, including the default DNSSEC policy. I'm going to update documentation to reflect that: https://gitlab.isc.org/isc-projects/bind

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,

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 refer

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.

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-po

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: > d

Re: [DNSSEC] testing KASP

On 29. 05. 24 11:31, adrien sipasseuth wrote: Only if KSK has DSState: rumoured. If the DSState is hidden it means that it is not expected to be in the parent (for example because the DNSKEY has not yet been fully propagated). > Do you need to withdraw the old key too immediatly ? anything els

Re: [DNSSEC] testing KASP

Only if KSK has DSState: rumoured. If the DSState is hidden it means that it is not expected to be in the parent (for example because the DNSKEY has not yet been fully propagated). > Do you need to withdraw the old key too immediatly ? anything else to do ? >>> Do you mean withdraw the old DS?

Re: [DNSSEC] testing KASP

Hi, On 5/16/24 14:02, adrien sipasseuth wrote: Hello, I try to set up a testing environment in order to create some scripts for automated the roll over KSK. # question 1 # this is my policy : dnssec-policy "test" {     keys {     ksk lifetime P3D algorithm ecds

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

> On 1 May 2024, at 22:25, Walter H. via bind-users > wrote: > > On 01.05.2024 01:33, Mark Andrews wrote: >> >>> On 1 May 2024, at 03:32, Lee wrote: >>> >>> On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: On 29.04.2024 22:19, Lee wrote: > On Sun, Apr 28, 2024 at 2:18 AM Walter H.

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On 01.05.2024 01:33, Mark Andrews wrote: On 1 May 2024, at 03:32, Lee wrote: On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: On 29.04.2024 22:19, Lee wrote: On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users wrote: something that I replied to and got this in response: Error Icon

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

> On 1 May 2024, at 03:32, Lee wrote: > > On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: >> >> On 29.04.2024 22:19, Lee wrote: >>> On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users >>> wrote: >>> >>> something that I replied to and got this in response: >>> >>> Error Icon >>> Mes

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Tue, Apr 30, 2024 at 2:40 AM Mark Andrews wrote: > > And it has been fixed. Yay! No more error messages in the log because of them :-) Thanks for your help Lee -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this softwar

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: > > On 29.04.2024 22:19, Lee wrote: > > On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users > > wrote: > > > > something that I replied to and got this in response: > > > > Error Icon > > Message blocked > > Your message to Walter.H@[..snip.

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

And it has been fixed. % dig dnssec-analyzer.verisignlabs.com ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.24-dev <<>> dnssec-analyzer.verisignlabs.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9048 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1,

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

> On 30 Apr 2024, at 13:39, Walter H. via bind-users > wrote: > > On 29.04.2024 22:19, Lee wrote: >> On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users >> wrote: >> >> something that I replied to and got this in response: >> >> Error Icon >> Message blocked >> Your message to Walter.

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On 29.04.2024 22:19, Lee wrote: On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users wrote: something that I replied to and got this in response: Error Icon Message blocked Your message to Walter.H@[..snip..] has been blocked. See technical details below for more information. The respon

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Mon, Apr 29, 2024 at 5:13 PM Mark Andrews wrote: > > I prefer to only name and shame when I’m 100% sure of the target. I was only trying to understand why I was getting a SERVFAIL, there was no intention to name & shame. Regards, Lee "name & shame" was not my intent. > > -- > Mark Andrews > >

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

I prefer to only name and shame when I’m 100% sure of the target. -- Mark Andrews > On 30 Apr 2024, at 06:56, Lee wrote: > > On Sun, Apr 28, 2024 at 7:56 PM Mark Andrews wrote: >> >> It isn’t DNSSEC. It’s a badly configured DNS server that is claiming that it >> serves .com rather than dns

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Sun, Apr 28, 2024 at 7:56 PM Mark Andrews wrote: > > It isn’t DNSSEC. It’s a badly configured DNS server that is claiming that it > serves .com rather than dnssec-analyzer-gslb.verisignlabs.com which is > actually delegated to it. > > % dig dnssec-analyzer-gslb.verisignlabs.com +trace +al

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

And the SMTP server doesn’t need to listen on IPv6 if it isn’t going to accept messages over that transport. Talk about a way to DoS yourself. -- Mark Andrews > On 30 Apr 2024, at 06:19, Lee wrote: > > On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users > wrote: > > something that I

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users wrote: something that I replied to and got this in response: Error Icon Message blocked Your message to Walter.H@[..snip..] has been blocked. See technical details below for more information. The response from the remote server was: 554

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Sun, Apr 28, 2024 at 2:18 AM Walter H. wrote: > > On 27.04.2024 16:54, Lee wrote: > > On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-users > > wrote: > >> # host dnssec-analyzer.verisignlabs.com > >> dnssec-analyzer.verisignlabs.com is an alias for > >> dnssec-analyzer-gslb.verisignlabs.com

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

It isn’t DNSSEC. It’s a badly configured DNS server that is claiming that it serves .com rather than dnssec-analyzer-gslb.verisignlabs.com which is actually delegated to it. % dig dnssec-analyzer-gslb.verisignlabs.com +trace +all ;; BADCOOKIE, retrying. ; <<>> DiG 9.19.24-dev <<>> dnssec-a

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

|Try these four | | | |fail01.dnssec.works| |fail02.dnssec.works| |fail03.dnssec.works| |fail04.dnssec.works| and then with   +cd and note the difference; On 28.04.2024 08:17, Walter H. via bind-users wrote: On 27.04.2024 16:54, Lee wrote: On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-use

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On 27.04.2024 16:54, Lee wrote: On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-users wrote: # host dnssec-analyzer.verisignlabs.com dnssec-analyzer.verisignlabs.com is an alias for dnssec-analyzer-gslb.verisignlabs.com. dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42 Righ

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-users wrote: > > # host dnssec-analyzer.verisignlabs.com > dnssec-analyzer.verisignlabs.com is an alias for > dnssec-analyzer-gslb.verisignlabs.com. > dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42 > Right, the IPv4 address look

Re: dnssec-analyzer.verisignlabs.com aaaa lookup fail

# host dnssec-analyzer.verisignlabs.com dnssec-analyzer.verisignlabs.com is an alias for dnssec-analyzer-gslb.verisignlabs.com. dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42 On 27.04.2024 01:35, Lee wrote: dig dnssec-analyzer.verisignlabs.com gives me a SERVFAIL & thi

Re: DNSSEC deployement in an isolated virtual environment

Hi Amaury. You should be able to do this by defining your own trust anchors. This should explain what you need: https://bind9.readthedocs.io/en/latest/dnssec-guide.html#trusted-keys-and-managed-keys Have fun. Greg On Sat, 16 Mar 2024 at 13:38, Amaury Van Pevenaeyge < avanpevenae...@outlook.fr> wr

Re: I am provoked by ISC for the 10 years statement that ISC refuse to fulfill (Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?)

It's hilarious. Who says python3 is going to be a thing in 10y ... or 20 🤣 On February 11, 2024 5:41:34 PM GMT+01:00, Tim Daneliuk via bind-users wrote: >On 2/11/24 02:07, Ole Aamot wrote: >> "This whole “we support everything for 10 years” is just a sales pitch, not >> a something that can be

Re: I am provoked by ISC for the 10 years statement that ISC refuse to fulfill (Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?)

On 2/11/24 02:07, Ole Aamot wrote: "This whole “we support everything for 10 years” is just a sales pitch, not a something that can be fulfilled." – Ondřej Surý — ISC I realize that there was a whole kerfuffle here that I mercifully missed and have absolutely no interest in. But it did "pro

I am provoked by ISC for the 10 years statement that ISC refuse to fulfill (Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?)

"This whole “we support everything for 10 years” is just a sales pitch, not a something that can be fulfilled." – Ondřej Surý — ISC 10+ year support is effectively done by domainameshop.com and is not just a sales pitch. I worked with Ståle Schumacher's company between 2003-2015 who celebrated

Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?

Jordan Larson via bind-users wrote: > All the dnssec configuration(s) only need to reside on the master then, > correct? Correct. Björn Persson pgpkzz0Ht2jQu.pgp Description: OpenPGP digital signatur -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list IS

Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?

Thank you for the detailed explanation! This is what I was wondering. All the dnssec configuration(s) only need to reside on the master then, correct? Looks like it a got a little clean-up to do. Appreciate everyones insight with this! ~Jordan On 2/9/24, 8:44 AM, "Björn Persson" wrote: Jord

Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?

Couple of things... Use the words Primary and Secondary... don't use Master and Slave - as it upsets many people. (I teach DNS/DNSSEC and still say dumb things at times, and I live in South Africa) The Secondary Nameservers should not have any additional DNSSEC configurations if the Primary

Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?

Jordan Larson via bind-users wrote: > Was I wrong to enable “inline-signing yes” for my slave zones? I would assume > each slave would need its own DS key? Can I do that? That sounds very wrong. Your zone shall have one DNSsec key, or set of keys, that is the same on all slave servers. A client s

Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?

Subject: Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys? 9.16.1 has bugs that have been fixed in more recent releases. There’s no point in trying to even start thinking what could be wrong in something old as this. It would be just a waste of time on both sides

Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?

Jordan > > > From: Ondřej Surý > Date: Thursday, February 8, 2024 at 2:03 PM > To: Jordan Larson > Cc: bind-users@lists.isc.org > Subject: Re: DNSSEC setup for stealth master and multi slave/recursive - > Multiple DS keys? > > I would recommend to start with upgradi

Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?

so I can do that but I was attempting to sort my issues before I attempt an upgrade. Thanks! Jordan From: Ondřej Surý Date: Thursday, February 8, 2024 at 2:03 PM To: Jordan Larson Cc: bind-users@lists.isc.org Subject: Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple

Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?

I would recommend to start with upgrading BIND (9.16.1) to a version: - that's not 4 years old - that's not going to be EOL in just couple of weeks e.g. latest 9.18.x version. ISC provides PPA for BIND 9.18 here: https://launchpad.net/~isc/+archive/ubuntu/bind Ondřej. -- Ondřej Surý (He/Him) on

Re: dnssec-key 'unknown algorithm RSASHA512'

Oh, please do not forget to generate new my-tsig after sharing your current with all of us. Next time please use named-checkconf -px named.conf.tsigkeys to filter out secrets. As Anand already wrote, shared keys are not asymmetric keys generated by dnssec-keygen. That have been split since 9

Re: dnssec-key 'unknown algorithm RSASHA512'

On 11/01/2024 12:58, trgapp16 via bind-users wrote: Hi Mounika, [snip] -->With help of the private key i generated one file with name "named.conf.tsigkeys" at /etc/bind - root@dhcpt:/etc/bind# cat named.conf.tsigkeys key "my-tsig" { algorithm "ECDSAP256SHA256"; secret "ESkrVALONh

Re: dnssec-key 'unknown algorithm RSASHA512'

Hello, Bind version - 9.18.12 -->This is the command I used for generating dnssec-keygen keys - root@dhcpt: /etc/bind# dnssec-keygen -a ECDSAP256SHA256 -n ZONE example.com Kexample.com.+013+43215.key Kexample.com.+013+43215.private root@dhcpt:/etc/bind# cat Kexample.com.+013+43215.private Privat

Re: dnssec-key 'unknown algorithm RSASHA512'

Firstly show what you are actually doing. It it too much for you to actually cut-and-paste what you are doing? Secondly BIND 9.18 is at 9.18.22. Version 9.18.8 is seriously out of date. > On 11 Jan 2024, at 15:21, pvs via bind-users wrote: > > Hello, > > I'm using ubuntu 22.04 server on

Re: DNSSec mess with SHA1

I would like to add decision to not allow SHA1 signatures verification were done on openssl component in RHEL9. It was not proposed by bind maintainer and because the crypto library prevents that operation, there is a little bind package made by any vendor can do. Unless they want to support th

Re: DNSSec mess with SHA1

Hello Wolfgang, I would suggest using policy DEFAULT:SHA1 instead. It does not enable all outdated algorithms, but enables only SHA1 in addition. Good choice for dedicated DNS servers. $ update-crypto-policies --set DEFAULT:SHA1 With my bind maintainer hat on, I need to clarify that it was e

Re: DNSSec mess with SHA1

Hi Folks, Many thanks for you feedback and insights. I didn’t wanted to say that this is an ISC issue or something I expected someone to fix. I just wanted to get your opinions and maybe provide a solution as I am not the only one facing that challenge ;-) Yes, it may be a distribution packing

Re: DNSSec mess with SHA1

They haven’t removed sha1 they have removed certain uses of sha1. If they ever remove sha1 we will just add an implementation for sha1. -- Mark Andrews > On 16 Dec 2023, at 01:09, Scott Morizot wrote: > >  >> On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček wrote: >> We do runtime detection at

Re: DNSSec mess with SHA1

On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček wrote: > We do runtime detection at startup because it's configurable, build time > would not work properly. > Okay, that makes sense. However, if I understood the scenario correctly, it seems like that configuration should then generate a runtime erro

Re: DNSSec mess with SHA1

On 15. 12. 23 14:28, Scott Morizot wrote: On Fri, Dec 15, 2023 at 6:58 AM Petr Špaček > wrote: Hello. It smells like a packaging issue to me. Stock BIND (not an obsolete Red Hat-Frankenstein version) should detect this condition and threat domains as inse

Re: DNSSec mess with SHA1

On Fri, Dec 15, 2023 at 6:58 AM Petr Špaček wrote: > Hello. > > It smells like a packaging issue to me. Stock BIND (not an obsolete Red > Hat-Frankenstein version) should detect this condition and threat > domains as insecure. > And I think that answers the one question I had. I was curious what

Re: DNSSec mess with SHA1

Hello. It smells like a packaging issue to me. Stock BIND (not an obsolete Red Hat-Frankenstein version) should detect this condition and threat domains as insecure. If it does not work with stock BIND please report it to us. If it does not work in Red Hat's packages only, well, report it to

Re: DNSSec mess with SHA1

The question I have is why you're posting the issue to this list and what you expect the ISC to do? It could be submitted as a bug to the distribution you're using. Or if you want to change the way algorithms are treated, the dnsops list at the IETF would be an appropriate place to start. (There ha

Re: DNSSec mess with SHA1

Hello, To answer my own question, the following will work: [shadowman-200.png] Chapter 4. Using system-wide cryptographic policies Red

Re: DNSSec mess with SHA1

On 14. 12. 23 8:58, Wolfgang Riedel via bind-users wrote: Hi Folks, I just wonder what's your take is on the current DNSSec mess with SHA1? There are still a lot of top level domains being signed with SHA1 and look like nobody really cares? Current OS releases like RHEL9 and others simply remo

RE: dnssec-delegation seems to be broken from .gov to bls.gov

0:19 PM To: Bhangui, Sandeep - BLS CTR Cc: Nick Tait ; bind-users@lists.isc.org Subject: Re: dnssec-delegation seems to be broken from .gov to bls.gov CAUTION: This email originated from outside of BLS. DO NOT click (select) links or open attachments unless you recognize the sender and know the

Re: dnssec-delegation seems to be broken from .gov to bls.gov

sers > Sent: Wednesday, December 6, 2023 3:23 PM > To: bind-users@lists.isc.org > Subject: Re: dnssec-delegation seems to be broken from .gov to bls.gov > CAUTION: This email originated from outside of BLS. DO NOT click (select) > links or open attachments unless you recognize

RE: dnssec-delegation seems to be broken from .gov to bls.gov

dotgov.gov did not happen correctly. Thanks Sandeep From: bind-users On Behalf Of Nick Tait via bind-users Sent: Wednesday, December 6, 2023 3:23 PM To: bind-users@lists.isc.org Subject: Re: dnssec-delegation seems to be broken from .gov to bls.gov CAUTION: This email originated from outside of

Re: dnssec-delegation seems to be broken from .gov to bls.gov

On 7/12/2023 9:05 am, Nick Tait via bind-users wrote: I could be wrong, but based on the output above it looks like the current TTL is 0, which means that doing this should provide immediate relief. Sorry it looks like the DNS server on the Wi-Fi network I'm connected to has done something we

Re: dnssec-delegation seems to be broken from .gov to bls.gov

On 7/12/2023 1:53 am, Bhangui, Sandeep - BLS CTR via bind-users wrote: Hi It seems the DNSSEC delegation is broken from “.gov” to bls.gov domain and due to which the records for bls.gov are considered as bogus and we are having issues at our site. It looks like we were in the process of KSK

Re: dnssec-keyfromlabel not working with Debian 12 (bookworm)

I've added a warning to the KB article now. Thanks for reporting this. -- 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. > On 4. 12. 2023, at 14:45, Gérard Parat via bind-user

Re: dnssec-keyfromlabel not working with Debian 12 (bookworm)

Hi, I'll follow your advice ans postpone the use of SoftHSM2 for the time being. Anyway, thanks for your help! Gérard Le 04/12/2023 à 14:31, Ondřej Surý a écrit : Hi, the guide was written for OpenSSL 1.1.x and tested with that version and the engines support in OpenSSL 3.x is deprecated, so

Re: dnssec-keyfromlabel not working with Debian 12 (bookworm)

Hi, the guide was written for OpenSSL 1.1.x and tested with that version and the engines support in OpenSSL 3.x is deprecated, so most probably something got broken along the way. Everything works properly with OpenSSL 1.1.x (for example on Ubuntu focal). There's a new provider for OpenSSL 3.x h

Re: dnssec-keyfromlabel not working with Debian 12 (bookworm)

Hi, Weird behavior with /opt/bind9/etc/openssl.cnf. The only difference with /etc/ssl/openssl.cnf is the pkcs11 engine: [openssl_init] engines=engine_section [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /usr/lib/x86_64-linux-gnu/engines-3/pkc

Re: dnssec-keyfromlabel not working with Debian 12 (bookworm)

Hi, Sorry for the typo (command is correct in strace file), here is the unedited log: $ dnssec-keyfromlabel -E pkcs11 -a RSASHA256 -l "token=bind9;object=example.net-ksk" -f KSK example.net dnssec-keyfromlabel: fatal: could not initialize dst: crypto failure Gérard Le 03/12/2023 à 19:06, O

Re: dnssec-keyfromlabel not working with Debian 12 (bookworm)

Hi, I directly see missing semicolon in the failed command. Please provide full unedited log, so we can be sure that the error was not made when redacting the output. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to

Re: dnssec-policy syntax error in options but not in view

What Mark said. So that would become: dnssec-policy "mydefault" { keys { csk key-directory lifetime unlimited algorithm ecdsa256; }; }; options { dnssec-policy "mydefault"; }; On 8/4/23 01:32, Mark Andrews wrote: You can’t define a policy there. You can tell named to use t

Re: dnssec-policy syntax error in options but not in view

You can’t define a policy there. You can tell named to use the policy. Move the definition outside of options. -- Mark Andrews > On 4 Aug 2023, at 08:26, E R wrote: > >  > My understanding from the ARM is that the dnssec-policy can be in the > "options", "view" or "zone". I have mine in "

Re: DNSSec Setup ARM Manual vs KB article on adding inline-signing for non-dynamic zones

On 7/24/23 20:14, E R wrote: As if DNSSec is not confusing enough...It seems the ARM manual that matches my release is out of step with the web site.  I followed the "Easy-Start Guide for Signing Authoritative Zones" in the ARM manual after manually signing my test zone for my starting point.

Re: DNSSec Setup ARM Manual vs KB article on adding inline-signing for non-dynamic zones

Well, you didn’t say which version of ARM did you follow. Your ARM needs to match the BIND 9 version - you need to ask RH for the matching ARM. And of course, if you find discrepancies between the BIND 9 version as provided by ISC and matching ARM as provided by ISC, we would be happy to fix it.

Re: DNSSEC doubt

Perhaps this article is a better read for you: https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy Best regards, Matthijs On 6/22/23 22:03, Daniel A. Rodriguez via bind-users wrote: Thanks, I was reading but wasn't able to decode that. Best regards El 22 de junio de 2023 4:27:21

Re: DNSSEC doubt

Thanks, I was reading but wasn't able to decode that. Best regards El 22 de junio de 2023 4:27:21 p. m. GMT-03:00, "Ondřej Surý" escribió: >It’s not. TL;DR use dnssec-policy. > >The more elaborate version of the TL;DR can be found in the DNSSEC Guide here: >https://bind9.readthedocs.io/en/v9

Re: DNSSEC doubt

It’s not. TL;DR use dnssec-policy. The more elaborate version of the TL;DR can be found in the DNSSEC Guide here: https://bind9.readthedocs.io/en/v9.18.16/dnssec-guide.html -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to r

Re: DNSSEC doubt

Hi Daniel, As far as from my experience, you’ll need to create a KSK and a ZSK first. But you can also use script to generate these key pairs. However, it is (at least with the few registrars I have experience) mandatory to enter your first DS record manually, and then you could use CDS (if the

Re: dnssec not automatically updating on 1 server

First of all, I don't recommend copying the configuration and having two primaries signing the same zone. It would at least need some key management synchronizing the signing keys. I see that the DNSKEY set from ns1 differs from ns2 (there are two more keys there, where do they come from?) P

Re: dnssec not automatically updating on 1 server

What does the logs say? Have you checked them? Ondrej -- 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. > On 15. 6. 2023, at 15:54, Michael Martinell via bind-users > wrote:

Re: dnssec-policy change from ZSK/KSK to CSK failed (bogus DNSSEC for zone)

* Matthijs Mekking [2023-06-02 14:10]: > Did you wait until the migration was complete? Everything needs to be > omnipresent after the migration before you can making DNSSEC policy changes > safely. Well there was no easy way to tell if migration was complete, there were no indications if the DS

Re: dnssec-policy change from ZSK/KSK to CSK failed (bogus DNSSEC for zone)

Hi, On 6/2/23 13:53, Sebastian Wiesinger wrote: Hi, I recently moved from auto-dnssec to dnssec-policy and after the switch I tried to change a zone from an RSA ZSK/KSK to an ECDSA CSK. When I changed the dnssec-policy from rsa to ecdsa-csk the old keys immediately got removed which lead to a

RE: DNSSEC and forward zone

that much about the parent setup. Anyway, thanks and regards! David From: bind-users On Behalf Of Petr Menšík Sent: 21 April 2023 10:59 To: bind-users@lists.isc.org Subject: Re: DNSSEC and forward zone Would it make sense to create a subdomain for internal use, but have the main zone

Re: DNSSEC and forward zone

*Sent:* 19 April 2023 10:27 *To:* David Carvalho *Cc:* Bind Users Mailing List *Subject:* Re: DNSSEC and forward zone Hi David, You can disable validation on one or more domains using "validate-except" - https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statemen

  1   2   3   4   5   6   7   8   9   10   >