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.
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.
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.
In this post, I’d like to introduce the upcoming major version of Knot Resolver project, which is currently in the testing and debugging phase, and we would greatly appreciate if you could try it out and give us any feedback on it.
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).
Contemporary DNS software is very complex. Vendors and development teams lack feedback about the features that are actually in use. Our survey aimed to obtain such information from users. The results are described in this article. Users and administrators of DNS resolvers from any vendor were invited to participate in this survey. This post follows the article “Survey: How do you configure DNS resolvers?”.
I try to describe the basic building blocks of our national domain registry administration to people around me quite often. Yet (or maybe for that very reason), the .cz is still perceived as something that simply works. Just like when you get in your car to take your children to school every morning. You expect the journey to take the usual 10 minutes (or 15 if you need to refuel) and that you won’t have to deal with any trouble. Even though you know that you need to change the oil regularly, check and change worn parts, or repair defects caused by operation, most of you leave these “out of order” cases to service professionals or at least a handy neighbor and avoid having to wash your hands from automotive grease or to remember the required type of brake pads. Modern cars are able to inform you of any necessary maintenance and all you have to do is dial the correct phone number. Although you don’t fully understand the person at the other end of the line, they manage to get through to you because you have a basic idea of how a car works.
DNS Shotgun is a bechmarking tool specifically developed for realistic performance testing of DNS resolvers. Its goal is to simulate real clients and their behaviour, including timing of queries and realistic connection management, which are areas where traditional tools are lacking.
Since the end of January 2021, the data from all authoritative DNS servers operated by CZ.NIC about DNS transactions (queries and responses) is being collected exclusively using the new standard Compacted-DNS (C-DNS) format defined in RFC 8618. For data acquisition on the servers we use the DNS Probe software, developed by CZ.NIC Labs in cooperation with Brno Technical University. This milestone marks the end of a six-month transition period in which we migrated all servers from the traditional PCAP format that we used previously. During that period we heavily tested and improved the performance and stability of DNS Probe, and also compared the results obtained in both the old and new format.
It is no longer “trending”, but at the dawn of the millennium, the increasing globalization together with the rise of modern technology and especially the Internet gave birth to the term “Follow the Sun”. For the young or old and forgetful, here is what it was all about. For example, while online services that usually require continuous operation and worldwide accessibility at any given time, a service may stop working or become inaccessible to some users. Anytime. How to provide technical support for such service without forcing employees to be awake at night in a certain time zone? Spread the workers around the world so that you always have someone who has daytime (the Sun over their head) and can provide support for the online service. And if the worker can’t solve the issue, they would pass it to the next one in the direction of the moving sun, who would finish the job. The fact that the time needed to solve the request was not measured in hours, but in the number of revolutions of the request around the Earth, is not so important.