The most common errors identified in professional DNS audits

A DNS outage can be incredibly damaging to companies.

3 auditors

Going down?

Recent DNS outages should serve as a wake-up call that DNS is critical to business infrastructure. When your DNS infrastructure goes down, so does your web site, email, and other services, which may result in lost revenue and a negative brand perception. Many organizations are challenged by the cost and complexity of managing a DNS infrastructure because best practices may change over time, resulting in errors and inefficiencies. Chris Roosenraad, director of DNS Services at Neustar, shares some of the most common errors observed during audits of its customer’s DNS infrastructure and the best practices you can take to ensure you are maximizing your DNS performance to minimize potential downtime.


DNS audits
Globalite (Creative Commons BY or BY-SA)

Zone Delegation Issues

The single biggest issue found during DNS audits is problems with zone delegation, which arise when zones are not properly delegated properly, resulting in DNS queries that do not resolve because they don’t go anywhere or are misdirected. Preventing zone delegation issues requires the organization to review the name servers for each domain and ensure they are correct for where the domain is hosted.

DNS audits

Incorrect Sender Policy Framework (SPF) configuration

Sender Policy Framework is an email verification system that prevents spoofing, but if it is misconfigured then email can be spoofed from your domain. Common misconfiguration errors include invalid syntax or incorrect use of multiple strings. Other than zone delegation issues, SPF errors are the most common issues found in DNS audits. Whenever an SPF record is created or modified, it should be validated through a validation site.


DNS audits

Records pointing to inactive domain names

There are many record types that point to other domain names. These records include CNAME, MX, NS, PTR and SRV, but 10 to 25 percent of these records point to names that don’t resolve. The most common cause of these errors is a typo in the record or changing the name of a server, but not the records that point to it. The best practice to prevent these errors is to thoroughly check that each name a record points to exists and can be resolved.


DNS audits

Negative caching errors

A negative cache is a cache entry that contains a negative response, resulting in failures or slow responses, even once the cause has been fixed. If a negative caching interval is too short, it can result in multiple queries for records that don’t exist, but if it is too long it can delay adding new records because the cache delays the discovery of the new record. The best practice is to set a reasonable caching interval, which may vary by use case, but is generally suggested as one hour. This is controlled via the Minimum TTL (Time To Live) field value in the SOA record. Another option, in the case of some records, is to configure records for most commonly requested undefined records.


DNS audits

Improper Time to Live (TTL) Configuration

TTL configuration errors are like negative caching errors; negative caching sets how long a record cannot exist, while TTL sets how long a record can exist. If TTL is mistakenly set to 0, it may not resolve, if it is too short it may result in excessive queries and increased load, and if it is too long it may be difficult to change records in the case of an error. Again the best practice is to set a reasonable interval, generally suggested as one hour, which may greatly reduce DNS infrastructure load.


DNS audits

Misconfigured Pointer (PTR) Records

Pointer or PTR Records format an IP address in reverse order. They are commonly referred to as Reverse lookups because instead of using the hostname to find the IP, you use the IP to find the hostname. There is rarely any reason for a PTR record to exist anywhere outside a reverse zone, but it is surprisingly common to find them configured in forward zones. Another error is to find PTR records that don’t reverse the order of the octets in the address. To prevent these errors, test PTR record look-ups to make sure they get the right answer.


Internal IP Addresses in External Zones

External DNS zones usually should not contain internal addresses, but it is very common to find “RFC 1918” addresses (non-routable addresses for local use only), loopback address and addresses from other restricted ranges, such as “for documentation only” addresses. These are critical errors because they expose internal infrastructure information. The best practice is to separate internal and external DNS and to make sure internal records do not exist in external zones.


DNS audits
Glenn Fawcett/USCBP

Insufficient failover protection/Lack of secondary provider

Properly configured DNS zones are only useful if the resolvers are actually accessible and answer. A DNS service outage can cause massive business disruption, negatively impacting customers and employees. Critical zones, such as ecommerce, should employ failover protection through the redundant backup of a secondary independent DNS provider, so that if one goes down, the other will keep your domain online.

RELATED: How can good guys take advantage of DNS

Copyright © 2017 IDG Communications, Inc.

Related Slideshows