DNS Workshop

Sunday Dec 22, 2013

a local, augmented root-zone with DNSSEC

Sometimes I get this question in my DNSSEC training classes: "now DNSSEC seems to be a good technology, but the root-zone is controlled by the US government. Because of that, can we trust DNSSEC?".

My answer is not to mix technology (DNSSEC) with implementation (the DNS system of the Internet).

Both are separate. While I can understand that some people do not trust the organisations in control of the Internet DNS root-zone, I see no flaw in DNSSEC (at this moment).

One way to solve the trust issue with the Internet root-zone is to host your own root-zone for the Internet. Then you are in full control of that zone. Have that zone in your own network, or on your Laptop computer und use it for the starting.point of all DNSSEC validation (the trust anchor) for DNS.

Besides the trust question, there might be another reason to operate a local root-zone: some organisations have created an internal, private top-level domain (TLD)1. A local, dnssec-signed root-zone enables the operator to remove or add any delegations, while still being able to validate all DNSSEC signed data in the Internet, as well as data that is stored in their own private DNS namespace.

The following tutorial explains the steps required to generate a local augmented and DNSSEC signed root-zone. The tutorial requires some understanding of DNS concepts and basic knowledge on DNSSEC.

[Read More]

Wednesday Oct 31, 2012

Who is asking for 0.0.0.0.in-addr.arpa.?

This morning I experienced a steep increase in NXDOMAIN responses in my home network, just about the time that I started to install Windows 2012 for some DNS experiments. There were around 15 queries per minute from one source for a non-existing domain.

An increase of NXDOMAIN this morning

A closer look revealed that the NXDOMAIN responses where caused by queries for "0.0.0.0.in-addr.arpa.". This looked like a misbehaving software.

A closer look: the queries are for 0.0.0.0.in-addr.arpa.

However the originating IPv4 address that I could see sending the queries was non of my "well known" client- or server-systems.

The machine turned to be the iDRAC card in a Dell r200 server I

It turned out to be the remote management card (iDRAC) inside the Dell r200 server I'm installing Windows 2012 on (IPv4 address 192.168.1.169 is the iDRAC card, 192.168.1.2 my BIND 9 resolving DNS). Luckily, because I'm running a recent version of BIND 9, these queries were stopped by the "automatic empty zones" feature in the recursive DNS server and not send out to the Internet.

The automatic empty zones are defined in RFC 6303 - "Locally Served DNS Zones" and can be controlled using the "empty-zones-enable" statement in named.conf. If you have Dell servers with iDRAC cards that show the same behaviour than mine, and you use BIND 9.5.0+ with automatic empty zones, you are fine. Look at your BIND recursive server startup messages. If you see a similar list as shown below, all is fine:

BIND "empty zones" startup messages

31-Oct-2012 12:39:26.753 automatic empty zone: 10.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 16.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 17.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 18.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 19.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 20.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 21.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 22.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 23.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 24.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 25.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 26.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 27.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 28.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 29.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 30.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 31.172.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 168.192.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 0.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 127.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 254.169.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 2.0.192.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 100.51.198.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 113.0.203.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
31-Oct-2012 12:39:26.753 automatic empty zone: D.F.IP6.ARPA
31-Oct-2012 12:39:26.754 automatic empty zone: 8.E.F.IP6.ARPA
31-Oct-2012 12:39:26.754 automatic empty zone: 9.E.F.IP6.ARPA
31-Oct-2012 12:39:26.754 automatic empty zone: A.E.F.IP6.ARPA
31-Oct-2012 12:39:26.754 automatic empty zone: B.E.F.IP6.ARPA
31-Oct-2012 12:39:26.754 automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA

If you do not see this messages, it might be because your BIND version is quite old. Consider upgrading. If you are using a different DNS Server product, it is good practice to define empty DNS zones for the address blocks defined in RFC 6303. These zones only contain one SOA and one NS record (see below), they are "empty" and the only purpose is to stop internal traffic to leak from your internal networks to the Internet by serving the NXDOMAIN response locally.

Example "empty" zone-file

@ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
@ 10800 IN NS @

Saturday Jun 30, 2012

DNS Name Resolution Design for proper DNSSEC validation

Many networks have a DNS name resolution design that uses a hybrid DNS server. A hybrid DNS server is a DNS server that combines both functions that a DNS server can operate in into one process: the authoritative function (hosting zones) and the resolving/caching function (looking up names in DNS on behalf of DNS clients).

Both BIND and Microsoft Windows DNS server can operate in a hybrid mode. Other (some would say "more modern") DNS servers such as Unbound (resolving only) and NSD (caching only) separate these functions.

While running a hybrid DNS server was fine in the world before DNSSEC, the deployment of DNSSEC requires a closer look at these "legacy" DNS designs.

Authoritative DNS servers, when queried for a name they are authoritative for, will set the AA-flag (Authoritative Answer) in the answer.

Resolving DNS server that perform DNSSEC validation will set the AD-flag, if the DNS data received is validating. The AA-flag and the AD-flag are mutually exclusive, there can only be either one in an DNS answer. The reason is that it would be extra work, but no added security, if an authoritative DNS server would validate its own data. After all, if the server has been compromised, it cannot trust its own data and it is not possible to detect the false data from within the authoritative DNS server. Only a DNS server external to the authoritative server can validate DNSSEC signed zone data.

For proper DNSSEC name resolution (AD flag set on all answers from DNSSEC secured zones), all queries must go through a resolving DNS Server that is separate from the DNS server hosting the zones.[Read More]

Friday Dec 30, 2011

Take your DNSSEC with a grain of salt

DNSSEC has many useful properties. One is called 'Authenticated denial of existence'. This basically means that a DNSSEC validating DNS Server can prove that domain-names and resource records do not exist in the DNS.

But how does NSEC and NSEC3 work. And how to choose good values for NSEC3 salt and iterations?

[Read More]

Calendar

Feeds

Search

Links

Navigation