Technitium DNS Server VS log2ram

It works on minimal hardware. I am running it on an Orange Pi 3 LTS.

https://technitium.com/dns/

#!/bin/bash # Check input file if [ $# -eq 0 ]; then echo "Usage: $0 " exit 1 fi # Configurable value for zip file suffix SUFFIX="daily" # Get input file DNS_FILE=$1 # Read lines while read -r line; do HOSTNAME=$(echo $line | cut -d',' -f1) IP=$(echo $line | cut -d',' -f2) TOKEN=$(echo $line | cut -d',' -f3) # Construct API URL with IP and token, change any unwanted settings below to false as documented in https://github.com/TechnitiumSoftware/DnsServer/blob/master/APIDOCS.md#backup-settings URL="http://$IP:5380/api/settings/backup?token=$TOKEN&blockLists=true&logs=true&scopes=true&apps=true&stats=true&zones=true&allowedZones=true&blockedZones=true&dnsSettings=true&logSettings=true&authConfig=true" # Construct output file name FILE_NAME=$HOSTNAME-$IP-$(date +%Y%m%d)-$SUFFIX.zip # Call API curl -o $FILE_NAME $URL done < $DNS_FILE

You can try using a DNS/DHCP server other than the Windows one, e.g. Technitium I use this on Linux but as it is written in Dotnet it will of course also work on Windows https://technitium.com/dns/

I recently made an effort to harden my network due to (technically) exposing more of it with FireZone (WireGuard). For the curious, I shared some details in a recent comment. I didn't mention it in the comment, but I also set up local DNS (Technitium) with block lists.

Thanks for asking. There is already a feature request on Github for it. It is not planned to be implemented for now since there are some core features that are prioritized to be implemented. But it should come later once the planned features are implemented.

See what's new in this release: https://github.com/TechnitiumSoftware/DnsServer/blob/master/CHANGELOG.md

How would this compare to https://technitium.com/dns/?

I am working on open source DNS server project since a few years adding features to it whenever I get time: https://github.com/TechnitiumSoftware/DnsServer

Reducing logging, logging to ram and writing to the sdcard once a day helps longevity a lot, especially with quality sd cards.

99% of the time it's the verbose logging of application servers that is the culprit of sdcard failures.

https://github.com/azlux/log2ram

I always use this: https://github.com/azlux/log2ram

If you've got other issues then it's quite likely that lots of small writes from logging and similar has worn out the SD card, mounting the SD card as read only or installing log2ram could prevent it happening to another SD card.

> writing permanent its log files and swap partition

If this is the problem, the solutions are no swap and log2ram https://github.com/azlux/log2ram

I also noticed that Armbian logs to a ramdisk. I didn't investigate the implementation and if its contents survive a reboot.

The only real problems for me are that the SD card will eventually fail no matter what (I mean, much sooner than a SDD or HDD) and that there are basically no Pis at sale at a reasonable price. As a platform it is nearly dead.

For Pi-hole, I have an Rpi Zero with $10 Usb-to-Ethernet adapter, SD-card barely written (with Log2Ram) to avoid wear. Running about 3 years now almost unattended (besides security updates).

In addition to the other helpful suggestions you’ve received, look into using Log2Ram. It does what it sounds like, puts log writes in ram and then writes them to disk on a slower cadence that doesn’t work your SD card that much.

https://github.com/azlux/log2ram

Log files are a bit trickier. I want these to stick around between reboots, so just storing them on a ramdisk wouldn't really work. Thankfully, log2ram solves this problem. Written primarily for Raspberry Pi machines, it works fine on x86-64 laptops. This stores /var/log in RAM but will sync the contents to disk from time to time, ideal for our needs.