Another great tool from Babak Farrokhi is dnstraceroute. It is part of the DNSDiag toolkit from which I already showed the dnsping feature. With dnstraceroute you can verify whether a DNS request is indeed answered by the correct DNS server destination or whether a man-in-the-middle has spoofed/hijacked the DNS reply. It works by using the traceroute trick by incrementing the TTL value within the IP header from 1 to 30.

Beside detecting malicious DNS spoofing attacks, it can also be used to verify security features such as DNS sinkholing. I am showing the usage as well as a test case for verifying a sinkhole feature.

The third tool out of the DNSDiag toolkit from Babak is dnseval. “dnseval is a bulk ping utility that sends an arbitrary DNS query to a given list of DNS servers. This script is meant for comparing response times of multiple DNS servers at once”. It is not only listing the response times but also further information about the DNS responses such as the TTL and the flags. Really great for comparison and troubleshooting different DNS forwarders as well as own authoritative DNS server responses as seen by others.

After the implementation of DNS and DNSSEC (see the last posts) it is good to do some reconnaissance attacks against the own DNS servers. Especially to see the NSEC or NSEC3 differences, i.e., whether zone walking (enumeration) is feasible or not.

For many different kinds of DNS reconnaissance the tool dnsreconcan be used. In this post I will focus on the
-z option which is used for DNSSEC zone walking, i.e., walk leaf by leaf of the whole DNS zone.

By default DNSSEC uses the next secure (NSEC) resource record “to provide authenticated denial of existence for DNS data”, RFC 4034. This feature creates a complete chain of all resource records of a complete zone. While it has its usage to prove that no entry exists between two other entries, it can be used to “walk” through a complete zone, known as zone enumeration. That is: an attacker can easily gather all information about a complete zone by just using the designed features of DNSSEC.

For this reason NSEC3 was introduced: It constructs a chain of hashed and not of plain text resource records (RFC 5155). With NSEC3 enabled it is not feasible anymore to enumerate the zone. The standard uses a hash function and adds the NSEC3PARAM resource record to the zone which provides some details such as the salt.

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:

This is really cool. After DNSSEC is used to sign a complete zone, SSH connections can be authenticated via checking the SSH fingerprint against the SSHFP resource record on the DNS server. With this way, administrators will never get the well-known “The authenticity of host ‘xyz’ can’t be established.” message again. Here we go:

DNS-based Authentication of Named Entities (DANE) is a great feature that uses the advantages of a DNSSEC signed zone in order to tell the client which TLS certificate he has to expect when connecting to a secure destination over HTTPS or SMTPS. Via a secure channel (DNSSEC) the client can request the public key of the server. This means, that a Man-in-the-Middle attack (MITM) with a spoofed certificate would be exposed directly, i.e., is not possible anymore. Furthermore, the trust to certificate authorities (CAs) is not needed anymore.

In this blog post I will show how to use DANE and its DNS records within an authoritative DNS server to provide enhanced security features for the public.

To solve the chicken-or-egg problem for DNSSEC from the other side, let’s use an authoritative DNS server (BIND) for signing DNS zones. This tutorial describes how to generate the keys and configure the “Berkeley Internet Name Domain” (BIND) server in order to automatically sign zones. I am not explaining many details of DNSSEC at all, but only the configuration and verification steps for a concrete BIND server.

It is really easy to tell BIND to do the inline signing. With this option enabled, the admin can still configure the static database for his zone files without any relation to DNSSEC. Everything with signing and maintaining is fully done by BIND without any user interaction. Great.

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 slaves 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.

I am using the DNS Proxy on a Palo Alto Networks firewall for some user subnets. Beside the default/primary DNS server it can be configured with proxy rules (sometimes called conditional forwarding) which I am using for reverse DNS lookups, i.e., PTR records, that are answered by a BIND DNS server. While it is easy and well-known to configure the legacy IP (IPv4) reverse records, the IPv6 ones are slightly more difficult. Fortunately there are some good tools on the Internet to help reversing IPv6 addresses.

While I tested the FQDN objects with a Palo Alto Networks firewall, I ran into some strange behaviours which I could not reproduce, but have documented them. I furthermore tested the usage of FQDN objects with more than 32 IP addresses, which are the maximum that are supported due to the official Palo Alto documentation. Here we go:

I initially stored my ownCloud data on an external NTFS hard disk. (Yes, this was not a good idea at all.) After some time now I wanted to move the files to a bigger ext4 drive on the same machine. Unluckily there are many posts and articles that are really irritating on the Internet, such as: 1, 2, 3, 4, 5. At least I found some promising hints at the official GitHub forums (this and that) and gave it a try: