Skip to main content

Security Best Practices: DNSSEC Validation

Dnssec 765x333 21jun16 en

I would like to share some key points about the significance of the security technology Domain Name System Security Extensions (DNSSEC) and some important updates that will be implemented in the coming year. These points are extracted from my recent presentation at the Africa Internet Summit 2016 (AIS'16) in Gaborone, Botswana.

The DNS is a question-and-answer system, and anyone who relies on looking up services on the Internet relies on DNS responses. However, unsecured DNS responses can be forgeries that can redirect traffic destined for trusted services to malicious sites. For example, attempts to access bank account information may result in redirection to a site that will steal user identification and passwords, and even possibly install malware on a victim's computer.

Internet users can be protected from attacks like this by deploying DNSSEC, which is comprised of two main functions – signing and validating. In this post, I want to focus on validation, which is a security enhancement of the DNS protocol that checks received answers for authenticity and completeness.

Since most Internet users trust and rely on their network service providers, enabling DNSSEC validation typically occurs on the infrastructure of that provider. Internet or connectivity service providers should enable DNSSEC validation on the DNS resolvers they operate. DNSSEC validation reduces the risk of attackers using the DNS to redirect the service provider’s customers to compromised sites. While these attacks are relatively rare, they may become more common as vulnerabilities are addressed that allow easier types of attacks.

Beyond protecting the network service provider’s infrastructure, turning on DNSSEC validation provides a mechanism by which data stored in the DNS can be more fully trusted. This capability creates a new infrastructure upon which more secure services can be built.

Configuring DNS servers to perform the validation is relatively simple, and the operation of the validating resolver remains the same as that of a non-validating resolver. Some ongoing maintenance is required; operators of the validating resolvers must ensure that the configuration of the trust anchor for the DNS root zone is kept up to date. This process can also be automated.

The trust anchor corresponds to the cryptographic public key that is part of the Root Zone Key Signing Key (KSK). This key will be changing in 2017. To ensure that the community is aware of these changes, we created a resource page “Root Zone KSK Rollover” that includes details about the changes, how community members can get involved and links to additional resources.

We are encouraged by the increasing number of organizations that are adopting DNSSEC validation. It is a minimal investment that creates a far more secure and capable DNS infrastructure.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."