Ensuring that your DNS server is available is an important part of protecting your web service. If an attacker makes the DNS server unavailable, for most users it could mean that your site will be inaccessible or that the application accessing your domain is not working. Besides, information about the unavailability of the DNS server is usually stored for some time in the cache on the user's device or on the recursive DNS server they use, such as Google Public DNS or the recursive DNS server of the Internet service provider. Because of this, users may continue to have problems accessing your site even after the attack on the DNS server has stopped.
To protect against DNS attacks, you can use Qrator Labs secure DNS server. Below you will find the general principle of operation of this service and descriptions of the two possible modes of operation: secondary DNS server mode and proxy DNS server mode.
Instructions on how to connect the service can be found here: Connection: Secure DNS server.
Principle of operation
A DNS attack is usually in the form of a large number of simultaneous requests to it. The attacker expects that since the cost of processing a DNS request exceeds the cost of creating it, the attacked DNS server will either slow down significantly or stop processing requests from legitimate users altogether. Qrator Labs DNS servers can remain functional during attacks due to the high bandwidth of the Qrator Labs network where the servers are hosted.
When setting up the service for the first time, the customer specifies the Qrator Labs DNS server as the authoritative server for his DNS zone (see Connection: Secure DNS server). Thus, the user makes requests not to the customer's DNS server, but to one of Qrator Labs DNS servers. These servers translate the data received from the customer's DNS server in one of two ways:
- By transferring the DNS zone (see Secondary DNS server mode)
- By proxying DNS responses (see Proxy DNS server mode)
Warning
Regardless of the mode you choose, it is recommended to switch to Qrator Labs secure DNS server in advance, without waiting for a possible attack.
Changing the DNS server initiated during an attack often fails to quickly mitigate the damage since both users and recursive DNS servers keep trying to access the former DNS server until the cache lifetime expires.
Secondary DNS server mode
This mode uses the standard zone transfer mechanism, where the customer's DNS server is primary and Qrator Labs DNS server is secondary. The mechanisms of interaction between the primary and secondary DNS servers are described in RFCÂ 1996 and RFCÂ 5936.
The Qrator Labs DNS server queries the primary server for complete information about the zone, including the SOA (start of authority) record, and responds to user requests according to the information received.
By default, the primary server is contacted again after the period specified in the SOA record refresh field has elapsed. The primary server can also send a notify request to the Qrator Labs DNS server, in this case the Qrator Labs DNS server requests full zone information from the customer's DNS server immediately.
If the customer server is unavailable, the Qrator Labs DNS server continues to use data from the last successful update.
Proxy DNS server mode
In this mode, the customer and Qrator Labs DNS servers do not enter into a primary and secondary server relationship and communicate without authorization. Upon receiving a new request from the user, the proxying server redirects it to the customer server unchanged. If the customer server responds to the request, that response is redirected to the user and also stored in the cache.
The default cache expiration time for a negative response (response that no record was found) is 600 seconds (10 minutes), and for a positive response, the TTL is defined in the customer server response. During this time, all users who make exactly the same request to the Qrator Labs DNS server receive a response from the cache. After the TTL expires, the requests are redirected back to the customer server to refresh the cache. If the customer server is unavailable on the next update, the Qrator Labs DNS server continues to use data from the cache.
Thus, at normal times, the proxying Qrator Labs DNS server reduces the load on the customer DNS server by using the cache, and in contingencies does not allow any temporary unavailability of the customer DNS server to cause the negative cache to spread to other DNS servers.
When using this mode, there is no way to force the cache to refresh before the TTL expires.