Just a quick glance at the domain_analyzer script from Sebastián García and Verónica Valeros. “Domain analyzer is a security analysis tool which automatically discovers and reports information about the given domain. Its main purpose is to analyze domains in an unattended way.” Nice one. If you’re running your own DNS servers you should check e.g. whether your firewall rules are correct (scanned with Nmap) or whether you’re not allowing zone transfer, etc.
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.
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.
Haha, do you like acronyms as much as I do? This article is about the feature from Palo Alto Networks’ Next-Generation Firewall for Internet Protocol version 6 Neighbor Discovery Protocol Router Advertisements with Recursive Domain Name System Server and Domain Name System Search List options. ;) I am showing how to use it and how Windows and Linux react on it.
While preparing for my CCNP SWITCH exam I built a laboratory with 4 switches, 3 routers and 2 workstations in order to test almost all layer 2/3 protocols that are related to network management traffic. And because “PCAP or it didn’t happen” I captured 22 of these protocols to further investigate them with Wireshark. Oh oh, I remember the good old times where I merely used unmanaged layer 2 switches. ;)
In this blogpost I am publishing the captured pcap file with all of these 22 protocols. I am further listing 46 CHALLENGES as an exercise for the reader. Feel free to download the pcap and to test your protocol skills with Wireshark! Use the comment section below for posting your answers.
Of course I am running my lab fully dual-stacked, i.e., with IPv6 and legacy IP. On some switches the SDM template must be changed to be IPv6 capable such as sdm prefer dual-ipv4-and-ipv6 default .
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.
The usage of the SSHFP resource record helps admins to authenticate the SSH server before they are exposing their credentials or before a man-in-the-middle attack occurs. This is only one great extension of DNSSEC (beside DANE whose TLSA records can be used to authenticate HTTPS/SMTPS servers).
While there are some great online tools for checking the mere DNS (1, 2), the correct DNSSEC signing (3, 4), or the placement of TLSA resource records for DANE (5, 6, 7), I have not found an online SSHFP validator. That’s the idea:
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 dnsrecon can 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.
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:
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.
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.