Centralised DNSSEC validation on closed networks

31 October 2012

The Authentic Data (AD) flag is used by caching DNS servers to indicate that they have validated the DNSSEC records. The idea is that the client doesn't then have to repeat the check.

Use of the AD flag is, of course, safe only on a network where the security of the last mile is assured. Examples include company networks, campus networks and the closed networks belonging to internet access providers and mobile operators. On such networks, DNSSEC validation and DNS caching can be centralised on the recursive DNS servers.

What is the AD flag for?

The Authentic Data (AD) flag is used by (caching) DNS servers to indicate that they have validated the DNSSEC records. The idea is that the client doesn't then have to repeat the check. In its DNS query, the (stub) resolver asks for the DNSSEC records by setting the DO flag (DNSSEC OK) — with the dig network tool, you can do that by using the +dnssec option. When replying with the DNS records, the DNS server may add the AD flag. The DNS server is then effectively taking responsibility for both the caching and the validation.

However, when testing a validating DNS server, it's important to bear in mind that the DNSSEC specification (RFC 4035, subsection 3.1.6) states that authoritative servers don't have to undertake validation for their own domains. They are then allowed to set the AD flag, but only if they have obtained their authoritative records in a secure manner. That has to be separately configured.

The role of the AD flag has since been extended: whereas it was originally exclusively for DNS responses, it can now be used in DNS queries. According to subsection 5.7 of RFC 6840, it was previously recommended that the AD flag shouldn't be set in DNS queries. Now setting the AD flag in a DNS query yields information exclusively about the validation result (by means of the AD flag in the DNS response), and not about the DNSSEC records themselves. The dig network tool now supports AD flagging with its +adflag option. The DO flag is still used as before to request DNSSEC information.

When can you trust the AD flag?

Of course, the crypto-technical answer is 'never'! Because the pathway between the (stub) resolver and (caching) DNS server is generally not secure, the contents of a DNS response can always be modified by a man-in-the-middle attack undetected by the client. In principle, neither the record contents nor any of the meta-data (headers) can be trusted.

Various solutions are currently available for this so-called last-mile security problem:

  • DNS information exchange can be secured using TSIG (Transaction SIGnature). The TSIG protocol is often used for the exchange of DNS records between authoritative servers, and to secure Dynamic DNS updates from the DHCP servers to the DNS server. TSIG could also be used for communication between resolver and DNS server, but is not an obvious option in that context. The protocol is based on symmetrical cryptography, implying that a shared private key has to be exchanged between client and server.

  • By contrast, DNSCrypt uses asymmetrical cryptography, making it more suitable for last-mile security. DNSCrypt is used by the DNS service provider OpenDNS to encrypt traffic to and from its clients. The system is based on DNSCurve, developed by Daniel J. Bernstein (DJB), who has a reputation for fast and secure internet software. It was he who developed qmail and djbdns, for example. DNSCrypt is supported mainly by OpenDNS and is available for Windows, Linux, Mac OS X and iPhone.

  • DNSSIG is a rival to DNSCrypt. It is designed to maximise transparency by using TXT records.

  • In Secure Dynamic Update, Microsoft has developed a protocol for tunnelling DNS traffic. The system uses the GSS-API and a variant of Kerberos.

  • Finally, DNS-over-TLS is a much more logical option, since it is open. However, because of the overhead, it is just as inelegant for encrypting traffic between resolver and DNS server as Secure Dynamic Update.

Despite all the initiatives of the last ten years, it appears that none of the technologies outlined above will become established as the solution for last-mile security. Although combining DNSSEC validation with DNS record caching seems like an obvious (and efficient) thing to do, it truncates the cryptographically secured DNSSEC chain. Ideally, the chain should extend all the way from the root zone (.) to the client. Therefore, if validation is also performed on the caching DNS servers, a new technology is required for the last part of the chain to secure transmission of the AD flag.

Where can the AD flag be used?

The AD flag can be used on a network where the security of the last mile is assured. Examples include company networks, campus networks and the closed networks belonging to internet access providers and mobile operators. On such networks, DNSSEC validation and DNS caching can be centralised on the recursive DNS servers.

Comments

  • Monday 15 April 2019

    About SIDN

    "Together, we're going to create enormous added value"

    Thumb-Martijn-Kaag

    Interview with CEOs SIDN and Connectis

    Read more
  • Thursday 18 October 2018

    SIDN Labs

    A successful root KSK rollover: a brief look back

    Thumb-key

    Our findings

    Read more
  • Monday 27 May 2019

    Internet security

    Bits of Freedom makes privacy law work in practice

    Thumb-shredded-paper

    My Data Done Right: a new tool for generating personal data requests

    Read more

Sorry

Your browser is too old to optimally experience this website. Upgrade your browser to improve your experience.