DNS of your domain: problem and protection
In the good old days, our project was repeatedly subjected to DDoS attacks of different types, of different power and duration. We have worked out many different methods of protection, as well as optimized the very structure of the service, partly in the aspect of hosting and the location of servers. An important part of a learned lesson was the correct DNS setting. As shown by the latest attack on Habr and comments about problems similar to ours, not everyone pays enough attention to protecting the DNS, but is very, very vain.
Let's start to understand what could be the wrong DNS setup for us in case of problems.
')
1. “Lived happily ever after” is not about records in the DNS zone. This is the first thing that causes a problem with an emergency IP change (and not an emergency one either). Those times have long passed when customers ignored low ttl and simply did not allow using ttl below a certain value. Now it’s quite normal to use a recording lifetime of 5-10 minutes. Yes, this is expressed in additional traffic, but you must admit that it is insignificant against the background of normal traffic generated by the subsequent http request.
This is the most intuitive point. In the event of an attack, you get the opportunity to quickly switch to other servers (if the attack is on a specific IP). This will also help to quickly disable the fallen node when using round-robin .
In the event of an attack on a specific IP, we begin to play cat and mouse with the attacker, and the occupation is, frankly, ungrateful and most often useless. First of all, you need to have enough IP pool in order to transfer the site from one to another, sending the old one just nowhere. Secondly, an attacker will simply get bored and he will solve the problem at once - your name servers will be attacked, which are responsible for resolving the domain.
2. Do you host NS on the same server (s) as the site itself? Then problems come to you. By attacking your server, the attacker gets a double benefit: both the site is laid down and the clients have blocked access to updated information about the zone. Thus, even with a ttl of 60, the site will still remain inaccessible if you switch to the backup IP, because this information cannot be obtained. Keeping the site and the name server on the same site is detrimental and this will immediately show itself from the worst side at the first problem.
3. DNS hosting will not save the father of Russian democracy! More precisely, not every DNS hosting. Even using external, paid or free DNS hosting services, you do not protect yourself 100%. If this service is located on 2, 3 or even 4 geographically remote servers, which supposedly should guarantee 100% reliability, in fact, 4 servers with a 10 mbps unlim channel do not guarantee anything. They are successfully clogged with a small botnet, which is much cheaper for an attacker (customer) than to attack your super-secure site with a gigabit channel and already established protection schemes. When using a DNS hosting service, it is important to make sure that the service provider itself has sufficient protection, because it will lie - you will lie down, and this is already thinking much less than about the first paragraph.
As a bonus, we offer a table with tariffs for DNS hosting, which we managed to sketch on the results of issuing the first page of Google.
As we can see, a low ttl with a large attendance will cost us a lot of money on all services except dnsmadeeasy, because of the extremely low number of requests allowed by the tariff. Many services do not allow to use too low ttl, in particular - free ones. The solution from dyndns, described in the last line, seemed quite good, but expensive.
In the table there is no indicator of "protection" of the service, since this issue requires a more detailed study of each individual service. It is important to understand that quality service will cost you a lot of money. But if you are ready to invest in the infrastructure for your resource, then along with the cost of hosting, do not forget to pay a lot of money for the reliability of the name servers, which are the first step in visiting your resource. It's worth it.
Let's sum up:
- ttl is better to put logical, in fact, it is individual for each resource. Too high is dangerous, and too low is expensive.
- name servers are better to use external ones and not exactly located on the same site as the site
- protect the name servers at least as much as the site and take the choice of DNS hosting at least as seriously as hosting the site.
In addition to the recommendations written above, you can also discuss such wonderful features of competent work with DNS as round-robin, load-balancing and even DNS-firewall, which can make the life of many administrators easier and more fabulous, but this is a topic for a separate article.
Let's start to understand what could be the wrong DNS setup for us in case of problems.
')
1. “Lived happily ever after” is not about records in the DNS zone. This is the first thing that causes a problem with an emergency IP change (and not an emergency one either). Those times have long passed when customers ignored low ttl and simply did not allow using ttl below a certain value. Now it’s quite normal to use a recording lifetime of 5-10 minutes. Yes, this is expressed in additional traffic, but you must admit that it is insignificant against the background of normal traffic generated by the subsequent http request.
This is the most intuitive point. In the event of an attack, you get the opportunity to quickly switch to other servers (if the attack is on a specific IP). This will also help to quickly disable the fallen node when using round-robin .
In the event of an attack on a specific IP, we begin to play cat and mouse with the attacker, and the occupation is, frankly, ungrateful and most often useless. First of all, you need to have enough IP pool in order to transfer the site from one to another, sending the old one just nowhere. Secondly, an attacker will simply get bored and he will solve the problem at once - your name servers will be attacked, which are responsible for resolving the domain.
2. Do you host NS on the same server (s) as the site itself? Then problems come to you. By attacking your server, the attacker gets a double benefit: both the site is laid down and the clients have blocked access to updated information about the zone. Thus, even with a ttl of 60, the site will still remain inaccessible if you switch to the backup IP, because this information cannot be obtained. Keeping the site and the name server on the same site is detrimental and this will immediately show itself from the worst side at the first problem.
3. DNS hosting will not save the father of Russian democracy! More precisely, not every DNS hosting. Even using external, paid or free DNS hosting services, you do not protect yourself 100%. If this service is located on 2, 3 or even 4 geographically remote servers, which supposedly should guarantee 100% reliability, in fact, 4 servers with a 10 mbps unlim channel do not guarantee anything. They are successfully clogged with a small botnet, which is much cheaper for an attacker (customer) than to attack your super-secure site with a gigabit channel and already established protection schemes. When using a DNS hosting service, it is important to make sure that the service provider itself has sufficient protection, because it will lie - you will lie down, and this is already thinking much less than about the first paragraph.
As a bonus, we offer a table with tariffs for DNS hosting, which we managed to sketch on the results of issuing the first page of Google.
| provider | # of domains | # of records | # of queries | minimum ttl | cost / month | cost / year |
| neustar | ten | 1,000 | 100,000 | 50 | ||
| neustar | 100 | 5,000 | 250,000 | 110 | ||
| neustar | 100 | 5,000 | 400,000 | 160 | ||
| zonomi | one | ten | 0 | 0 | ||
| zonomi | ten | 100 | ten | |||
| zonomi | 15 | 150 | ten | |||
| dnsmax | 25 | 20,000 | 300 | 3 | 36 | |
| dnsmax | 100 | 50,000 | 60 | 12 | 144 | |
| dnsmax | 500 | 100,000 | one | 25 | 300 | |
| dyndns | 75 | 600,000 | thirty | |||
| dyndns smb | ten | 100 | 600,000 | thirty | ||
| dyndns smb | 25 | 250 | 600,000 | 60 | ||
| dyndns (custom) | > 195 | |||||
| dnsmadeeasy | ten | 400 | 5,000,000 | thirty | ||
| dnsmadeeasy | 25 | 1,000 | 10,000,000 | 60 | ||
| dnsmadeeasy | 50 | 2,000 | 50,000,000 | 150 |
As we can see, a low ttl with a large attendance will cost us a lot of money on all services except dnsmadeeasy, because of the extremely low number of requests allowed by the tariff. Many services do not allow to use too low ttl, in particular - free ones. The solution from dyndns, described in the last line, seemed quite good, but expensive.
In the table there is no indicator of "protection" of the service, since this issue requires a more detailed study of each individual service. It is important to understand that quality service will cost you a lot of money. But if you are ready to invest in the infrastructure for your resource, then along with the cost of hosting, do not forget to pay a lot of money for the reliability of the name servers, which are the first step in visiting your resource. It's worth it.
Let's sum up:
- ttl is better to put logical, in fact, it is individual for each resource. Too high is dangerous, and too low is expensive.
- name servers are better to use external ones and not exactly located on the same site as the site
- protect the name servers at least as much as the site and take the choice of DNS hosting at least as seriously as hosting the site.
In addition to the recommendations written above, you can also discuss such wonderful features of competent work with DNS as round-robin, load-balancing and even DNS-firewall, which can make the life of many administrators easier and more fabulous, but this is a topic for a separate article.
Source: https://habr.com/ru/post/105491/
All Articles