Let’s start with a brief reminder of non-existence proofs in DNSSEC. If you have a solid understanding of the topic, feel free to skip this introduction.
The standard DNSSEC solution to proving a record’s non-existence is the NSEC RR. It contains the next node in the lexicographical order and a bitmask of available RTYPEs:
SaltStack, DNS and TLSA
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.
SaltStack, DNS and ssh
In my last post, I showed, how we can combine SaltStack and Knot to have some basic records filled in 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.
Managing DNS via 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.
RFC 9432: DNS Catalog zones
A DNS zone is usually served by multiple authoritative servers, which is actually recommended for the sake of redundancy. Large authoritative DNS operators even combine different name server implementations to avoid complete infrastructure outage in case of any software error. For synchronizing zone contents between authoritative servers, a DNS-specific mechanism is available, called zone transfer. It is well established and supported by all common DNS implementations. It enables both full zone transfer (AXFR) and incremental update (IXFR).
Almost All .CZ Domains Are Ready for The February DNS Maintenance
A global DNS maintenance is scheduled for February 1, 2019, and authoritative server operators must get ready for it. That is why we dedicate our today’s article to the state of readiness of .CZ domains for changes that will be effective from the beginning of next month.
DNS traffic collector
We are releasing dns-collector, an entry part of our pipeline for monitoring of our DNS servers and analysis of the DNS traffic. Together with advanced analysis of the collected data, we can not only monitor the DNS traffic for urgent problems, but also detect and examine long-term trends and issues (e.g. misconfiguration of other servers). We have presented this system at the IT 15.2 conference (video and slides in Czech).
How the TTL reducing impacted the .cz zone
In mid-February we informed about Reducing TTL in the .cz zone by one hour. Then, at a similar hour every Wednesday, we reduced it by another hour, until on March 15, 2017 we reached the required value of 1 hour (i.e. TTL=3600).