I just wrote a self-hosted #dyndns server using #knotdns, #bottle for the update server (https PUT), and a #python client to detect IP changes. It's running on #AlpineLinux, the code is minimal and it only uses packages that are in the Alpine repos. Full #IPv4 and #IPv6 support, you can use either or both.
Why? It's a cool project, and IMHO every dyndns clients and services I tried were bad, insecure, or both.
successfully migrated my hidden primary #DNS from #bind9 on a VPS to #knotdns on my homelab. @isnic caused me a little trouble, since I couldn't add the new DS key while the old zone was still active.
next up: automatic knot backups and a #dnscontrol setup
Last week was another stakeholder meeting on #DNS4EU. #Whalebone provided a short overview of the project including a timeline. Public launch is scheduled for June this year. The talk elaborates on various considerations of the new #DNS project. I was mostly interested in the deployment aspect, the #DDoS slides and the #privacy and #anonymization mechanisms.
My personal main concern with the project is the absence of resolver technology. The project plainly uses the #KnotDNS resolver. Not a bad choice, but University taught me that diversity in the backend software introduces even more resiliency. Yet, as Whalebone is a #Czech company, it is apparent why they chose #KnotDNS exclusively.
The slides are public.
My colleagues are putting together a new DoS protection mechanism in the upcoming Knot Resolver 6. Together we have written a blog post outlining how it works. Enjoy!
https://en.blog.nic.cz/2024/07/15/knot-resolver-6-news-dos-protection-operators-overview/
#KnotResolver #KnotDNS #DNS #DDoS #DoS #security #ratelimiting
This is the new #DNS infrastructure I built on #FEE_CTU. #CVUT
DNS zones are defined in a custom YAML format with additional metadata and versioned in #git on #GitLab. They are validated using JSON schema, yamllint and custom semantic checks (both in editor and CI). CI job converts them to zone files (and also canonical JSON) and deploys them to hidden master – #KnotDNS. I’ve also created an interactive table view (SPA in React) on top of zone data for easy filtering and CSV export generation.
During my lunch break, I watched the #DNS4EU update of DNS-OARC 41 earlier this year. Since the company responsible for operating the DNS4EU project is Czech, it comes at no surprise that they consider #KnotDNS as part of their infrastructure. Yet, in the talk it does not sound like they settle on software diversity, and predominantly consider the (pretty reliable) Czech resolver.
From other folks, I heard that software diversity is just one of the resiliency features among ASN diversity, geographical diversity, etc. Why is this not highlighted in the "scope, timeline and challenges" talk on DNS4EU?
Lately I blogged about how am I managing my DNS entries via SaltStack. So far it was about being a great time saver, but nothing that you couldn’t do manually with considerably more effort. This time, let’s take a look at something that would be in some setups almost impossible manually - adding TLSA records for your webs. What is TLSA TLSA records specify SSL certificate used by specified service.
In my last post, I showed how we can combine SaltStack and Knot to have some basic records filled your zone. As I was introducing the concept, I picked the most obvious and basic entries. But since we have a hammer now, everything starts to look like a nail. And there is much more that can be stored in DNS apart from IP addresses. Let’s take a look at some other examples and how to get them automatically filled in by SaltStack.
Running services online without domain is hard. More services you run, more DNS entries you need to manage. More services you run, more servers you need to manage. And when you manage several servers, it’s time to use some orchestration. But what about all those domains associated with those servers and services? Can’t that be also part of the orchestration? Somehow automated? Of-course it can. Let me tell you how am I handling it for my domains and servers.
Patrick
ѕенааѕ
Max Resing
Turris project
Oto Šťáva
Jakub Jirutka 🇨🇿🇺🇦
Michal Hrušecký 
