We made a new DNS*
And we decided to do this because DNS needs to be separated into a separate, self-deployed service and at the same time file features.
In terms of functionality, I wanted to match Route53, fix a couple of shortcomings and make it all free for users. Login or register on our siteyou can touch the new DNS by link.
The service is at the stage of public beta and we will be grateful for any feedback.
Interface
One day, we received a call to the hotline accompanying a ticket to OTRS. The CEO of a company called. For some reason, his server stopped working, the organization stopped working, and his main “programmer” had an accident and he himself needed help. The main part of the diagnostics was carried out by employees on the hotline right on the phone, together with the CEO. The conversation was recorded and submitted for analysis.
The most difficult moment for our client was when they and the operator reached the network diagnostics. In Windows Server, you need to open several windows and look in several different places to get to the properties of the network adapter. As new windows were opened, one could feel how the person on the other end of the wire “parsed” the contents of the new windows for longer.
You or your technical support may not have had to explain to a client in a stressful situation how and where to look, but we try to minimize complexity wherever we see it.
▍Minimization of technical complexity
The complexity of any system consists of:
- Inevitable complexity – the complexity associated with the subject area and features.
- Side complexity – the complexity introduced by the implementation of these features.
If we take the equivalent functionality on Route53, then in order to create a GeoIP record, you must explicitly specify the type of records to be added. This complexity has brought with it unnecessary restrictions, since it becomes impossible to group records of different types into one GeoIP sector.
Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service
This is a good example of the side complexity associated with the peculiarities of the business logic.
We removed all the side complexity and left only the inevitable – you just have to register the countries, specify the entries and come up with a name for this.
▍Minimizing cognitive complexity
You can reduce the cognitive load either by reducing the number of entities with which a person works, or by abstraction. We started looking at how users were using the previous version of DNS. Approximately 80% of users had only a couple of entries, however, there were real whales.
For people with the largest number of domains, the most popular record was CNAME, and the number of subdomains reached 63. People specified aliases for different services (ftp, smb) and branches in different cities (spb, msk). Therefore, we combined subdomains and additional logic into one entity and called it scenarios. It may not be the best name, but so far so.
We also separated the subdomain into a separate entity. Given the experience of the most active users, it is more convenient to manage subdomains as separate entities, since when it comes time to specify the unique records of one of the branches, they can be edited in one place.
The basic script (Simple) has no logic and is just DNS.
Now a few words about new, artsy scenarios.
New features
▍GeoIP
Sometimes people contact us in support or chat with a request to evaluate their ideas. One of the hottest ideas is your own small CDN.
The idea is to make an instance for your European clients and direct them to it using DNS or a redirect. The idea is good, so we made a GeoIP scenario. Entries in it will be allowed only in the specified countries.
But it’s not without limitations. If a person uses public DNS servers, instead of the server that he received via DHCP, he will end up in the country hosting this DNS. For example, if a person uses Yandex DNS, no matter where he is, the server will determine him as if he is always in Russia.
According to our estimates, GeoIP has an accuracy of about 70–80%, which is quite usable. We will understand how accuracy can be improved after analyzing the query logs. For now, try it.
▍Load Balancing
The script is useful if you have several copies of your application on several servers, and one of the copies is significantly faster than all the others. Unlike records with weights, balancing is carried out not by addresses, but by areas, where the weight is assigned to a group of records, and not to each one individually. That is, different servers can have multiple IP addresses. Thus, if your “strong” server has not only an IPv4 address, but also an IPv6 address, you can use that as well.
The balancing accuracy is not as high as that of balancers, but unlike HTTP balancers, it is not a single point of failure and does not require any intervention in the infrastructure. Plus it’s free.
▍TimeOfDay
This script allows you to specify alternate entries for a domain or subdomain for a specified time. For example, you can connect additional server capacities during peak hours, and in quiet times, in order to save money, replace an expensive instance with a cheaper one.
▍GeoIPFilter
Allows you to allow a domain or subdomain for people from the specified regions, which generally reduces the number of requests to the endpoint. Although the practical usefulness of this scenario is still in question.
▍Other
There are also mixtures of all of the above features. We will see how high the demand for them will be, and we will remove them if no one needs them.
Finally
Not only we will use our services, therefore, if you have ideas on how to make the service better, more convenient, or (horror) you own Photoshop, write your thoughts to support@ruvds.com and get bonus points on your balance.
For every good and unique idea, we will add an amount to the bonus balance, enough to rent a small server on Linux or Windows Server Core.
We will be glad to hear criticism with arguments and your ideas.
