You probably know already the concept of the Pi-hole. If not: It’s a (forwarding) DNS server that you can install on your private network at home. All your clients, incl. every single smartphone, tablet, laptop, and IoT devices such as smart TVs or light bulb bridges, can use this Pi-hole service as their DNS server. Now here’s the point: it not only caches DNS entries, but blocks certain queries for hostnames that are used for ads, tracking, or even malware. That is: You don’t have to use an ad- or track-blocker on your devices (which is not feasible on smart TVs or smartphone apps, etc.), but you’re blocking this kind of sites entirely. Nice approach!
Yes, there are already some setup tutorials for the Pi-hole out there. However, it’s not only about installing the mere Pi-hole, but setting it up with your own recursive DNS server (since the default installation forwards to public DNS servers), using DNSSEC, and adding some more adlists. That’s why I am listing my installation procedure here as well. However, it’s not a complete beginners guide. You’ll need some basic Linux know-how.
Continue reading Pi-hole Installation Guide
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.
Continue reading DNS Capture – The Records Edition
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.
delv will send to a specified name server all queries needed to fetch and validate the requested data; this includes the original requested query, subsequent queries to follow CNAME or DNAME chains, and queries for DNSKEY, DS and DLV records to establish a chain of trust for DNSSEC validation. It does not perform iterative resolution, but simulates the behavior of a name server configured for DNSSEC validating and forwarding.
Continue reading Dive into delv: DNSSEC Validation
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.
Continue reading DNS Capture: UDP, TCP, IP-Fragmentation, EDNS, ECS, Cookie
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.
Continue reading Single DNS Query – Hundreds of Packets
Implementing DNSSEC for a couple of years now while playing with many different DNS options such as TTL values, I came around an error message from DNSViz pointing to possible problems when the TTL of a signed resource record is longer than the lifetime of the DNSSEC signature itself. Since I was not fully aware of this (and because I did not run into a real error over the last years) I wanted to test it more precisely.
Continue reading Signed DNS Zone with too long-living TTLs
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.
Continue reading DNSSEC KSK Emergency Rollover
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.
Note that this blogpost is NOT about the Root Zone KSK Rollover
that appears in 2017/2018. It is merely about your OWN zone
that is secured via DNSSEC.
Continue reading DNSSEC KSK Key Rollover
If you are already familiar with DNSSEC this is quite easy: How to sign a delegated subdomain zone. For the sake of completeness I am showing how to generate and use the appropriate DS record in order to preserve the chain of trust for DNSSEC.
Continue reading Signing a Delegated Subdomain
Until now I generated all SSHFP resource records on the SSH destination server itself via
ssh-keygen -r <name>. This is quite easy when you already have an SSH connection to a standard Linux system. But when connecting to third-party products such as routers, firewalls, whatever appliances, you don’t have this option. Hence I searched and found a way to generate SSHFP resource records remotely. Here we go:
Continue reading Generating SSHFP Records Remotely
This is actually a bad user experience problem: To generally omit the manual verification of SSH key fingerprints I am using SSHFP. With fully qualified domain names (FQDN) as the hostname for SSH connections such as
ssh nb10.weberlab.de this works perfectly. However, admins are lazy and only use the hostname without the domain suffix to connect to their servers since the domain search does the rest:
ssh nb10. Not so for SSHFP which fails since the default OpenSSH client does not use canonicalization for its DNS queries. Hence you must explicitly enable canonicalization for OpenSSH.
Continue reading SSHFP: FQDN vs. Domain Search/DNS-Suffix
I am intensely using the SSH Public Key Fingerprint (SSHFP, RFC 4255) in all of my environments. Since my zones are secured via DNSSEC I got rid of any “authenticity of host ‘xyz’ can’t be established” problems. As long as I am using my central jump host with OpenSSH and the “VerifyHostKeyDNS yes” option I can securely login into any of my servers without any warnings. Great!
However, I encountered a couple of daily problems when using SSHFP. One of them was the question whether SSHFP works behind CNAMEs, that is, when connecting to an alias. Short answer: yes. Some more details here:
Continue reading SSHFP behind CNAME
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.
Continue reading PGP Key Distribution via DNSSEC: OPENPGPKEY
I really like the kind of security features that are easy to use. The CAA “DNS Certification Authority Authorization” is one of those, specified in RFC 6844. As a domain administrator you must only generate the appropriate CAA records and you’re done. (Unlike other security features such as HPKP that requires deep and careful planning or DANE which is not used widely.) Since the check of CAA records is mandatory for CAs since 8. September 2017, the usage of those records is quite useful because it adds another layer of security.
Continue reading CAA: DNS Certification Authority Authorization
I know that BIND correctly changes the serial numbers of zones when it is enabled with inline signing and auto-dnssec. However, I got confused one more time as I looked on some of my SOA records. So, just for the record, here is an example how the serial numbers increase while the admin has not changed anything manually on the zone files.
Continue reading BIND Inline-Signing Serial Numbers Cruncher