DNS Workshop

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.

Name resolution in legacy hybrid DNS designs

The graphic below shows DNSSEC name resolution for a DNSSEC secured name from the Internet, using a hybrid DNS server:

The AD flag is seen by the client, and DNSSEC aware applications will continue to work.

The next graphic show name resolution for an internal DNS domain, which is also DNSSEC secured and hosted on the DNS server that is used for DNSSEC validation (a hybrid DNS server):

Here, only the AA-flag is seen by the client. DNSSEC aware applications that require the AD flag will fail.

Name resolution in modern DNS designs

In modern DNS designs, the resolving/caching DNS servers are separate from the authoritative DNS servers. As a rule of thumb, in these designs, caching/resolving DNS servers only receive DNS queries from client machines, never from other DNS servers (except for forwarding, where a DNS server acts like a client proxy). Authoritative servers only talk to caching/resolving DNS servers, never directly to DNS clients.

Resolving and validating names in the Internet works like in the hybrid design above:

AD-flag is seen by the client, everything is good and secure.

DNS queries for internal DNS domains now also will see the AD-flag:

DNSSEC aware applications work for all domains, internal and external.

Benefits from a modern DNS design

A modern DNS name resolution design is required to be able to make use of all features DNSSEC offers. The number of DNSSEC aware applications is likely to grow in the future, so more and more applications will rely on proper DNSSEC validation.

Besides DNSSEC, there are more benefits in a modern DNS name resolution design: the possibility to apply different security policy and settings to the caching and authoritative servers, better troubleshooting options, simpler maintenance and upgrade-ability of DNS server components among them.

Separating the resolving/caching and the authoritative functions of DNS servers does not necessarily require more hardware or more physical DNS servers. Virtualization can be used to create separate instances of DNS servers on the same machine. Either full machine virtualization (HyperV, VMWare, VirtualBox, XEN or KVM), system virtualization (Solaris zones or Linux Container/LXC) or even process virtualization (BIND 9 views) can be used.

Comments:

If the zone hosted on the caching name server is not signed (example.com), and the client send "query example.com +dnssec", what is the result ?

Posted by samer on July 04, 2012 at 07:59 AM CEST #

Hello samer,

if a DNS server with a zone that is not signed gets a request (for that zone) with the 'DO' flag set (DO = DNSSEC OK, the flag set by +DNSSEC), it just responds with a normal DNS answer (like DNS without DNSSEC). There will not be a AD flag, there will be no signatures to validate. It just treated as normal DNS.

Carsten

Posted by Carsten on July 05, 2012 at 08:40 AM CEST #

Hi Carsten, if i have a dnssec-unaware stub-resolver asking a dnssec-aware dns-server (do=0). Will the Server do an dnssec-query with validation and respond back with ad=1 (if configured) ?

Posted by mathias on May 26, 2013 at 07:04 PM CEST #

Hello Mathias,

If a validating resolver, that has a valid trust anchor configured,
receives a DNS query from a dnssec-unaware stub-resolver asking with
DO=0, it will

1) send a query to the authoritative server with DO=1
2) if DNSSEC information is returned, will validate the information
based on the trust anchor and the chain of trust
3) if the data is good (validated successfully), it will send the answer
data to the dnssec-unaware stub-resolver WITHOUT AD flag, as it could be
a legacy DNS resolver that does not know about the AD flag (and, in
worse case, could crash). The AD flag is only returned to the client
resolver if the query was send with DO=1
4) if the data is bogus (validation fails), the answer data is discarded
and a SERVFAIL error answer is returned to the client resolver.

This behavior will protect legacy dnssec-unaware stub-resolver from bad
DNS data, without the need that the client has DNSSEC capabilities.

Posted by Carsten on May 27, 2013 at 09:41 PM CEST #

I am using DNSSEC base response for validation for internal network

(1) How can i change default resolver to some other server and
verify that a nsloookup fails on the client?

(2) How can i revoke the DNSSEC certificate and verify that it
fails ?

(3) How can i expire the DNSSEC certificate and verify that it
fails ? Also, why we have a reliance on an external
root (div.isc.org)...since we are using this internally only?

(4) How can i verify that a valid, non-expired certificate from a
foreign domain properly fails ?

(5) if i will be using DNSEC for internal network, how can i
restrict client to accept data from response have proper key in
header ?

------------------

Hello Mudassir,

thanks for your questions regarding DNSSEC. I'll try to be brief with
my responses. Please let me know by E-Mail if you have additional
questions:

(1) How can i change default resolver to some other server and verify that a nsloookup fails on the client?

A: Changing the default resolver depends on the type of operating
system. In traditional Unix, this is done in the /etc/resolv.conf file
(however, some modern Linux/Unix variants use a different system). On
Windows, the default resolver is set in the TCP/IP settings. It it
possible that the default resolver is distributed by DHCP, then you
need to change the DHCP coniguration.

(2) How can i revoke the DNSSEC certificate and verify that it fails ?

A: DNSSEC is a PKI, but it works differently from a X509
certification based PKI. In DNSSEC, there are "keys"
and "signatures". It is possible to revoke a DNSSEC key, if the
key is compromised. Key revocation for DNSSEC is specified in RFC
5011 (https://tools.ietf.org/html/rfc5011), section
2.1 "Revokation". If you use the BIND DNS Server tools, you can
revoke a DNSSEC key using the "dnssec-revoke" command and publish
the DNSKEY record of that key with the revoke flag set to "1".

How to verify: If there is just one KSK DNSKEY in a zone, and that key has the revoke
flag set, a DNSSEC validating resolver with a trust anchor for that
zone should respond to DNS queries with "SERVFAIL".

(3) How can i expire the DNSSEC certificate and verify that it fails ?

A: There are no DNSSEC certificates. I guess you ask about DNSSEC
keys. DNSSEC keys do not expire, only DNSSEC signatures expire. DNSSEC
keys can only be revoked (see question and answer above)

DNSSEC signatures get a lifetime (start- and expiry time) when they
are created. It is not possible to change the start- and expiry time
without removing and re-create the signature.

(3a) Also, why we have a reliance on an external root (div.isc.org)...since
we are using this internally only?

No idea, I do not know your DNS design. If you do not need DLV, just
don't enable it.

(4) How can i verify that a valid, non-expired certificate from a
foreign domain properly fails ?

There are many tools available that can help:

* "drill" from ldns --> https://www.nlnetlabs.nl/projects/ldns/
* "unbound-host" from "unbound" --> http://unnbound.net
* DNSViz --> http://dnsviz.net/
* DNSSEC debugger --> http://dnssec-debugger.verisignlabs.com/

All these tools can verify/validate a DNSSEC trust-chain and can find
issues with a broken trust chain.

(5) if i will be using DNSEC for internal network, how can i restrict
client to accept data from response have proper key in header ?

You can make sure that all clients use your own DNSSEC enabled
caching resolver (caching DNS Server). For Windows 7 or 8, you
can configure the client to be a "DNSSEC aware, non-validating
stub-resolver". The client will then only talk to a trusted DNS
caching server (in it's own domain), and it will for all DNS zones
marked as "mandatory DNSSEC" will only accepts answers with the
AD-Flag (AD = authenticated data) set.

Posted by Mudassir on December 04, 2013 at 05:45 PM CET #

Post a Comment:
  • HTML Syntax: Allowed

Calendar

Feeds

Search

Links

Navigation