Some time ago I published a post called DNS Test Names & Resource Records which lists many different FQDNs with lots of different RRs. You can use those public available DNS names to test your DNS servers or the like. However, I was missing a packet capture showing all these resource records as they appear on the wire. So now, here it is. If you are searching for some packets to test your tools for whatever reason, feel free to download this pcap.
If you’re into DNSSEC, you’ll probably have to troubleshoot or at least to verify it. While there are some good online tools such as DNSViz, there is also a command-line tool to test DNSSEC signatures onsite: delv.
It’s not always this simple DNS thing such as “single query – single answer, both via UDP”. Sometimes you have some more options or bigger messages that look and behave differently on the network. For example: IP fragmentation for larger DNS answers that do not fit into a single UDP datagram (hopefully not after the DNS flag day 2020 anymore), or DNS via TCP, or some newer options within the EDNS space such as “EDNS Client Subnet” (ECS) or DNS cookies.
I won’t explain any details about those options, but I am publishing a pcap with that kind of packets along with some Wireshark screenshots. Feel free to dig into it.
I was interested in how a recursive DNS server resolves DNS queries in detail. That is, not only the mere AAAA or A record, but also DNSSEC keys and signatures, the authority and additional section when testing with dig , and so on. For this I made two simple DNS queries to my recursive DNS server which resulted in more than 100 DNS packets at all. Wow.
In the following I am publishing a downloadable pcap so that you can analyse it by yourself. Furthermore I am showing some listings and screenshots to get an idea of the DNS resolution process.
In my last blogpost I showed how to perform a DNSSEC KSK rollover. I did it quite slowly and carefully. This time I am looking into an emergency rollover of the KSK. That is: What to do if your KSK is compromised and you must replace it IMMEDIATELY.
I am listing the procedures and commands I used to replace the KSK of my delegated subdomain dyn.weberdns.de with BIND. And as you might already suggest it, I am showing DNSViz graphs after every step since it greatly reveals the current DNSKEYs etc.
Probably the most crucial part in a DNSSEC environment is the maintenance of the key-signing key, the KSK. You should rollover this key on a regular basis, though not that often as the zone signing keys, the ZSKs. I am doing a KSK rollover every 2 years.
In the following I will describe the two existing methods for a KSK rollover along with a step-by-step guide how I performed such a rollover for my zone “weberdns.de”. Of course again with many graphics from DNSViz (with “redundant edges”) that easily reveal the keys and signatures at a glance.
I am testing a lot with my own DNS servers as well as with third-party DNS implementations such as DNS proxies on firewalls, DNSSEC validation on resolvers, etc. While there are a number of free DNS online tools around the Internet I was lacking some DNS test names with certain properties or resource records. Hence I configured a couple of them on my own authoritative DNS servers and its zone weberdns.de.
For example, we encountered a bug on the Palo Alto DNS proxy that has not stored the TTL value correctly – hence some test names with different TTL values. Or we had some problems when a single DNS name has more than 15 IPv4/IPv6 addresses – hence some test names with lots of addresses. And many more: Continue reading DNS Test Names & Resource Records
What is the biggest problem of PGP? The key distribution. This is well-known and not new at all. What is new is the OPENPGPKEY DNS resource record that delivers PGP public keys for mail addresses. If signed and verified with DNSSEC a mail sender can get the correct public key for his recipient. This solves both key distribution problems: 1) the delivery of the public key and 2) the authenticity of the key itself, i.e., that you’re using the correct key to encrypt a mail.
The “DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP” is specified in the experimental RFC 7929. Let’s have a look on how you can add your public key into the zone file of your DNS server.
One important maintenance requirement for DNSSEC is the key rollover of the zone signing key (ZSK). With this procedure a new public/private key pair is used for signing the resource records, of course without any problems for the end user, i.e., no falsified signatures, etc.
In fact it is really simply to rollover the ZSK with BIND. It is almost one single CLI command to generate a new key with certain time ranges. BIND will use the correct keys at the appropriate time automatically. Here we go:
To overcome the chicken-or-egg problem for DNSSEC (“I don’t need a DNSSEC validating resolver if there are no signed zones”), let’s install the DNS server Unbound on a Raspberry Pi for home usage. Up then, domain names are DNSSEC validated. I am listing the commands to install Unbound on a Raspberry Pi as well as some further commands to test and troubleshoot it. Finally I am showing a few Wireshark screenshots from a sample iterative DNS capture. Here we go:
If you are searching for a DNSSEC validating DNS server, you can use BIND to do that. In fact, with a current version of BIND, e.g. version 9.10, the dnssec-validation is enabled by default. If you are already using BIND as a recursive or forwarding/caching server, you’re almost done. If not, this is a very basic installation guide for BIND with DNSSEC validation enabled and some notes on how to test it.
This is a basic tutorial on how to install BIND, the Berkeley Internet Name Domain server, on a Ubuntu server in order to run it as an authoritative DNS server. It differs from other tutorials because I am using three servers (one as a hidden primary and two secondaries as the public accessible ones), as well as some security such as denying recursive lookups and public zone transfers, as well as using TSIG for authenticating internal zone transfers. That is, this post is not an absolute beginner’s guide.