Category Archives: DNS/DNSSEC

DNSSEC Signing w/ BIND

Crypto, DNS/DNSSEC, Linux, Tutorial/Howto, , , , , , , , ,

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.

Continue reading DNSSEC Signing w/ BIND →

DNSSEC Validation with Unbound on a Raspberry

DNS/DNSSEC, Raspberry Pi, Tutorial/Howto, , , , ,

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:

Continue reading DNSSEC Validation with Unbound on a Raspberry →

BIND DNSSEC Validation

DNS/DNSSEC, Tutorial/Howto, ,

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.

Continue reading BIND DNSSEC Validation →

Basic BIND Installation

DNS/DNSSEC, Linux, Tutorial/Howto, , , , , , , , ,

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

Continue reading Basic BIND Installation →

Palo Alto DNS Proxy Rule for Reverse DNS

DNS/DNSSEC, Palo Alto Networks, , , , , , ,

I am using the DNS Proxy on a Palo Alto Networks firewall for some user subnets. Besides the default/primary DNS server, it can be configured with proxy rules (also 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.

Continue reading Palo Alto DNS Proxy Rule for Reverse DNS →

Palo Alto FQDN Objects

DNS/DNSSEC, Palo Alto Networks, , ,

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:

Continue reading Palo Alto FQDN Objects →

Advanced Ping: httping, dnsping, smtpping

DNS/DNSSEC, Mail, Memorandum, Ping/Traceroute, , , , , , , , , , , , , , , ,

I really love ping! It is easy to use and directly reveals whether the network works or not. Refer to Why Ping is no Security Flaw! (But your Friend) and Advanced Tracerouting. At least outgoing pings (from trust to untrust) should be allowed without any security concerns. However, many companies are denying these ICMP echo-requests from untrust into the DMZ which makes it difficult to test whether all servers are up and running.

I was sitting at the customer’s site replacing the DMZ firewall. Of course I wanted to know (from the outside) whether all servers are connected correctly (NAT) and whether the firewall permits the connections (policy). However, ping was not allowed. Therefore I used several layer 7 ping tools that generate HTTP, DNS, or SMTP sessions (instead of ICMP echo-requests) and revealed whether the services (and not only the servers) were running. Great!

This post shows the installation and usage of httping, dnsping, and smtpping on a Linux machine, in my case a Ubuntu server 14.04.4 LTS, as well as some Wireshark screenshots from captured sessions. Finally, a pcap file can be downloaded that shows the sample runs of all three tools.

Continue reading Advanced Ping: httping, dnsping, smtpping →

IPv6 Dyn Prefix Problems

Design/Policy, DNS/DNSSEC, IPv6, , , , , , , , , ,

I am lucky to have a full dual-stack ISP connection at home. However, the ISP only offers a dynamic IPv6 prefix with all of its disadvantages (while no single advantage). In this post, I am summarizing the limitations of a dynamic prefix and some of the ideas on how to overcome them. I am always comparing the “IPv6 dynamic prefix” state with the legacy “dynamic IPv4 address” situation. I suppose that some of these problems will hit many small office / home office locations during the next years.

Of course, IPv6 ISP connections with dynamic prefixes should only be purchased at private home sites. It is no problem to have new IPv6 addresses there because all connections are outbound. However, many small remote offices (SOHO) might rely on such cheap ISP connections, too. If they provide some servers in a DMZ or other components such as network cameras, building components with IPv6 connections, etc., they will run into these kind of problems. (The remote office could even tunnel every outbound IPv6 traffic through a VPN to the headquarter. But if it wants to use a local breakout, this won’t be an alternative.)

Continue reading IPv6 Dyn Prefix Problems →

Palo Alto: DNS Proxy for Management Services

DNS/DNSSEC, Palo Alto Networks, , , ,

The Palo Alto firewall has a feature called DNS Proxy. Normally it is used for data plane interfaces so that clients can use the interfaces of the Palo for its recursive DNS server. Furthermore, this DNS Proxy Object can be used for the DNS services of the management plane, specified under Device -> Setup -> Services. However, there was a bug in PAN-OS that did not process the proxy rules and static entries when a DNS proxy object was used in the management plane. This bug was fixed in PAN-OS 6.0.0. I tested it in my lab with PAN-OS 6.1.0 running. Here are the successful results.

Continue reading Palo Alto: DNS Proxy for Management Services →

Idea: IPv6 Dynamic Prefix

DNS/DNSSEC, Future Work, Internet Access, IPv6, , , , ,

For dynamic IPv4 addresses, dynamic DNS services such as Dyn or No-IP are well-known. If an ISP issues a single dynamic IPv4 address every 24 hours (or the like), the router or any other device registers the IPv4 address for a DNS record. With port-forwardings on the router, several services on different clients can be accessed.

Since there are some ISPs that offer dynamic IPv6 prefixes as well, I have a suggestion on how to optimize the “dynamic DNS” service for several IPv6 addresses and names. The main idea is to update only the IPv6 prefix, while the host IDs are statically configured on the DNS server. This limits the DNS updates and expands the usage of DNS names even for devices that have no “DynDNS update client” built-in.

Continue reading Idea: IPv6 Dynamic Prefix →

If only one DNS query is malicious …

DNS/DNSSEC, Palo Alto Networks, Security, , , ,

… the whole Internet breaks down. So happened on a Palo Alto with a DNS proxy and a (slightly misconfigured) anti-spyware profile.

All network clients had a single DNS server configured, namely the DNS proxy of the Palo Alto. And as a single network client requested an URL that was classified as “spyware”, the Palo correctly (!) blocked the DNS session from its DNS proxy to the Internet. Unluckily, this session stayed active for a long time (with drop-all-packets) since many DNS requests were traversing through it. But since it stayed blocked, the Internet was “unavailable” for all end-users.

Continue reading If only one DNS query is malicious … →