My earlier experience with More DNSSEC signing of DNS-01 ACME verifications made me wonder whether I can let bind9 do all the key generation for me.

So I took another zone and configured it for DNSSEC with:

zone "_acme-challenge.minsky.idefix.net" {
    type master;
    file "/var/cache/bind/_acme-challenge.minsky.idefix.net-zone";
    masterfile-format text;
    allow-update { key "acmekey-minsky"; };
    allow-query { any; };
    allow-transfer {
        localnetwork;
    };
    key-directory "/var/cache/bind";
    dnssec-policy "acmezone";
    inline-signing yes;
};

And just reload the configuration and let bind9 handle it:

root@wozniak:/etc/bind# named-checkconf 
root@wozniak:/etc/bind# rndc reconfig
root@wozniak:/etc/bind# rndc dnssec -status _acme-challenge.minsky.idefix.net
dnssec-policy: acmezone
current time:  Tue Jul  7 23:20:59 2026

key: 46040 (ECDSAP256SHA256), KSK
  published:      yes - since Tue Jul  7 23:20:28 2026
  key signing:    yes - since Tue Jul  7 23:20:28 2026

  No rollover scheduled
  - goal:           omnipresent
  - dnskey:         rumoured
  - ds:             hidden
  - key rrsig:      rumoured

key: 53188 (ECDSAP256SHA256), ZSK
  published:      yes - since Tue Jul  7 23:20:28 2026
  zone signing:   yes - since Tue Jul  7 23:20:28 2026

  No rollover scheduled
  - goal:           omnipresent
  - dnskey:         rumoured
  - zone rrsig:     rumoured

I ran the first signing:

root@wozniak:/etc/bind# rndc sign _acme-challenge.minsky.idefix.net

I added the new KSK DS to the parent zone and told it was published:

root@wozniak:/etc/bind# rndc dnssec -checkds -key 46040 published _acme-challenge.minsky.idefix.net
KSK 46040: Marked DS as published since 07-Jul-2026 23:23:51.000
root@wozniak:/etc/bind# rndc dnssec -status _acme-challenge.minsky.idefix.net
dnssec-policy: acmezone
current time:  Tue Jul  7 23:27:27 2026

key: 46040 (ECDSAP256SHA256), KSK
  published:      yes - since Tue Jul  7 23:20:28 2026
  key signing:    yes - since Tue Jul  7 23:20:28 2026

  No rollover scheduled
  - goal:           omnipresent
  - dnskey:         rumoured
  - ds:             rumoured
  - key rrsig:      rumoured

key: 53188 (ECDSAP256SHA256), ZSK
  published:      yes - since Tue Jul  7 23:20:28 2026
  zone signing:   yes - since Tue Jul  7 23:20:28 2026

  No rollover scheduled
  - goal:           omnipresent
  - dnskey:         rumoured
  - zone rrsig:     rumoured

And on the local resolver it works fine:

root@wozniak:~# delv _acme-challenge.minsky.idefix.net soa
; fully validated
_acme-challenge.minsky.idefix.net. 86400 IN SOA	ns2.idefix.net. koos.idefix.net. 112 604800 86400 2419200 86400
_acme-challenge.minsky.idefix.net. 86400 IN RRSIG SOA 13 4 86400 20260722212351 20260707202351 53188 _acme-challenge.minsky.idefix.net. q08TKiz2VB97V8YagQH6viWpjjyA33bF0VM3bJknFXk13DLgN3cg1dr/ 9Bya4AT5hXp+AqvG1+2VY6Z7g237gA==

So the conclusion is I can let bind9 do more of the work for me, and I will end with a working solution.

I sometimes want to take the radio outside, and one of the elements needed is power. For outside radio I take the very used Yaesu FT-857D with microphone and small morse paddle. I usually use the multiband vertical antenna for playing radio outside.

One of the requirements is power. I used to take one of several lead-acid batteries. The highest capacity lead acid battery I used is 12 Ah.

I noticed on transmitting SSB or CW over 50 Watts the voltage as shown on the display of the FT-857D dropping to below 10 Volts where it should be over 12 Volts. When transmitting at 100 Watts the radio will draw up to 20 Ampere which is a bit much for a 12 Ah battery.

The battery is also a bit heavy for holiday use. So I wanted to upgrade to something different. I searched for a long time and selected the Victron 12V 20AH SuperPack Lithium and to charge it I selected the Victron Blue Smart IP65 battery charger 12V with bluetooth.

The bluetooth is nice to keep an eye from a nearby phone to see how the charging is doing.

As this battery has screw terminals I had to make a different cable to connect the radio. This became one of those "I still have to fix this some day" projects. But this evening I have some time because my amateur radio club evening is cancelled. Time to do some other radio work, find the right parts and finish the cable. I made the cable and tested it. When transmitting at a 100 Watts SSB the voltage only drops 0.2 Volts.

After the first tests of DNSSEC signing of DNS-01 ACME zones went fine I decided to add DNSSEC signatures to another zone, document my steps carefully and share my steps.

First bind9 needs a configured dnssec-policy for automatic dnssec signing to tell it when to sign, how, when to rollover keys and when to resign.

I created a dnssec-policy specific for acme zones with static keys (managed outside bind9) so I can do a rollover by hand in the upstream zone. The dnssec-policy configuration:

dnssec-policy "acmezone" {
        # policy which uses static keys managed by hand
        keys {
                ksk key-directory lifetime unlimited algorithm ecdsa256;
                zsk key-directory lifetime unlimited algorithm ecdsa256;
    };
        dnskey-ttl 600;
        max-zone-ttl 86400;
        parent-ds-ttl 6h;
        parent-propagation-delay 2h;
        publish-safety 2d;
        retire-safety 2d;
        signatures-refresh 5d;
        signatures-validity 15d;
        signatures-validity-dnskey 15d;
        zone-propagation-delay 2h;
        nsec3param;
};

The next steps are to reconfigure a dynamic zone to allow automatic dnssec signing. The green parts are the new parts for dynamic dnssec. After changing the configuration I do not reload it yet!

zone "_acme-challenge.gosper.idefix.net" {
        type primary;
        file "/var/cache/bind/_acme-challenge.gosper.idefix.net-zone";
        masterfile-format text;
        allow-update { key "acmekey-gosper"; };
        allow-query { any; };
        allow-transfer {
                localnetwork;
	};
        key-directory "/var/cache/bind";
        dnssec-policy "acmezone";
        inline-signing yes;
};

First I generate the key signing key (KSK) and zone signing key (ZSK) for this zone:

root@wozniak:/var/cache/bind# dnssec-keygen -f KSK -3 -a ECDSAP256SHA256 _acme-challenge.gosper.idefix.net
Generating key pair.
K_acme-challenge.gosper.idefix.net.+013+45699
root@wozniak:/var/cache/bind# dnssec-keygen -3 -a ECDSAP256SHA256 _acme-challenge.gosper.idefix.net
Generating key pair.
K_acme-challenge.gosper.idefix.net.+013+03511

Then I change the ownership of those keyfiles since bind9 needs to be able to change them:

root@wozniak:/var/cache/bind# chown bind:bind K_acme-challenge.gosper.idefix.net.+013+*
root@wozniak:/var/cache/bind# ls -l K_acme-challenge.gosper.idefix.net.+013+*
-rw-r--r-- 1 bind bind 385 Jul  5 13:35 K_acme-challenge.gosper.idefix.net.+013+03511.key
-rw------- 1 bind bind 187 Jul  5 13:35 K_acme-challenge.gosper.idefix.net.+013+03511.private
-rw-r--r-- 1 bind bind 385 Jul  5 13:35 K_acme-challenge.gosper.idefix.net.+013+45699.key
-rw------- 1 bind bind 187 Jul  5 13:35 K_acme-challenge.gosper.idefix.net.+013+45699.private

Now I can reconfigure bind9 to accept these changes:

root@wozniak:/var/cache/bind# named-checkconf
root@wozniak:/var/cache/bind# rndc reconfig

In an earlier test I restarted bind9 before I generated keys. As a result bind9 generated its own KSK and ZSK for the zone and I got confused which one was used.

First status check:

root@wozniak:/var/cache/bind# rndc dnssec -status _acme-challenge.gosper.idefix.net
dnssec-policy: acmezone
current time:  Sun Jul  5 13:39:14 2026

key: 45699 (ECDSAP256SHA256), KSK
  published:      yes - since Sun Jul  5 13:35:22 2026
  key signing:    yes - since Sun Jul  5 13:35:22 2026

  No rollover scheduled
  - goal:           omnipresent
  - dnskey:         rumoured
  - ds:             hidden
  - key rrsig:      rumoured

key: 3511 (ECDSAP256SHA256), ZSK
  published:      yes - since Sun Jul  5 13:35:39 2026
  zone signing:   yes - since Sun Jul  5 13:35:39 2026

  No rollover scheduled
  - goal:           omnipresent
  - dnskey:         rumoured
  - zone rrsig:     rumoured

The next step is to add the DS key for this zone to the parent zone to establish the chain of trust.

root@wozniak:/var/cache/bind# dnssec-dsfromkey -2 K_acme-challenge.gosper.idefix.net.+013+45699.key 
_acme-challenge.gosper.idefix.net. IN DS 45699 13 2 22DF9EB4304B9E210E0E1FA9650BCB30436549424BEFBB5E8172E260EB9DC7F6

I added this record to the idefix.net zone, reloaded it, waited for the updated zone to propagate.

Now I can set the DS status to published.

root@wozniak:/var/cache/bind# rndc dnssec -checkds -key 45699 published _acme-challenge.gosper.idefix.net
KSK 45699: Marked DS as published since 05-Jul-2026 13:45:03.000
root@wozniak:/var/cache/bind# rndc dnssec -status _acme-challenge.gosper.idefix.net
dnssec-policy: acmezone
current time:  Sun Jul  5 13:45:39 2026

key: 45699 (ECDSAP256SHA256), KSK
  published:      yes - since Sun Jul  5 13:35:22 2026
  key signing:    yes - since Sun Jul  5 13:35:22 2026

  No rollover scheduled
  - goal:           omnipresent
  - dnskey:         rumoured
  - ds:             rumoured
  - key rrsig:      rumoured

key: 3511 (ECDSAP256SHA256), ZSK
  published:      yes - since Sun Jul  5 13:35:39 2026
  zone signing:   yes - since Sun Jul  5 13:35:39 2026

  No rollover scheduled
  - goal:           omnipresent
  - dnskey:         rumoured
  - zone rrsig:     rumoured

Before actually using the zone for updates I need to force a signature first:

root@wozniak:/var/cache/bind# rndc sign _acme-challenge.gosper.idefix.net

Desynchronization between unsigned and signed zone

I think I forgot the rndc sign command before the first attempt at updating, and got a weird error:

Jul  5 13:56:01 wozniak named[8408]: zone _acme-challenge.gosper.idefix.net/IN (signed): receive_secure_serial: not exact

The effect is that a dynamic update goes through fine but is not visible when querying the nameserver. This was probably due to doing other update tests before that first rndc sign. This error does not go away by itself, it needs some work. I tried the hints from DNS - DuckCorp Infrastructure - DuckCorp Projects which suggests the inline signing journal file got corrupted.

As a workaround I tried

root@wozniak:/var/cache/bind# rndc sync -clean _acme-challenge.gosper.idefix.net

But that did not make the error go away. So I froze the dynamic zone

root@wozniak:/var/cache/bind# rndc freeze _acme-challenge.wozniak.idefix.net

edited it to increase the serial number in the SOA record, stopped bind9, threw away the journal files in /var/cache/bind:

root@wozniak:/var/cache/bind# rm _acme-challenge.gosper.idefix.net-zone.jbk
root@wozniak:/var/cache/bind# rm _acme-challenge.gosper.idefix.net-zone.signed.jnl

Restarted bind9 and forced a signature again:

root@wozniak:/var/cache/bind# rndc sign _acme-challenge.gosper.idefix.net

Now that error is gone and dynamic updates work and are visible, leading to a successfull acme DNS-01 renew.

Someone at the radio club was selling a set of old Chesilvale DSTS 2 test phones. Those were the standard test phone for analog lines with pulse and dtmf dialing somewhere in the late 90s in the Netherlands, and in other countries.

I was interested as 'gadget' because I am not doing a lot with analoge telephony. It turned out there was an extra DSTS 2 that had its cord cut and other issues, so I got it for free.

I opened it and started cleaning it a bit. Besides the cut wires to connect it to the phone network there are also wires cut which led to a 'TEST/TEL' switch on the back which seems to be specific to the Dutch version. Those wires were cut near the circuit board and near the switch. The switch itself was not functioning and could be pushed into the handset.

On opening it further I found the sliding switch was pushed apart. The sliding mechanism is broken and to replace the sliding switch I would have to remove the label from the back of the handset.

So I tried bypassing the switch with soldered wires and testing the test handset with the Cisco ATA 186.

In one position I get dialtone immediately upon connecting but no other functions. In the other connection I can't draw dialtone with the MONI/AAN switch but the polarity test and the ringer work. Maybe I need to wire up a 2p2t switch to test further.

Afgelopen nacht was er rond 3 uur een heel zware onweersbui. Er waren ontladingen die erg in de buurt klonken.

De gevolgen daarvan merken we ook, want er was vanmorgen geen verbinding naar buiten. Het moment van verbreken 'klopt' met de onweersbui:

Jun 28 03:11:47 wozniak pppd[3956]: No response to 2 echo-requests
Jun 28 03:11:47 wozniak pppd[3956]: Serial link appears to be disconnected.
Jun 28 03:11:47 wozniak pppd[3956]: Connect time 90906.7 minutes.
Jun 28 03:11:47 wozniak pppd[3956]: Sent 3328715374 bytes, received 1278927208 bytes.
Jun 28 03:11:53 wozniak pppd[3956]: Connection terminated.
Jun 28 03:11:53 wozniak pppd[3956]: Connect time 90906.7 minutes.
Jun 28 03:11:53 wozniak pppd[3956]: Sent 3328715374 bytes, received 1278927208 bytes.
Jun 28 03:11:53 wozniak pppd[3956]: Modem hangup

De VDSL link is sindsdien ook down. In de tellingen van het aantal fouten is al een toename te zien vanaf 02:30, wat overeenkomt met toen het onweer begon.

Ik ben even langs de VDSL straatkast gelopen, en die is verdacht stil. Ik herinner me toch van eerder dat er aan de buitenkant duidelijk draaiende ventilatoren te horen waren, dus volledige stilte wijst op een uitval van de voeding.

Het volgende probleem is de storing gemeld krijgen. Bij freedom en bij KPN beweren de sites dat er geen storing hier bekend is. Toch maar even een mailtje naar de freedom helpdesk gestuurd met details, ook al zijn ze pas maandagochtend actief. Later was er wel een monteur bezig met de VDSL straatkast die in een telefoongesprek met iemand probeerde uit te zoeken wat het probleem was. Ondertussen is de monteur weer weg maar is de straatkast nog steeds stil.

Update: weer on-line 17 uur later

Het leek er even op dat er maandag pas wat ging gebeuren maar vanavond liepen er zelfs twee monteurs richting de straatkast, dus er was actie. Omstreeks 20:00 liepen ze vrolijk weer terug, dat gaf me het idee dat ze succes hadden gehad in het repareren/herstarten van dingen en inderdaad kwam de VDSL link weer terug en de verbinding met freedom:

Jun 28 20:04:18 wozniak pppd[3956]: Using interface ppp0
Jun 28 20:04:18 wozniak pppd[3956]: Connect: ppp0 <--> eth3
Jun 28 20:04:18 wozniak pppd[3956]: PAP authentication succeeded

Some other people at the radioclub were active building the mains power filter to the same design I built my mains power filter in September 2023.

So we want to measure the effect. I suggested using powerline network adapters because those cause broadband noise. This measurement will take place when I bring the network adapters and cables, and someone else brings a filter and measuring devices.

But I can test the effect at home, and it is impressive. I dug up the software to request the status in Linux from dguglielmi/dlan-linux-software: devolo dLAN Software Package for Linux · GitHub which compiles fine and runs. It needs to be run as root because it uses raw packets.

First to one mains socket, near the input of the filter. The speed is a lot lower than the maximum I saw earlier with two adapters on the same set of power outlets, so the path through our house wiring is noisy already.

Type    MAC address        Mbps TX/RX       Version/Product
local   00:0B:3B:6F:AE:90  ---.-- / ---.--  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B devolo dLAN 200 AVplus [MT2165]
remote  00:0B:3B:5F:95:AB   30.19 /  19.69  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B

Type    MAC address        Mbps TX/RX       Version/Product
local   00:0B:3B:6F:AE:90  ---.-- / ---.--  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B devolo dLAN 200 AVplus [MT2165]
remote  00:0B:3B:5F:95:AB   31.50 /  21.00  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B

Type    MAC address        Mbps TX/RX       Version/Product
local   00:0B:3B:6F:AE:90  ---.-- / ---.--  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B devolo dLAN 200 AVplus [MT2165]
remote  00:0B:3B:5F:95:AB   40.69 /  28.88  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B

Type    MAC address        Mbps TX/RX       Version/Product
local   00:0B:3B:6F:AE:90  ---.-- / ---.--  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B devolo dLAN 200 AVplus [MT2165]
remote  00:0B:3B:5F:95:AB   36.75 /  21.00  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B

And after moving the adapter to an outlet behind the mains power filter:

Type    MAC address        Mbps TX/RX       Version/Product
local   00:0B:3B:6F:AE:90  ---.-- / ---.--  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B devolo dLAN 200 AVplus [MT2165]
remote  00:0B:3B:5F:95:AB    9.19 /   9.19  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B

Type    MAC address        Mbps TX/RX       Version/Product
local   00:0B:3B:6F:AE:90  ---.-- / ---.--  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B devolo dLAN 200 AVplus [MT2165]
remote  00:0B:3B:5F:95:AB    9.19 /   6.56  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B

Type    MAC address        Mbps TX/RX       Version/Product
local   00:0B:3B:6F:AE:90  ---.-- / ---.--  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B devolo dLAN 200 AVplus [MT2165]
remote  00:0B:3B:5F:95:AB    6.56 /   7.88  INT6000-MAC-3-3-3348-00-2764-20080808-FINAL-B

The status led for the connection which can be green, orange or red depending on quality switches between red and 'off' for this connection! In a simple ping test there are high delays and packet loss.

Conclusion: the mains power filter is effective at filtering!

I set up a sendmail access rule to block all connections from IP addresses that resolve to bc.usergooglecontent.com names. Blocking entire ranges is a measure I don't like to use because it may block valid traffic, but I couldn't find valid e-mail directly from those ranges in my mail archive.

Reporting all the spam sender addresses and spam URLs to google abuse made no difference, the spam kept coming.

Someone asked why I don't block the google cloud address ranges completely at IP level. I checked other logs and found valid web traffic from those ranges.

A recent article ACME CAA Extensions to Become Mandatory - Feisty Duck suggested strongly to me that dnssec will become mandatory for DNS based validation for ACME.

But in reading the upcoming DNS-PERSIST-01 validation standard at Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation I noticed a SHOULD in draft DNS-PERSIST-01 7.7.1 dnssec:

DNS Security Extensions (DNSSEC) [RFC4033] provide cryptographic authentication of DNS data, ensuring that the validation records retrieved by a CA are authentic and have not been tampered with. CAs SHOULD use a DNSSEC-validating resolver when querying dns-persist-01 TXT records. Without one, a CA will silently accept forged responses in DNSSEC-signed zones. If a CA performs DNSSEC validation, it MUST treat validation failure (e.g., expired signatures, broken chain of trust) as a challenge failure and MUST NOT use the record for domain validation. This requirement is stricter than the general DNSSEC guidance in [RFC8555] because dns-persist-01 records are long-lived and their compromise would persist for the record's lifetime.

Re-reading this shows to me long-lived DNS-PERSIST-01 records should indeed have valid dnssec signatures. It is not a must but it is a very good idea. But it is a good argument for also making sure DNS-01 answers can be validated with dnssec.

Since 15 March 2026 validation of dnssec for CAA records and DCV records (domain control validation, implemented as DNS-01 and DNS-PERSISTS-01) must be done when dnssec is enabled on the domain. This is from Ballot SC-085v2: Require Validation of DNSSEC (when present) for CAA and DCV Lookups - CA/Browser Forum.

And here comes a change: my current DNS-01 setup depends on separated _acme-validation.domainname zones in bind9 that are dynamically updated during the ACME transaction. Until now I do all the dnssec signing outside the running bind9 process on the master authoritive nameserver. So I had to read up on automatic signing in bind9, settings for the key management and interesting ways in which bind9 can do things differently than I want.

This also depends on getting dnssec with subzones correct which I failed to get to work in 2019 First tries with DNSSEC on subzones: no success which I finally solved in 2023: Finally working DNSSEC for subzones.

Automatic signing in bind9 as part of automatic dnssec management is a whole new area for me so I had to do some serious reading on how to enable this. Giving bind9 full access to private key material including write access feels weird.

The end result needs more waiting than before: the validation chain has to be correct everywhere before I can renew a certificate. This also means that dnssec problems will stop certificate renewal, and due to dns caching there can be a waiting period before I can try renewing again. So maybe the monitoring of dnssec has to improve.

I am currently testing this on a test domain. The first attempts at getting the validation chain right already showed problems when bind9 decided to generate a new KSK and use it against the policy I set, so I am doing more tests before I write an item on how I did all this and where the pitfalls are that I found. The error from LetsEncrypt is usable to find the problem:

["error","type"]        "urn:ietf:params:acme:error:dns"
["error","detail"]      "DNS problem: looking up TXT for _acme-challenge.www.camp-wireless.com: DNSSEC: Bogus: validation failure \u003c_acme-challenge.www.camp-wireless.com. TXT IN\u003e: no keys have a DS with algorithm ECDSAP256SHA256 from 45.83.232.134 for key _acme-challenge.www.camp-wireless.com. while building chain of trust"

I added the DS key for _acme-challenge.www.camp-wireless.com to the camp-wireless.com zone that I generated, but it turned out bind9 generated a new KSK and ZSK by itself and used those. This is a pitfall that I don't completely understand, so I will test more before I consider this problem solved.

As my certificate renewal scripts run daily the next renewal went through after I updated the DS records and now things went fine. I may look at automatically rotating zone signing keys in dynamic zones.

No production certificates were harmed in testing all this.

Texels went from a brewer only active on the island of Texel to being available in lots of supermarkets in the Netherlands.

Looking for new beers I found "Overzee IPA" and since I do like IPA style beers I gave it a try.

The taste is somewhat different from what I expect from an IPA. A taste of hop, but not like other IPA beers. The beer looks a bit cloudy.

The beer details

Company	Texels bierbrouwerij
Beer name	Overzee IPA
Beer style	IPA - India Pale Ale
Alcohol by volume	6.0 %

I am seeing lots of spam coming from "Google cloud customers" IPv4 ranges, visible as googleusercontent.com names and using links via storage.googleapis.com.

A selection of Received headers and urls from the latest spam mail:

Received: from odditees.co (21.54.87.34.bc.googleusercontent.com [34.87.54.21]) 

   1. https://storage.googleapis.com/poyufgsfqsdf/lis
   2. https://storage.googleapis.com/poyufgsfqsdf/lis
   3. https://storage.googleapis.com/siutdhdgfhg/lis
   4. https://storage.googleapis.com/poyufgsfqsdf/lis
   5. https://storage.googleapis.com/poyufgsfqsdf/lis

Received: from classico.gr (47.30.147.34.bc.googleusercontent.com               

   1. https://storage.googleapis.com/uytrqhsdfhqsdf/lis
   2. https://storage.googleapis.com/pogidgry/lis

Received: from jvsecurepay.com (47.30.147.34.bc.googleusercontent.com           

   1. https://storage.googleapis.com/uytrqhsdfhqsdf/lis
   2. https://storage.googleapis.com/pogidgry/lis

Received: from casando.de (1.36.136.34.bc.googleusercontent.com [34.136.36.1])  

   1. https://storage.googleapis.com/securitycammnr/ls
   2. https://storage.googleapis.com/securitycammnr/ls
   3. https://storage.googleapis.com/securitycammnr/ls
   4. https://storage.googleapis.com/securitycammnr/ls
   5. https://storage.googleapis.com/securitycammnr/ls
   6. https://storage.googleapis.com/securitycamunsb/ls
   7. https://storage.googleapis.com/securitycammnr/ls

Received: from 4wdingaustralia.com (46.134.126.34.bc.googleusercontent.com

   1. https://storage.googleapis.com/kdtjdyudfgh/lis
   2. https://storage.googleapis.com/kdtjdyudfgh/lis
   3. https://storage.googleapis.com/iutjsghui/lis

Received: from roslinyakwariowe.pl (99.239.86.34.bc.googleusercontent.com

   1. https://storage.googleapis.com/prostatesabahus/ls
   2. https://storage.googleapis.com/prostatesabahus/ls
   3. https://storage.googleapis.com/prostjmffteenunsb/ls

Received: from interstatemusic.com (197.214.107.136.bc.googleusercontent.com

   1. https://storage.googleapis.com/uscloudflowstarjm/ls
   2. https://storage.googleapis.com/uscloudflowstarjm/ls
   3. https://storage.googleapis.com/strongcldunsb/ls

Received: from wallis.com.au (197.214.107.136.bc.googleusercontent.com

   1. https://storage.googleapis.com/uscloudflowstarjm/ls
   2. https://storage.googleapis.com/uscloudflowstarjm/ls
   3. https://storage.googleapis.com/strongcldunsb/ls

The urls go through redirects when they don't end up at a "There is an account problem for the requested project." XML file. I guess some work is done to block the worst offenders. But not fast enough.

Lang na de eerste aankondiging van januari 2023 Plannen voor glasvezel hier is dan eindelijk de ODF glasvezel afgemonteerd in de meterkast.

Een persoon kwam voor het binnenbrengen van de vezel vanaf de voortuin naar de meterkast, een tweede persoon kwam er achteraan voor het afmonteren in de Fiber Termination Unit (FTU).

De volgende stap is wanneer Fiber Operator de vezel mag belichten en Freedom Internet er Internet met IPv6 en IPv4 over mag leveren.

I am always hoping to get a new country/entity in the log. Lately it feels like I could not get all opportunities in the log that were available. So there is also a number of missed ones that I also wanted. What ends up in the lists is the contacts I managed, for missed opportunities there will probably be a next time.

Ogasawara islands

The Ogasawara Islands or Bonin Islands are an archipelago near Japan. They count as a separate DXCC entity.

I had a morse contact with JD1BMH who is active from Ogasawara from time to time.

Central Kiribati

Kiribati is a country in Oceania consisting of 32 islands and counts as three separate DXCC entities: West Kiribati, Central Kiribati and East Kiribati.

The Rebel DX Group was active as T31TTT from Central Kiribati. I only got in the log on 20m FT8.

Palau

Palau is a country in Oceania consisting of approximately 340 islands.

Masato Sugiara was active as T88IL in May 2026. I got in the log on 12m FT8 only.

Republic of South Sudan

South Sudan is a country in Africa and is independent since 2011.

I contacted Z81D on 12m FT8.

Ethiopia

Ethiopia is also a country in Africa. The Ethiopian Amateur Radio Society is active under the call ET3AA and I managed to get in the log on 12m FT8.

French Polynesia

French Polynesia is a collection of 121 islands which is an overseas part of France.

Didier Cabot is active as FO/F6BCW and I managed to get in the log on 20m morse.

The count of total worked entities is now at 260.

Today I saw a very regular pattern of about 1.9 requests per second for one website. All in the 4xx category, and with some looking at the logs it seems all were attempts to find source code with included secrets for the website. This is a low enough rate to not hit ratelimits.

Since this was for a website that has exactly one non-public purpose and a very limited set of working URLs I decided to try to answer all those requests with big files of randomness and see if the attacking bot could deal with that.

The plan was to respond to any invalid URL with a large binary blob, to make the attacker fetch all kinds of junk data to analyze.

After some testing I ended up with the following in the Apache configuration:

    <Location "/">
        FallbackResource /random.bin
    </Location>

The random.bin file was created with

$ dd if=/dev/urandom of=random.bin bs=1k count=1024

Sending back binary blobs of randomness didn't change the request rate at all. I experimented a bit with the size of the returned file. When the file was big enough to fill my upstream almost completely the transfers were aborted, but the requests absolutely did not stop or change rate.

In the end 60546 HTTP requests were logged from IPv4 address 34.178.58.49 registered for google cloud customers. The client has about 19 gigabytes of data to analyze for leaking secrets.

So my conclusion is that I need more upstream bandwidth to annoy attackers. An upgrade to gigabit fiber-based Internet is on its way, although it will take about a year before it'll be connected to my preferred Internet provider.

I also learned that if you have multiple configuration items 'Location' with 'FallbackResource' you have to put the most-specific one last. The '<Location "/">' was for all URLs within one server, and that server uses a more specific FallbackResource for normal operations.

For a while I saw logging that the zigbee powerswitch I bought had an update available according to zigbee2mqtt.

To keep an eye on things I subscribed to /zigbee2mqtt/bridge/+ for log messages.

{"level":"info","message":"Checking if update available for 'sch-mancave'"}
{"level":"info","message":"MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{\"message\":\"Checking if update available for 'sch-mancave'\",\"meta\":{\"device\":\"sch-mancave\",\"status\":\"checking_if_available\"},\"type\":\"ota_update\"}'"}
{"message":"Checking if update available for 'sch-mancave'","meta":{"device":"sch-mancave","status":"checking_if_available"},"type":"ota_update"}
{"level":"info","message":"Update available for 'sch-mancave'"}

This evening I started the update with steps from OTA updates - zigbee2mqtt.

I am checking both in the zigbee2mqtt console and via a subscription to the zigbee2mqtt/bridge/+ subject. The update works, but it takes a while:

{"level":"info","message":"Updating 'sch-mancave' to latest firmware"}
{"level":"info","message":"MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{\"message\":\"Updating 'sch-mancave' to latest firmware\",\"meta\":{\"device\":\"sch-mancave\",\"status\":\"update_in_progress\"},\"type\":\"ota_update\"}'"}
{"message":"Updating 'sch-mancave' to latest firmware","meta":{"device":"sch-mancave","status":"update_in_progress"},"type":"ota_update"}
{"level":"info","message":"Update of 'sch-mancave' at 0.00%"}

{"level":"info","message":"Update of 'sch-mancave' at 1.85%, ≈ 27 minutes remaining"}

Update: update successful

Almost half an hour later:

{"level":"info","message":"MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{\"message\":{\"id\":\"sch-mancave\"},\"meta\":{\"device\":\"sch-mancave\",\"from\":null,\"status\":\"update_succeeded\",\"to\":null},\"type\":\"ota_update\"}'"}
{"message":{"id":"sch-mancave"},"meta":{"device":"sch-mancave","from":null,"status":"update_succeeded","to":null},"type":"ota_update"}
{"level":"info","message":"MQTT publish: topic 'zigbee2mqtt/bridge/response/device/ota_update/update', payload '{\"data\":{\"from\":null,\"id\":\"sch-mancave\",\"to\":null},\"status\":\"ok\"}'"}

Gisteren stonden er ineens mensen namens Open Dutch Fiber voor de deur of ze de glasvezel onder de tuin door mochten brengen naar de voorgevel toe. Dat was voor ons prima. De glasvezel is vanaf de straat onder de voortuin 'geboord' en er zijn een of twee tegels in de voortuin opgetild en weer netjes teruggelegd.

De volgende stap gaat het naar binnen brengen en afmonteren in de meterkast zijn. Over de planning van die werkzaamheden zal contact opgenomen worden. Sinds de graafwerkzaamheden voor de deur zie ik in de omgeving al aansluitingen gemaakt worden en ik zie wireless netwerken met 'ODIDO' in de naam ontstaan. Ook ben ik al eens langs het gebouwtje gelopen waar alles aangesloten is. Een donkergroen blok met een deur en wat stickers dat het van Open Dutch Fiber is.

Ik heb dus voorzichtige hoop dat het moment dat andere partijen zoals Fiber Operator en daarmee Freedom Internet toegang krijgen tot de ODF aansluitingen bij ons in de buurt niet tot ver in 2027 duurt.

Past weekend was the CW World Wide WPX Contest 2026 CW edition.

I participated a few hours Saturday and a few hours Sunday. Although this is a big 48 hour contest with lots of opportunities for contacts I also had other things to do in the weekend and propagation wasn't cooperating a lot. Beforehand I thought about setting up an antenna for 15 meters but I didn't feel like it due to the high temperatures outside.

I made 90 contacts, one on the 40 meter band where I had some weird interference to the radio so I stopped on that band. All other contacts were on the 20 meter band so I entered my results in the 20 meter only category.

The results according to TLF:

                                             Band   160   80   40   20   15   10
                                             QSO      0    0    1   89    0    0
                                                                                
                                                                                
                                             Pts: 117  Mul: 83 Score: 9711      

Something I came across in the supermarket, and to my surprise it's a new one.

It's a blonde beer. Not too much alcohol

A nice taste, not too complicated. I'm not sure the taste is exactly what I expect from a blond beer, it's somewhat near to a white beer (witbier) which I also had with Cornet Oaked.

The beer details

Company	Cornet
Beer name	Cornet Gold Blond
Beer style	Blond beer
Alcohol by volume	5.8 %

The past weekend was a good weekend for contacts on the 6 meter (50 MHz) amateur band. Normally contacts on this band are possible for line-of-sight plus a bit, but with atmospheric refraction this can extend to longer distances. The current heat and high pressure areas help create this refraction.

I don't have an antenna for this band so I can only receive the strongest signals, and my signals are weak at best. I managed to make contacts into Hungary (1183 km), Ireland (907 km), Estonnia (1459 km), Latvia (1430 km) Slovakia (1002 km) and Spain (1465 km). And also the Netherlands (19 km). Really nice to see what I can do with this setup. All in FT8. In FT8 signal strengths are very visible and some stations went from 'no signal' to 'strong signal' at +10 dB in a minute. Getting them on the good propagation was some timing and a lot of luck.

Past weekend was the His Majesty the King of Spain CW Contest edition 2026. I participated for a while late Saturday evening and Sunday morning. In total I made 57 contacts which is not a lot for the time I was on the air. On Sunday morning I set up the multiband vertical antenna for 15 meters in the front yard hoping to get some contacts on this band, but I only got 16 contacts in the log on this band.

I had a lot of trouble hearing serial numbers so I expect a few errors in the log.

The results according to TLF:

                                             Band   160   80   40   20   15   10
                                             QSO      0    0   22   19   16    0
                                             Mult     0    0   17   17   12    0
                                                                                
                                             Pts: 89  Mul: 46 Score: 4094       

The weird old hardware collection includes a rotary phone. An original PTT Telecom "T65 IDK" with pulse dialing. I hooked it up to the Cisco ATA 186 and tried to dial a number, but the Cisco ATA 186 does not support pulse dialing. With a DTMF generator on my smartphone I was able to make a few calls.

The ATA does drive the bell nicely, it gives a good ring. The ATA is set up for american style dial tone and ring cadence. Which is weird on a very Dutch phone. I remember changing it to the american settings but I don't remember my reasoning, so it was probably mostly 'because I can'.

As Cisco deems this device 'end of life' and 'end of support' it was a bit hard to find the documentation for it. With searching I could find the "Cisco ATA 186 and Cisco ATA 188 Analog Telephone Adapter Administrator's Guide (SCCP)" and "Cisco ATA 186 and Cisco ATA 188 Analog Telephone Adapter Administrator's Guide (H.323)" from Cisco, but not the version I wanted. But eventually I found Cisco ATA 186 and Cisco ATA 188 Analog Telephone Adaptor Administrator’s Guide (SIP) and saved a local copy. And this document doesn't have the tone settings per country, but Cisco has those in Recommended Cisco ATA Tone Parameter Values by Country which was linked from documentation for MGCP. I also saved a local copy.

Determining the right settings while using SIP after going through the documentation for SCCP, H.323 and MGCP was quite an intro into Cisco telephony!

Now I can make things weird by setting the tones and ringing cadence to any country I like!