Dynamic DNS (DDNS) actually is independent of DNSSEC. DDNS provides a mechanism other than editing the zone file or zone database, to edit DNS data. Most clients and DNS servers have the capability to handle dynamic updates, and DDNS can also be integrated as part of your DHCP environment.
When you have both DNSSEC and dynamic updates in your environment, updating zone data works the same way as with traditional (insecure) DNS: you can use rndc freeze before editing the zone file, and rndc thaw when you have finished editing, or you could use the command nsupdate to add, edit, or remove records like this:
$ nsupdate
> server 192.168.1.13
> update add xyz.example.com. 300 IN A 1.1.1.1
> send
> quitThe examples provided in this guide will make named automatically re-sign the zone whenever its content has changed. If you decide to sign your own zone file manually, you will need to remember to executed the dnssec-signzone whenever your zone file has been updated.
As far as system resources and performance is concerned, be mindful that when you have a DNSSEC zone that changes frequently, every time the zone changes, your system is executing a series of cryptographic operations to (re)generate signatures and NSEC or NSEC3 records.
ISC introduces the "inline-signing" option with the release of BIND 9.9, which allows named to sign zones completely transparently. named does this by automatically creating an internal version of the zone that is signed on the fly, and only the signed version of the zone is presented to queries. The unsigned version of the zone file is untouched on the file system, but not served.
This features simplifies DNSSEC deployment, below are two common scenarios of how this feature can be used:
For more details and configuration examples on Inline Signing, please see the section called “Inline Signing Recipes”.
DNSSEC Look-aside Validation (DLV) is an extension to the DNSSEC protocol. It was designed to assist in early DNSSEC adoption by simplifying the configuration of recursive servers and lessen the burden of key management for the administrators. Without DLV, in the absence of a fully signed path from root to a zone, administrators wishing to enable DNSSEC validation would have to configure and maintain multiple trust anchors or managed keys in their configuration.
DLV removes the need for manual key management by identifying a trusted repository through which those keys can be securely retrieved by the validating resolver when it needs them. Basically, someone else (in this case, ISC) is performing the tedious task of trust anchor management, and your validating resolver just needs to trust that that someone else is doing a good job maintaining these trust anchors for you.
To enable DLV on your validating resolver, place this line in your configuration file and reload named:
dnssec-lookaside auto;
DNSSEC deployment has matured to a stage where most top level domains are signed and more and more registrars are DNSSEC-ready. If you are currently relying on DLV service provided by ISC, be aware that the service will not be available forever. ISC stopped accepting new zones into the DLV registry in July 2016 and plans to discontinue the DLV service in early 2017.
Before we discuss DNSSEC on private networks, let's clarify what we mean by private networks. In this section, private networks really refers to a private or internal DNS view. Most DNS products offer the ability to have different version of DNS answers, depending on the origin of the query. This feature is often called DNS views or split DNS, and is most commonly implemented as an "internal" versus an "external" setup.
For instance, your organization may have a version of
example.com that is offered to the world, and its names
most likely resolves to publicly reachable IP addresses. You may also
have an internal version of example.com that is only
accessible when you are on the company's private networks or via a VPN
connection. These private networks typical fall under 10.0.0.0/8,
172.16.0.0.0/12, or 192.168.0.0.0/16 for IPv4.
So what if you want to offer DNSSEC for your internal version of
example.com? This is actually a more involving question,
and we can only cover this topic briefly in this document.
Deploying DNSSEC in this context is possible. Because private networks are usually trusted, there may be less need to worry about someone hijacking your DNS traffic. This is commonly known as the "last mile" in DNS delivery. If you wish to deploy DNSSEC on your private networks, here are some scenarios to consider:
If your name server is configured as both the validating resolver and
the internal authoritative server, the answers returned to your clients
will not be validated at all. This is because the answer is coming directly
from the authoritative server, thus the Authoritative Answer
(aa) bit is set and, by definition, it is not validated. What
this means is, to a regular client making the query, the secure
authoritative answer looks exactly the same as the insecure authoritative
answer.
It is technically possible to achieve validation and authoritative serving within a single instance of BIND by using separate views for each, however the details of doing so are outside the scope of this document. There is a good example of this technique for serving a locally validatable copy of the root zone in Appendix A of RFC 7706.
If you have two name server instances running, one acting
as the validating resolver, and one acting as the internal
authoritative name server, it is possible to actually validate
answers, provided that you have installed the trust anchor(s)
necessary for your internal zones on the validating resolver.
In this setup, the client gets back the Authenticated Data
(ad) bit when querying against the validating
resolver. If no trust anchors are installed, your validating
resolver will go out to root, and attempt to validate internal
answers against external authorities (and fail).
DNSSEC is designed to protect the communication between the client and the nameserver, however there are few applications or stub resolver libraries that take advantage of this. DNSSEC can help with last mile security in a managed environment, by deploying validating resolvers (such as BIND) on client machines.
In addition, early efforts have concentrated on getting DNSSEC deployed between authoritative servers and recursive servers as that is a prerequisite for working DNSSEC between the recursive server and the application. These efforts also provide a degree of protection for applications that are not DNSSEC-aware.
With your DNS infrastructure now secured with DNSSEC, information can now be stored in DNS and its integrity and authenticity can be proved. One of the new features that takes advantage of this is the DNS-Based Authentication of Named Entities, or DANE. Below is a list of features currently being developed and tested by the DANE community:
DANE is an exciting area for DNS administrators. If you would like to learn more about the standards being proposed or new features being discussed, check out the DANE working group: https://datatracker.ietf.org/wg/dane/charter/. You can also check out the section called “Self-signed Certificate Recipe”.
Gab
Twitter