Re: [DNSSEC] testing KASP

t; or "DSState: hidden"         If not in my registar (dig ds +dnssec +multiline)             Publish on my Registar(api register)             Notify Bind(bind rndc dnssec -checkds -key published )             Notify Bind(bind rndc dnssec -checkds -key withdraw ) In my understanding, i sho

Re: [DNSSEC] testing KASP

w the old DS? Yes, the old DS should be not yet withdraw because some RRSIG could be still valid ? or can i withdraw the old DS / KSK immediatly ? In my logic : For each file en .state If is KSK with "DSState: rumoured" or "DSState: hidden" If not in my regi

Re: Make dig and nslookup DNSSEC aware?

sers@lists.isc.org > <mailto:bind-users@lists.isc.org> <mailto:bind-users@lists.isc.org>> > Subject: Re: Make dig and nslookup DNSSEC aware? > > This email originated from outside of TESLA > > Do not click links or open attachments unless you recognize the sender

Re: Make dig and nslookup DNSSEC aware?

-users@lists.isc.org Subject: Re: Make dig and nslookup DNSSEC aware? This email originated from outside of TESLA Do not click links or open attachments unless you recognize the sender and know the content is safe. > Doesn't dig already offer DoT using +tls and DoH using +https? You're right

Re: Make dig and nslookup DNSSEC aware?

> Doesn't dig already offer DoT using +tls and DoH using +https? You're right, it does. I need to sort out my $PATH... Regards, - Håvard -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support

RE: Make dig and nslookup DNSSEC aware?

Doesn't dig already offer DoT using +tls and DoH using +https ? Don Friesen -Original Message- From: bind-users On Behalf Of Ondrej Surý Sent: Wednesday, May 22, 2024 8:09 AM To: Havard Eidnes Cc: bind-users@lists.isc.org Subject: Re: Make dig and nslookup DNSSEC aware? [EXTERNAL

Re: Make dig and nslookup DNSSEC aware?

forget about nslookup. deprecated in my mind. use dig like so: for DoT: $dig @1.1.1.1 -tA +dnssec +tls www.google.com for Doh: dig @1.1.1.1 -ta +https +dnssec www.google.com Make sure you have a more recent version of dig to supports this. If you need programmatic DNSSEC access use a library

Re: Make dig and nslookup DNSSEC aware?

> On 22. 5. 2024, at 17:02, Havard Eidnes via bind-users > wrote: > > And, no, I'm not aware of any such plans to incorporate a DNSSEC > validator in any of those tools. Not sure it makes technical > sense, as it's a fairly large task. That's what a validating > recursive

Re: Make dig and nslookup DNSSEC aware?

>> Sorry if this has already been hashed through, but I cannot >> find anything in the archive. Is there any chance someone can >> make dig and nslookup DNSSEC aware and force it to use DoT or >> DoH ports - TCP 443 or 853 only? > > Not sure about that. However, the

Re: Make dig and nslookup DNSSEC aware?

> Sorry if this has already been hashed through, but I cannot > find anything in the archive. Is there any chance someone can > make dig and nslookup DNSSEC aware and force it to use DoT or > DoH ports - TCP 443 or 853 only? Not sure about that. However, the "kdig" utilit

Make dig and nslookup DNSSEC aware?

Sorry if this has already been hashed through, but I cannot find anything in the archive. Is there any chance someone can make dig and nslookup DNSSEC aware and force it to use DoT or DoH ports - TCP 443 or 853 only? RW -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe

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

[DNSSEC] testing KASP

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 ecdsa256 2048; zsk lifetime P1D

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

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

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

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

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 ;; fla

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

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

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

t. > > -- > 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 ra

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

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.verisignla

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

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

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

-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 lookup works.  Now try looking up the IPv6 address

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

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

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

dnssec-analyzer.verisignlabs.com aaaa lookup fail

dig dnssec-analyzer.verisignlabs.com gives me a SERVFAIL & this in the bind errors_log file: $ grep dnssec-analyzer.verisignlabs.com named-errors.log | tail -1 26-Apr-2024 19:28:37.600 query-errors: info: client @0x7f384488e3c0 127.0.0.1#47121 (dnssec-analyzer.verisignlabs.com): q

Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

Thanks Mark. It's right there in the log. Bob -- 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

Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

Named will tell you which DNSSEC algorithms it supports. Depending upon the OS and its configuration this may differ. DNSSEC algorithms: RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448 vs DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256

Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

Would this be true for FreeBSD as well? I also have a bind 9.18.24 instance running on freeBSD and it seems to be ok. Bob > The crypto policy stuff ultimately creates and maintains files in /etc/crypto-policy/backends, which has a list of acceptable or not-acceptable crypto settings. > Whilst

Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

From: bind-users on behalf of John Thurston Date: Thursday, 18 April 2024 at 06:39 To: "bind-users@lists.isc.org" Subject: Re: Answers for www.dnssec-failed.org with dnssec-validation auto; Arrgh. You are correct. I was so far down in the weeds, I didn't notice a rock had fallen on my h

Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

) and dnssec-failed.org is signed with RSA/SHA-1…-- 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

Re: Answers for www.dnssec-failed.org with dnssec-validation auto; (John Thurston)

My bind 9.18.24 server runs under Debian. When I query with dig it appears to take long enough to resolve that it goes to the next DNS server in the client's IP stack. The secondary server in my list is quad9. It seems to resolve correctly. If I point to the address of my Debian server, it works

Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

Let me guess - you are running on RHEL (without SHA-1 support) and dnssec-failed.org is signed with RSA/SHA-1…--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 17. 4. 2024, at 19:02, John

Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

he_dump.db";     listen-on port 1053 {     127.0.0.1/32;     };     querylog yes;     dnssec-validation auto;     empty-zones-enable no;     recursion yes; }; key "ns88-testPrimary-key" {     algorithm "hmac-sha256";     secret "

Re: Answers for www.dnssec-failed.org with dnssec-validation auto;

On 17/04/2024 11:41, John Thurston wrote: I'm seeing strange behavior with a BIND 9.18.24 resolver and dnssec-failed.org. With no dnssec-validation line (or with "dnssec-validation auto") in the .conf, querying for www.dnssec-failed.org returns SERVFAIL, as expected . . until

Answers for www.dnssec-failed.org with dnssec-validation auto;

I'm seeing strange behavior with a BIND 9.18.24 resolver and dnssec-failed.org. With no dnssec-validation line (or with "dnssec-validation auto") in the .conf, querying for www.dnssec-failed.org returns SERVFAIL, as expected . . until it doesn't. After several seconds of answering S

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

DNSSEC deployement in an isolated virtual environment

environment. I've already been able to set up my entire environment in VirtualBox for DNS (i.e. without DNSSEC). Now I need to deploy DNSSEC on my server. I've managed to generate my key pairs and sign my DNS zones. However, when I try to do a dig from my client VM, I get a SERVFAIL. I think

Re: Value of a DNSSEC validating resolver

etter and recommended, > but not always necessary. > > What is required is dnssec (security) awareness. Meaning that resolver will > fetch signatures for all queries with do=1 bit set. For example even dnsmasq > in default configuration will forward DNSSEC signatures to all DNSSEC enab

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

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

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: Value of a DNSSEC validating resolver

-- Mark Andrews > On 10 Feb 2024, at 04:18, Randy Bush wrote: > >  >> >> I admit here we most often work with internal only forwarders, which >> are not accessible from outer internet. So those won't be under attack > > i am always impressed by security optiism > > randy -- Visit

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 thi

Re: Value of a DNSSEC validating resolver

> I admit here we most often work with internal only forwarders, which > are not accessible from outer internet. So those won't be under attack i am always impressed by security optiism randy -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds

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&qu

Re: Value of a DNSSEC validating resolver

On 2/9/24 12:39, Mark Andrews wrote: Do the analysis where the resolver is under attack or the auth server with the best rtt is stale. I admit here we most often work with internal only forwarders, which are not accessible from outer internet. So those won't be under attack, at least

Re: Value of a DNSSEC validating resolver

testing validating clients. Validating resolver is *not* > necessary for validating clients to work. They are better and recommended, > but not always necessary. > > What is required is dnssec (security) awareness. Meaning that resolver will > fetch signatures for all queries wi

Re: Value of a DNSSEC validating resolver

Hello Mark, allow me here to correct your statement. We spent in Red Hat some time thinking and testing validating clients. Validating resolver is *not* necessary for validating clients to work. They are better and recommended, but not always necessary. What is required is dnssec (security

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

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 upg

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

? If 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?

ng proper setup around > DNS. I feel somewhat comfortable navigating around BIND but possibly am > getting confused around the DNSSEC portion. > This is for an internally facing DNS, not exposed to the internet. > High level setup is as follows: > We have 1 master/pr

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

Greetings! I have what is hopefully a simple question regarding proper setup around DNS. I feel somewhat comfortable navigating around BIND but possibly am getting confused around the DNSSEC portion. This is for an internally facing DNS, not exposed to the internet. High level setup

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

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

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.priv

Re: dnssec-key 'unknown algorithm RSASHA512'

tu 22.04 server on which bind 9.18.8 service is running. > I'm trying to generate dnssec-key by using the command "dnssec-keygen -a > RSASHA512 -b 2048 -n zone example.com" > > After doing this, it is generating both public key and private key. When I > generate a file

dnssec-key 'unknown algorithm RSASHA512'

Hello, I'm  using ubuntu 22.04 server on which bind 9.18.8 service is running. I'm trying to generate dnssec-key by using the command  "dnssec-keygen -a RSASHA512 -b 2048 -n zone example.com" After doing this, it is generating both public key and private key.  When I gener

AW: migration from auto-dnssec to dnssec-policy deletes keys immediately

Hi all! I also know a colleague which was hit by the same issue, causing problems to their zone. Migrating from auto-dnssec to dnssec-policy can lead to operational issues. For example that problem with different algos should be mentioned in https://kb.isc.org/docs/dnssec-key-and-signing

Re: DNSSec mess with SHA1

published standards track instruction to validators. Here's the table from it.  The following table lists the implementation recommendations for DNSKEY algorithms [DNSKEY-IANA].  +++-+---+    | Number | Mnemonics          | DNSSEC

Re: DNSSec mess with SHA1

lfgang Riedel via bind-users wrote: Hello Petr, The issue is not just BIND local, as you can see on dnsviz.net <http://dnsviz.net/>. The whole chain of trust is broken. nist.gov <https://dnsviz.net/d/nist.gov/dnssec/> dnsviz.net <https://dnsviz.net/d/nist.gov/dnssec/> &

Re: migration from auto-dnssec to dnssec-policy deletes keys immediately

On 12/28/23 12:58, Adrian Zaugg wrote: Hi Nick Not changing the key algo does help indeed when introducing dnssec-policy, see the log below. Thank you very much for pointing this out. But I do not understand why BIND deletes valid and published keys, just because there should be another algo

Re: migration from auto-dnssec to dnssec-policy deletes keys immediately

Hi Nick Not changing the key algo does help indeed when introducing dnssec-policy, see the log below. Thank you very much for pointing this out. But I do not understand why BIND deletes valid and published keys, just because there should be another algo used. Couldn't this be done in a smooth

Re: migration from auto-dnssec to dnssec-policy deletes keys immediately

/ECDSAP256SHA256/3654 > (ZSK) > 2023-12-27 23:51:24: keymgr: DNSKEY myzone.ch/ED25519/2336 (KSK) created for > policy mypolicy > 2023-12-27 23:51:24: keymgr: DNSKEY myzone.ch/ED25519/35413 (ZSK) created for > policy mypolicy Your DNSSEC policy “mypolicy” specifies a different algorit

migration from auto-dnssec to dnssec-policy deletes keys immediately

Dear List Trying to migrate a zone from auto-dnssec zone "myzone.ch" { key-directory "/var/lib/bind/keys"; auto-dnssec maintain; inline-signing yes; type master; [...] to dnssec-

Re: DNSSec mess with SHA1

packing or installation issue outside of BIND but nevertheless it’s impacting DNS resolution in a negative way. Anyway, the easy solution to get it working without creating DNSSEC exceptions lists is: update-crypto-policies --set LEGACY … but I still think the right way would be getting people

Re: DNSSec mess with SHA1

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 error or at > least report t

Re: DNSSec mess with SHA1

a runtime error or at least report that DNSSEC validation has been disabled. The description involved removing support for SHA1 entirely from the underlying system configuration. If that's the case then I don't see how DNSSEC validation can be reliably performed at all. It's not like introducing a n

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

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

Re: DNSSec mess with SHA1

Dec 2023, at 12:46, Wolfgang Riedel via bind-users wrote: Hello Petr, The issue is not just BIND local, as you can see on dnsviz.net <http://dnsviz.net/>. The whole chain of trust is broken. nist.gov <https://dnsviz.net/d/nist.gov/dnssec/> dnsviz.net <https://dnsviz.net/d/

Re: DNSSec mess with SHA1

it. The following table lists the implementation recommendations for DNSKEY algorithms [DNSKEY-IANA]. +++-+---+ | Number | Mnemonics | DNSSEC Signing | DNSSEC Validation

Re: DNSSec mess with SHA1

al, as you can see on dnsviz.net<http://dnsviz.net/>. The whole chain of trust is broken. <https://dnsviz.net/d/nist.gov/dnssec/> nist.gov<https://dnsviz.net/d/nist.gov/dnssec/> dnsviz.net<https://dnsviz.net/d/nist.gov/dnssec/> <https://dnsviz.net/d/nist.gov/dnssec/> My

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

DNSSec mess with SHA1

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 removed SHA1 from the code so if you're running BIND

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

3 10: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 t

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

on the 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

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

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

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

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 rollover and that may have caused the issue as things were

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

thsm/libsofthsm2.so >>> >>> init = 0 >>> >>> For example, dig is not working with environment variable OPENSSL_CONF: >>> >>> $ dig www.internet.nl +short >>> 04-Dec-2023 00:39:24.280 EVP_PKEY_fromdata_init failed (crypto failur

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

ailure It works if OPENSSL_CONF is undefined: $ OPENSSL_CONF= dig www.internet.nl +short proloprod.internet.nl. 62.204.66.10 Issue seems wider than only relative to dnssec-keyfromlabel. Gérard Le 03/12/2023 à 18:40, Gérard Parat via bind-users a écrit : Hi, I used this tutorial as reference to

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

: crypto failure > > It works if OPENSSL_CONF is undefined: > > $ OPENSSL_CONF= dig www.internet.nl +short > proloprod.internet.nl. > 62.204.66.10 > > Issue seems wider than only relative to dnssec-keyfromlabel. > > Gérard > > Le 03/12/2023 à 18:40, Gérard Parat via bind-

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

routines::operation not supported for this keytype:../crypto/evp/pmeth_gn.c:354: dig: dst_lib_init: crypto failure It works if OPENSSL_CONF is undefined: $ OPENSSL_CONF= dig www.internet.nl +short proloprod.internet.nl. 62.204.66.10 Issue seems wider than only relative to dnssec-keyfromlabel

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/20

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

to reply outside your normal working hours. > On 3. 12. 2023, at 18:41, Gérard Parat via bind-users > wrote: > > Hi, > > I used this tutorial as reference to setup DNSSEC with SoftHSM2: > https://kb.isc.org/docs/bind-9-pkcs11 > > I installed the Debian package

dnssec-keyfromlabel not working with Debian 12 (bookworm)

Hi, I used this tutorial as reference to setup DNSSEC with SoftHSM2: https://kb.isc.org/docs/bind-9-pkcs11 I installed the Debian package instead of building libp11: libengine-pkcs11-openssl:amd640.4.12-0.1 It works until reaching this command: $ dnssec-keyfromlabel \ -E pkcs11

Re: Value of a DNSSEC validating resolver

023, at 12:31, Crist Clark wrote: > >  > Preface: Please don’t read any judgement of DNSSEC’s value into this > question. Just looking for the opportunity to understand DNSSEC better from > some world-class experts if any care to respond. > > When a client (or any DNS-spea

Re: Value of a DNSSEC validating resolver

Preface: Please don’t read any judgement of DNSSEC’s value into this question. Just looking for the opportunity to understand DNSSEC better from some world-class experts if any care to respond. When a client (or any DNS-speaker) is doing validation, doesn’t it set CD on queries through

  1   2   3   4   5   6   7   8   9   10   >