8 Reasons Why You Need a Professional DNS Audit
The importance of DNS to your overall web presence cannot be overstated. If your DNS were to be compromised or taken offline, it would wipe out your website, email, apps, and potentially other services which could lead to lost revenues and poor brand perception. DNS is the lifeline of your digital existence.
But since budgets are being stretched beyond usefulness, many organizations are using a piecemeal approach to enhancing their DNS – if they’re even paying attention to it at all. Employing a “set it and forget it” approach to DNS is like closing the door to a vault, but not ensuring it’s actually locked. And as cyber criminals continue to innovate new ways to attack and threaten businesses, vulnerable DNS equates to low hanging fruit.
So what should companies do when everything’s a priority and time is limited?
Conduct a DNS audit
Chris Roosenraad, Director of DNS Services at Neustar, shares some of the most common errors that Neustar has observed during audits of its customer’s DNS infrastructure and offers best practices you can take to ensure that you are maximizing your DNS performance to minimize potential downtime.
1. Zone Delegation Issues
The single biggest issue found during DNS audits has to do with zone delegation. If the zones are not set up correctly, then the DNS queries are misdirected, and cannot correctly resolve. 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.
2. Incorrect Sender Policy Framework Configuration
Sender Policy Framework (SPF) is an email verification system that prevents spoofing. But if SPF is misconfigured, then email can be spoofed from your domain, crippling any digital communication methods that you once used. 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, such as http://www.kitterman.com/spf
3. Records Pointing to Inactive Domain Names
There are a number of record types (CNAME, MX, NS, PTR and SRV) that point to other domain names. But 10 to 25 percent of these records point to domains 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.
4. Negative Caching Errors
As you might have guessed, a negative cache is a cache entry that contains a negative response, resulting in a failure or slow responses - even once the cause has been fixed. If a negative caching interval is too short, it can lead to multiple queries for records that don’t exist. But if it’s 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 Time to Live (TTL) field value in the SOA record. Another option, in the case of some records, is to configure records for most commonly requested undefined records.
5. Improper Time to Live Configuration
TTL configuration errors are similar to negative caching errors in that 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.
6. 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.
7. Internal IP Addresses in External Zones
Usually, external DNS zones 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.
8. 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 e-commerce, 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.
Need help setting up your professional DNS audit? Give us a call at 1-855-898-0036, or learn more by visiting our professional services website to get started.