Bash automation for dynamic, active/active Bind DNS server

2025-04-08 Thread Travis Bean 
Hello,


I developed a Bash script to automate the installation and configuration of
open-source software (i.e., launchpad.net/linuxha). I want to make sure the
syntax of this script is perfect so I can use it as a teaching tool to
educate people about Linux.


I need to know if there is anything misconfigured with my dynamic,
active/active Bind DNS server syntax.


If you find a bug in LinuxHA, please submit a bug report to
bugs.launchpad.net/linuxha/+filebug.


Kind regards,


Travis Bean
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Cannot import keys into dnssec-policy

2025-04-08 Thread Bagas Sanjaya 
On Mon, Apr 07, 2025 at 09:28:07AM -0500, Matthijs Mekking wrote:
> Hi,
> 
> I have tried to reproduce but when I am issuing a rollover it selects the
> key I generate previously, as expected.
> 
> If you believe this is a genuine bug, please support a bug report:
> 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/new?issuable_template=Default
> 
> and fill in the steps how to reproduce the issue.
> 
> Any logs (preferably debug level 3) would then also be greatly appreciated.
> 
> Thanks, best regards,
> 
> Matthijs
> 
> 
> 
> On 3/26/25 14:51, Nguyen Thi Minh Tam via bind-users wrote:
> > "Hi, I'm trying version 9.18.31.
> > 
> > According to the post on
> > https://kb.isc.org/docs/dnssec-key-and-signing-policy
> > , the policy
> > normally generates keys when they are needed. However, we can generate
> > the DNSSEC keys ourselves first, and when the policy requires a new key,
> > it will select the one we created.
> > 
> > There is even an example in that post.
> > 
> > So, I followed that approach. I generated a new key that matches the
> > policy and placed it in the key directory. However, when it was time to
> > roll the key, my key was retired, and the policy generated a new one
> > instead.
> > 
> > Here is my policy:"
> > 
> > 
> > dnssec-policy "hosting key" {
> >          dnskey-ttl PT1M;
> >          keys{
> >                  ksk key-directory lifetime P1Y algorithm RSASHA256 2048;
> >                  zsk key-directory lifetime P30D algorithm RSASHA256 2048;
> >          };
> > 
> > And i run this command to generate the next key:
> > 
> > dnssec-keygen -a 8 -b 2048 -n ZONE -K /data/keys/policy.com/ policy.com
> > i even tried
> > dnssec-keygen -k "hosting key" -l /etc/named.conf -K
> > /data/keys/policy.com/ policy.com

Hi Matthijs, Hi Nguyen,

I can reproduce the bug, using Nguyen's dnssec-policy.

Before the rollover, I pregenerate the explicit successor ZSK by:

```
$ cd /var/named
# dnssec-keygen -a rsasha256 -b 2048 -f zsk test.net
# chown named:named Ktest.net.+008+07213*
```

``rndc dnssec -status test.net`` shows that the successor key (07213) isn't
recognized:

```
dnssec-policy: test
current time:  Tue Apr  8 10:25:50 2025

key: 36679 (RSASHA256), KSK
  published:  yes - since Tue Apr  8 10:14:10 2025
  key signing:yes - since Tue Apr  8 10:14:10 2025

  Next rollover scheduled on Wed Apr  8 08:09:10 2026
  - goal:   omnipresent
  - dnskey: rumoured
  - ds: rumoured
  - key rrsig:  rumoured

key: 50448 (RSASHA256), ZSK
  published:  yes - since Tue Apr  8 10:14:10 2025
  zone signing:   yes - since Tue Apr  8 10:14:10 2025

  Next rollover scheduled on Fri May  9 08:09:10 2025
  - goal:   omnipresent
  - dnskey: rumoured
  - zone rrsig: rumoured

key: 7213 (RSASHA256), UNKNOWN
  published:  no

  No rollover scheduled
```

I trigger the rollover by ``rndc dnssec rollover -key 50448 -when 
20250408103000`` and the dnssec status shows that a new ZSK key is introduced 
instead:

```
dnssec-policy: test
current time:  Tue Apr  8 10:30:37 2025

key: 36679 (RSASHA256), KSK
  published:  yes - since Tue Apr  8 10:14:10 2025
  key signing:yes - since Tue Apr  8 10:14:10 2025

  Next rollover scheduled on Wed Apr  8 08:09:10 2026
  - goal:   omnipresent
  - dnskey: rumoured
  - ds: rumoured
  - key rrsig:  rumoured

key: 50448 (RSASHA256), ZSK
  published:  no
  zone signing:   no

  Key has been removed from the zone
  - goal:   hidden
  - dnskey: unretentive
  - zone rrsig: unretentive

key: 7213 (RSASHA256), ZSK
  published:  no
  zone signing:   no

  Key has been removed from the zone
  - goal:   hidden
  - dnskey: unretentive
  - zone rrsig: unretentive

key: 19861 (RSASHA256), ZSK
  published:  yes - since Tue Apr  8 10:30:00 2025
  zone signing:   yes - since Tue Apr  8 12:35:00 2025

  Next rollover scheduled on Fri May  9 10:30:00 2025
  - goal:   omnipresent
  - dnskey: rumoured
  - zone rrsig: rumoured
```

The log from systemd journal:

```
Apr 08 10:15:25 test.mydns.me named[174]: keymgr: checkds DS for key 
test.net/RSASHA256/36679 seen published at Tue Apr  8 10:15:25 2025
Apr 08 10:15:25 test.mydns.me named[174]: zone test.net/IN (signed): 
reconfiguring zone keys
Apr 08 10:15:25 test.mydns.me named[174]: CDS (SHA-256) for key 
test.net/RSASHA256/36679 is now published
Apr 08 10:15:25 test.mydns.me named[174]: CDNSKEY for key 
test.net/RSASHA256/36679 is now published
Apr 08 10:15:26 test.mydns.me named[174]: zone test.net/IN (signed): next key 
event: 08-Apr-2025 12:19:10.937
Apr 08 10:18:38 test.mydns.me named[174]: received control channel command 
'dnssec -status test.net'
Apr 08 10:25:50 test.mydns.me named[174]: received control channel command 
'dnssec -status test.net'
Apr 08 10:27:47 test.mydns.me named[174]: received control ch

Re: Survey on the impact of software regulation on DNS systems

2025-04-08 Thread Peter 'PMc' Much 
Michael,

  thank You very much for this message! it came at the right time
and it is truly inspiring! I missed that.

On Fri, Mar 28, 2025 at 01:59:02AM +0100, Michael De Roover wrote:

! > So, while I am not strictly against regulation, the bottomline question
! > appears to be: how do we manage to get /unbiased skill/ into the
! > decision making process?
! 
! When I sent an e-mail to the EU Commission (if memory serves) about the Chips 
! Act, I was told that my correspondence traversed several of their departments 
! before being added to their internal memos. They also mentioned that I should 
! join their "Expert Group", which presumably would've involved representatives 
! of various chips manufacturers (ASML and TSMC come to mind). I didn't join 
and 
! consider my email to be somewhat inaccurate in retrospect, but.. oh well. 

So what You are saying is, it might still work to just talk to these
people?
In earlier times that was usually my stance when discussing matters
in the underground - I might say, why do we not just make a date and
actually talk to the concerned people, as basically they're also
humans, like you and me? And occasionally things did indeed work
out pleasantly that way...

But given the development of recent years, I mostly lost my
optimism. Like a fellow mystician put it:  and it is difficult to cope with sheer madness - I
even made it onto the death-list of some activists ---

! > will be not far into the future that safety-critical material ends
! > up there - probably unnoticed until some accident happens. And after
! > the accident the outcry for regulations will be imminent.
! 
! Fascinating. Just the other day, I did experience a denial of service attack, 
! that turned out to be performed by none other than OpenAI. It was against my 
! Gitea server, with OpenAI's crawlers requesting an unreasonable amount of zip 
! and bundle archives from it. Those were generated, (presumably) transferred 
! and saved to disk. This took down my Gitea instance twice so far, in both 
! cases due to storage being depleted.

Ah, yeah, I've seen these. I don't think it is intentional DoS, rather
just recklessness. I have a cgit public, and I found them there,
downloading utterly worthless copies of the Berkeley sources.
It seems to work similiar to the California gold rush - they think the
more worthless garbage they download from the web, the richer they
will get (for whatever rationale I do not understand). So they ignore
any robots.txt, and fetch every url they can construct, no matter how
useless it might be.

I openend a thread here:
https://forums.freebsd.org/threads/how-valuable-is-the-freebsd-source.96962/

Bottomline so far: I switched my server to IPv6 only, and the spook
was gone entirely. So this is not any technologically advanced party,
and rather some make-money-fast gangs. 

Anyway, recklessness has greatly increased nowadays. Gotten rid of
this one, I already found the next: somebody is sending thousands and
thousands of queries against my named, with randomly created
hostnames:

 1 | m6nij.f71. in a
 1 | ctvwmkxbl25.m0bwykiudf3yozg0u.f75. in a
 1 | hvg5s6rr087hjml.55bvzlcm6ctwyy2.fas. in a
 1 | 5pagomi84gl.fb. in a
 1 | c5eczkjrv.zwm5r3.fb. in a
 1 | vunqrps4r.fbc. in a
 1 | c3u8ya1dasu.fc. in a
 1 | qoo48n.fc. in a
 1 | 57lozdnlui3.pzt6dvia7zr.fch. in a
 1 | 1k03772f837.fcs. in a

This is a public authoritative server, they never get an answer beyond
REFUSED.


! The case of radio kill switches is interesting to me. Unlike smartphone 
radios 
! and their proprietary drivers (which I don't think will ever be open source, 
! with very few exceptions), radio kill switches are easier to argue for. Not 
! only does the technology already exist, it's also easy to make a privacy 
! argument here. No matter how technical people are, we want privacy and 
control 
! over who gets to see what. Everyone wants to be able to close their 
proverbial 
! curtains. I think that many people have been desensitized over time, into an 
! idea that they can't change this status quo and should therefore simply 
accept 
! it. But that doesn't make the desire go away, it just buries it.

I didn't consider that one, just the safety implication of radio
waves. But You are right, it is also a possibility to spy and track
a given hw MAC address, and a proper kill switch should avoid that.
I don't know what happened to the people. Back in the 90s we went to
the street because the government wanted to do a census and we were
opposing the data collection.
So, I still try to figure out what did change, what actually happened
to the people, from a sociological rsp. systemic point of view.

Just an hour ago, at the supermarket, there was a new cashier, and so
he asked if I particpated in the "bonus program" (that is, the "app").
In return I asked him if he isn't ashamed for wanting to sniff
out his customers. He had some difficulty figuring the involved
association ch

Re: Cannot import keys into dnssec-policy

2025-04-08 Thread Matthijs Mekking 

This time I was able to reproduce, thanks.

The reason why the key created by dnssec-keygen is retired because named 
thinks it was in use already. When there is key timing metadata, the key 
is considered to be in use (now or in the past).


Only not previously used keys are considered as a successor in key 
rollovers.


Try generating the key with dnssec-keygen -G. This will create a key 
without setting timing metadata.


I will update the documentation accordingly.

Best regards,
Matthijs

On 4/8/25 05:43, Bagas Sanjaya wrote:

On Mon, Apr 07, 2025 at 09:28:07AM -0500, Matthijs Mekking wrote:

Hi,

I have tried to reproduce but when I am issuing a rollover it selects the
key I generate previously, as expected.

If you believe this is a genuine bug, please support a bug report:

https://gitlab.isc.org/isc-projects/bind9/-/issues/new?issuable_template=Default

and fill in the steps how to reproduce the issue.

Any logs (preferably debug level 3) would then also be greatly appreciated.

Thanks, best regards,

Matthijs



On 3/26/25 14:51, Nguyen Thi Minh Tam via bind-users wrote:

"Hi, I'm trying version 9.18.31.

According to the post on
https://kb.isc.org/docs/dnssec-key-and-signing-policy
, the policy
normally generates keys when they are needed. However, we can generate
the DNSSEC keys ourselves first, and when the policy requires a new key,
it will select the one we created.

There is even an example in that post.

So, I followed that approach. I generated a new key that matches the
policy and placed it in the key directory. However, when it was time to
roll the key, my key was retired, and the policy generated a new one
instead.

Here is my policy:"


dnssec-policy "hosting key" {
          dnskey-ttl PT1M;
          keys{
                  ksk key-directory lifetime P1Y algorithm RSASHA256 2048;
                  zsk key-directory lifetime P30D algorithm RSASHA256 2048;
          };

And i run this command to generate the next key:

dnssec-keygen -a 8 -b 2048 -n ZONE -K /data/keys/policy.com/ policy.com
i even tried
dnssec-keygen -k "hosting key" -l /etc/named.conf -K
/data/keys/policy.com/ policy.com


Hi Matthijs, Hi Nguyen,

I can reproduce the bug, using Nguyen's dnssec-policy.

Before the rollover, I pregenerate the explicit successor ZSK by:

```
$ cd /var/named
# dnssec-keygen -a rsasha256 -b 2048 -f zsk test.net
# chown named:named Ktest.net.+008+07213*
```

``rndc dnssec -status test.net`` shows that the successor key (07213) isn't
recognized:

```
dnssec-policy: test
current time:  Tue Apr  8 10:25:50 2025

key: 36679 (RSASHA256), KSK
   published:  yes - since Tue Apr  8 10:14:10 2025
   key signing:yes - since Tue Apr  8 10:14:10 2025

   Next rollover scheduled on Wed Apr  8 08:09:10 2026
   - goal:   omnipresent
   - dnskey: rumoured
   - ds: rumoured
   - key rrsig:  rumoured

key: 50448 (RSASHA256), ZSK
   published:  yes - since Tue Apr  8 10:14:10 2025
   zone signing:   yes - since Tue Apr  8 10:14:10 2025

   Next rollover scheduled on Fri May  9 08:09:10 2025
   - goal:   omnipresent
   - dnskey: rumoured
   - zone rrsig: rumoured

key: 7213 (RSASHA256), UNKNOWN
   published:  no

   No rollover scheduled
```

I trigger the rollover by ``rndc dnssec rollover -key 50448 -when 
20250408103000`` and the dnssec status shows that a new ZSK key is introduced 
instead:

```
dnssec-policy: test
current time:  Tue Apr  8 10:30:37 2025

key: 36679 (RSASHA256), KSK
   published:  yes - since Tue Apr  8 10:14:10 2025
   key signing:yes - since Tue Apr  8 10:14:10 2025

   Next rollover scheduled on Wed Apr  8 08:09:10 2026
   - goal:   omnipresent
   - dnskey: rumoured
   - ds: rumoured
   - key rrsig:  rumoured

key: 50448 (RSASHA256), ZSK
   published:  no
   zone signing:   no

   Key has been removed from the zone
   - goal:   hidden
   - dnskey: unretentive
   - zone rrsig: unretentive

key: 7213 (RSASHA256), ZSK
   published:  no
   zone signing:   no

   Key has been removed from the zone
   - goal:   hidden
   - dnskey: unretentive
   - zone rrsig: unretentive

key: 19861 (RSASHA256), ZSK
   published:  yes - since Tue Apr  8 10:30:00 2025
   zone signing:   yes - since Tue Apr  8 12:35:00 2025

   Next rollover scheduled on Fri May  9 10:30:00 2025
   - goal:   omnipresent
   - dnskey: rumoured
   - zone rrsig: rumoured
```

The log from systemd journal:

```
Apr 08 10:15:25 test.mydns.me named[174]: keymgr: checkds DS for key 
test.net/RSASHA256/36679 seen published at Tue Apr  8 10:15:25 2025
Apr 08 10:15:25 test.mydns.me named[174]: zone test.net/IN (signed): 
reconfiguring zone keys
Apr 08 10:15:25 test.mydns.me named[174]: CDS (SHA-256) for key 
test.net/RSASHA256/36679 is now published
Apr 08 10:15:25 test.mydns.me named[174]: CDNSKEY for key