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

r Špaček wrote: > > 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 document

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

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

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

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 document

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

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 w

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

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>

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

Re: [DNSSEC] testing KASP

SState: 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: 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 sub

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? [EXT

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

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

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

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. if there was

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 mail

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 a

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

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

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

ithout SHA-1 support) 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 infor

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 bu

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;

dump-file "cache_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";  

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

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 a

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

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

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

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 the

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 directed

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 Pr

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

on 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 is as follows: > We have 1 master/pri

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

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

Re: dnssec-key 'unknown algorithm RSASHA512'

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

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

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

emains the last 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 | Mnemoni

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 s

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

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

rate 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

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

15. 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.n

Re: DNSSec mess with SHA1

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

Re: DNSSec mess with SHA1

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 s

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

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

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)

ODULE_PATH = /usr/lib/softhsm/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 f

  1   2   3   4   5   6   7   8   9   10   >