Desec.io is a solid option - it allows for various types of records like TLSA and SRV. It can also generate scoped API tokens e.g. for "only TXT records of the _acme-challenge subdomain of example.com" to use in automated cert renewals, so pretty good for granularity. It's also a nonprofit.
I think selfhosting DNS is beneficial when you wanna control your own DNSSEC keys, but you'd need to account for high availability and safety. With that, you could do what's called a "hidden primary + public secondary" setup to protect your master DNS data from the public prying. You can even use 3rd-party services like ns-global.zone as your secondaries for redundancy and to reduce load on your infra, too. I recommend Technitium and their guidance if you wanna get started
Technically something like DANE can allow you to present DNSSEC-backed self-signed certs and even allow multi-domain matching that removes the need for SNI and Encrypted Client Hello... but until the browsers say it is supported, it's not
I write homelab docs mostly for user guidance like onboarding, login, and service-specific stuff. This helps me better design for people by putting myself in their shoes, and should act as a reference document for any member to come back to.
Previously I built an Mkdocs-Material website with a nice subdomain for it, but since the project went on maintenance mode, I'm gonna migrate all docs back to a Forgejo wiki since it's just Markdown anyways. I also run an issue tracker there, to manage the homelab's roadmaps and features since it's still evolving.
I find this approach benefiting compared to just documenting code. I'm not an IaC person yet, but I hope when I am, the playbooks should describe themselves for the nitty-gritty stuff anyways. I do write some infra notes for myself and perhaps to onboard maintainers, but most homelab developments happen in the issue tracker itself. The rest I try to keep it simple enough for an individual to understand
Nextcloud forked from the old PHP-based ownCloud stack, while Opencloud forked from the Infinite Scale Go-based stack. It also by default preserves the filesystem hierarchy on your server without needing a database, using a storage driver called PosixFS.
The Windows clients currently do support selective syncing so it is on-par with OneDrive. Android client looks to be forked from old Owncloud, and has offline availability too.
What issues did you have reverse-proxying? For me it was just as simple as pointing to port 5380. Other ports like 53 could be passed on with a layer-4 router
What about the login issues? I'd hope they'll be integrating with OIDC or some other auth mechanism, but for now managing 2FA creds should make do
Allows using DoH/DoT/DoQUIC/recursive upstreams without installing extra packages (unbound, cloudflared, etc)
Allows acting as a DoH/DoH3/DoT/DoQUIC server alongside normal DNS over UDP and TCP
Allows configuring SOCKS/HTTP proxies for forwarders
Act as authoritative zone server with DNSSEC signing
Allows custom responses via plugins (e.g. conditional responses based on client's IP addresses)
Accept PROXY Protocol to forward client IPs from trusted load balancers
All the clustering and zone transfers magic
DNS64
It really dives deep into the inner workings of DNS and does pretty much anything Pi-Hole does, with many more security and QoL features. Although the UI may feel a bit dated, I'd recommend it to anyone running their own homelab infrastructure beyond just adblocking
Thanks for posting this here. I'm not sure what to think about this, just set up mkdocs-material with huge customizations, including the macros plugin and tons of CSS. So it'd be tedious to eventually migrate to the new "component system" as they say.
Welp, should've gone with a barebone SSG and configured what I want. Feels like I'm kinda stuck in no man's land now.
I find it odd that a report for the proprietary Github platform takes the newsletter's spotlight, it's not very relevant. I'd much prefer if the writer could expand his thoughts on those new version releases or featured blogposts, especially the ones he finds interested in.
The client IP problem is a longstanding issue in podman's virtual bridge networks.
As a workaround I'd run HAProxy rootless, using the pasta networking mode as that one allows seeing native client IP. With pasta's -T flag (see docs) I'd forward traffic to another caddy container binding to 127.0.0.1:8080 or something similar.
This would coincide with your firewalld/HAProxy port-forwarding setup, but it has more rootlessness to it. It's still not perfect and you'd still need to tweak sysctls, but I hope it may be useful
You'll need a TURN server to relay calls and provide signalling capabilities, which is needed most of the time. Here's Synapse docs on it, and I'll probably use coturn:
You should add your DNS forwarder as its own node in Tailscale, and configure the tailnet to resolve DNS through it. That way you'll be able to resolve both MagicDNS node names and your local domains, as well as being blocklist-enabled. Besides, I think you can also define custom A/AAAA records on your Tailscale console, skipping local records on Pi-hole altogether.
I'd also recommend Technitium for a new DNS solution, mainly because they're going to add support for clustering soon. This could be highly useful if you want to configure blocklists once and sync them between different Technitium nodes. Should it works out, I'm thinking of installing it alongside every Tailscale exit node, for the benefit of synced blocklists, local domains, and exit-node geolocated IPs for external domains.
Rsync depends on OpenSSH, but it definitely isn't SFTP. I've tried using it against an SFTPGo instance, and lost some files because it runs its own binary, bypassing SFTPGo's permission checks. Instead, I've opted for rclone with the SFTP backend, which does everything rsync do and is very well compliant.
In fact, while SFTPGo's main developer published a fix for this bug, he also expressed intention to drop support for the command entirely. I think I'm just commenting to give a heads up for any passerby.
Hi, I think OP wants their sibilings to directly connect to their PC, skipping any relays, even if it's their VPS.
But if you are comparing setting up your own VPS instead of relaying through Tailscale's DERP, then the answer is... it depends on the distance and whether you can establish VPS->Local VM direct connections.
I found opening a specified port for Tailscale on the VPS to help with direct connections with CGNAT'd peers. I'm not familiar with Pangolin, but I think the same principle applies as long as at least one address:port combination is agreed between Wireguard peers.
If I'm being honest though, before doing all this, try asking your ISPs for IPv6 to avoid these cumbersome things together.
Desec.io is a solid option - it allows for various types of records like TLSA and SRV. It can also generate scoped API tokens e.g. for "only TXT records of the
_acme-challengesubdomain of example.com" to use in automated cert renewals, so pretty good for granularity. It's also a nonprofit.I think selfhosting DNS is beneficial when you wanna control your own DNSSEC keys, but you'd need to account for high availability and safety. With that, you could do what's called a "hidden primary + public secondary" setup to protect your master DNS data from the public prying. You can even use 3rd-party services like ns-global.zone as your secondaries for redundancy and to reduce load on your infra, too. I recommend Technitium and their guidance if you wanna get started