Windows dns ttl best practice

Once the given time expires, such data should be deleted in favor of new data. The TTL is also used for expiring records, for example, we can use to set the date and time in which a certain record will expire. Due to how the Internet and DNS requests work, the TTL plays a very important role because it tells other DNS systems for how long they should keep a certain record stored as cache data. Using cached records is important to make the requests between servers a lot faster, which makes the Internet in general faster.

What does this mean? It means that after picking up a record for the first time, the DNS systems should keep it in cache for seconds that is one hour , destroy it after such time passes and then pick it up again, to make sure the record is up to date in case some of its data changes, or if the records are deleted.

Without the TTLs the DNS system would be different, as the records would always need to be checked in real time and it would create a lot of delays, thus making all Internet traffic a lot slower, which would affect load time for websites for example. In the case of records that need to often change, the best practice is to keep a low TTL, for example around seconds or so, depending on of course how often the records will change. If a TTL is too high and you need to make a change to a record but also need it to propagate as soon as possible, then you need to start working on it 24 hours before the real change.

Because DNS is such a critical protocol for Internet operations, countless operating systems, and applications, operators and administrators must harden DNS servers to prevent them from being used maliciously. Some of these flaws are presented in this document to inform operators how they can be used maliciously.

Techniques are shared that can be used to prevent these types of activities. Essentially, a DNS open resolver provides responses answers to queries questions from anyone asking a question. DNS open resolvers are vulnerable to multiple malicious activities, including the following:. Attackers use this exploitation technique to redirect users from legitimate sites to malicious sites or to inform the DNS resolver to use a malicious name server NS that is providing RR information used for malicious activities.

DNS amplification and reflection attacks use DNS open resolvers to increase the volume of attacks and to hide the true source of an attack, actions that typically result in a DoS or DDoS attack. These attacks are possible because the open resolver will respond to queries from anyone asking a question. Attackers use these DNS open resolvers for malicious activities by sending DNS messages to the open resolvers using a forged source IP address that is the target for the attack.

When the open resolvers receive the spoofed DNS query messages, they respond by sending DNS response messages to the target address. Attacks of these types use multiple DNS open resolvers so the effects on the target devices are magnified. Resource utilization attacks on DNS open resolvers consume resources on the device. Examples of such resources include CPU, memory, and socket buffers. These types of attacks try to consume all available resources to negatively impact operations of the open resolver.

The impact of these attacks may require the device to be rebooted or a service to be stopped and restarted. Multiple vendors have products that implement the DNS protocol and that can be configured as a DNS open resolver intentionally or unintentionally.

A configured open resolver exposed to the Internet allows anyone to send DNS queries to the resolver. The examples that follow are configurations for some vendor products that are broadly deployed throughout the Internet. These example configurations show how to prevent a DNS server from acting as an open resolver.

These configurations are applied in the 'named. Note: Recursion is enabled by default for Version 9. BIND also allows operators to define views that can use the following configuration methods for disabling recursion.

Views are not discussed in this document. Operators can use the 'allow-recursion-on' configuration option to select which addresses on the DNS server will accept recursive DNS queries. BIND also allows operators the ability to select which addresses on the DNS server will provide answers from the DNS cache using the 'allow-query-cache-on' configuration option. Operators may also configure BIND to only listen on specific interfaces using the 'listen-on' or 'listen-on-v6' options configuration.

For additional configuration options, consult the BIND 9. The following configurations can be applied to the DNS Server service to prevent the server from acting as an open resolver.

Using either of the previous configuration examples for the DNS Server service will disable recursion for all resolvers sending recursive DNS queries to the server. If recursion is disabled, operators will not be able to use DNS forwarders on that server. Microsoft provides additional information operators can use to harden the configuration of the DNS Server service. Note that this feature is enabled by default on Windows Service Pack 3 SP3 and Windows Server , and that using this feature will also produce more queries sent from the DNS server.

DNS implementations use the transaction ID along with the source port value to synchronize the responses to previously sent query messages. Flaws have been discovered in DNS where the implementations do not provide sufficient entropy in the randomization of DNS transaction IDs when issuing queries. If attackers are able to predict the next transaction ID used in the DNS query along with source port value, they can construct and send spoof DNS messages with the correct transaction ID.

Even though the DNS message sent by the attacker is falsified, the DNS resolver accepts the query response because the transaction ID and source port value match up with the query the resolver sent, resulting in the DNS resolvers cache being poisoned.

Note: The transaction ID field for the DNS protocol is only 16 bits in length, so this value can range from 0 through Once the bits have been depleted from the entropy pool, a new pool will be created containing random bits.

DNS uses both the source port value and transaction ID for tracking queries and the responses to queries. Flaws have been discovered in DNS where the implementations do not provide sufficient entropy in the randomization of the UDP source port when issuing queries.

Malicious users can analyze the source port values generated by the DNS implementation to create an algorithm that can be used to predict the next UDP source port value used for a query message. Note: The source port field for the UDP protocol is only 16 bits in length, so this value can range from 0 through To use these configurations, apply them to the options section in the 'named. When a DNS resolver sends a query asking for information, an authoritative or a non-authoritative server may respond with a DNS query response message and the relevant resource record RR data or an error.

By using a short TTL value, malicious users can leverage DNS to distribute information about a large number of devices hosting malicious code or being used for malicious activities to DNS resolvers. The hostname to IP address mapping for devices in the requested domain name space will rapidly change usually anywhere from several seconds to a few minutes. This is known as a Fast-Flux FF network. This malicious technique makes it difficult for operators to use traceback methods and identify compromised hosts participating in the Fast-Flux network.

Another potentially malicious use of a short TTL is using a value of 0. This value informs the DNS resolver that the RR information received in the DNS query response message should not be stored in the cache of the resolver. Attackers can also use long TTL values for RRs so that DNS resolvers will cache the information received in the query response message for an extended period of time. This technique can be used for storing malicious RR information in the cache of a resolver for an extended period of time.

If the resolver is a recursive or open resolver, then it can distribute the RRs for the malicious host to many resolver clients, thus allowing use for malicious activities.

This method differs from the Fast-Flux technique that uses a short TTL value and operators are able to use traceback techniques to more easily identify malicious hosts distributing this information.

Authoritative and recursive resolvers have different primary functions. A recursive resolver recursively walks through the DNS architecture and locates the authoritative DNS server for the information in the DNS query question asked , then distributes an answer or error for that information using a DNS query response message to the resolver who asked the question. Because the functions of these resolvers are used for different purposes, the resolvers should be segregated.

Authoratative and recursive resolver functions should be segregated because authoritative DNS servers primarily distribute information about hosts accessible via the Internet and they are also accessible via the Internet for distributing this information. What is too short and what is too long? How would you determine what is the appropriate value to set? Well, there are two different approaches.

If I know there are DNS changes for a server, website, etc. IT Professionals of Florida, Inc. Definitely short at least until you know everything is working correctly. For internal DNS make it short. For external DNS make it as short as you can afford. Look at the values in the SOA record and understand their meaning and whether the answers are in the cache or have to be asked again. Also on the far end, if your authoritative server goes offline and stays offline, when does it's answer stop being authoritative.

To continue this discussion, please ask a new question.