Что такое 1 Byte DNS?
Это DNS-сервер, предоставляющий пользователям возможность легко создавать и управлять DNS-зонами через удобный веб-интерфейс. Сервер поддерживает все основные типы записей, балансировку нагрузки и мониторинг здоровья адресов.
Как это работает?
Вы регистрируетесь, создаёте зону, указываете наши NS-серверы у вашего регистратора домена, а затем управляете записями через веб-панель. Все изменения применяются мгновенно.
Расположение
Сервис находится в России. Все серверы расположены на территории РФ, что обеспечивает низкую задержку для пользователей из России и стран СНГ.
Подтверждение владения
Когда несколько пользователей создают зоны с одинаковым доменным именем, наша система автоматически проверяет владение, опрашивая публичные DNS-серверы. Зона, контролирующая авторитетные NS-серверы, становится активной. Это обеспечивает справедливый доступ и предотвращает конфликты.
Мобильный интерфейс
Интерфейс адаптируется под размер экрана — им удобно пользоваться на телефоне, планшете или компьютере.
Передача зон: AXFR и IXFR
DNS-сервер поддерживает полную передачу зон (AXFR, RFC 5936) и инкрементальную передачу (IXFR, RFC 1995). При IXFR вторичные серверы получают только изменения между serial в формате дельта (delta), соответствующем RFC: каждая гранула содержит старый SOA, удалённые записи (TTL=0), новый SOA и добавленные записи (TTL>0). Арифметика serial следует RFC 1982 (циклический пересчёт 32-битного числа). Передачи ограничены ACL — только разрешённые IP-адреса могут запросить передачу. Если история IXFR недоступна, сервер автоматически переключается на полную передачу (AXFR).
Почему мы?
- Быстрые ответы DNS с низкой задержкой.
- Высокая доступность серверов и отказоустойчивость.
- Бесплатный сервис без скрытых платежей.
- Полный контроль над вашими DNS-записями.
Почему это сложно?
Создание корректного DNS-сервера означает реализацию десятков RFC-спецификаций вплоть до бита. Каждое требование ниже — реальное ограничение DNS-протокола, которое наш сервер обязан соблюдать.
The order of transmission is resolved to the octet level. Whenever an octet represents a numeric quantity, the left most bit is the high order or most significant bit.— RFC 1035 §2.3.2 — Порядок передачи на уровне бит
An entire domain name or a list of labels is replaced with a pointer to a prior occurrence of the same name. The pointer takes the form of a two-octet sequence: 11|OFFSET.— RFC 1035 §4.1.4 — Сжатие имён
A name server must employ multiple concurrent activities. It is simply not acceptable for a name server to block the service of UDP requests while it waits for TCP data.— RFC 1035 §6.1.1 — Требование конкурентности
It is very important that when a zone is refreshed, queries should not use old and new data simultaneously.— RFC 1035 §6.1.2 — Атомарная замена зоны
The MINIMUM value in the SOA should be used to set a floor on the TTL of data distributed from a zone. This floor function should be done when the data is copied into a response.— RFC 1035 §6.2 — Нижняя граница TTL
When a response is so long that truncation is required, the truncation should start at the end of the response and work forward in the datagram.— RFC 1035 §6.2 — Обратное усечение
There must not be any other RRs associated with a nickname of the same class.— RFC 1033 — Эксклюзивность CNAME
When data enters the domain system, its original case should be preserved whenever possible. All comparisons are done in a case-insensitive manner.— RFC 1035 §2.3.3 — Сохранение регистра
An IXFR server should keep record of the newest version of the zone and the differences between that copy and several older versions.— RFC 1995 §4 — История инкрементальных изменений
When a zone has been updated, it should be saved in stable storage before the new version is used. Otherwise, if the server crashes, data which is no longer available may have been distributed.— RFC 1995 §2 — Персистентность перед передачей
Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests.— RFC 5936 §4 — AXFR только по TCP
The AXFR protocol treats the zone contents as an unordered collection of RRs. Clients MUST accept any ordering and grouping of the non-SOA RRs.— RFC 5936 §2.2 — Неупорядоченная передача зоны
Name compression in an AXFR message SHOULD be performed in a case-preserving manner. Although "a" equals "A" for matching, for AXFR compression "a" is not equal to "A".— RFC 5936 §3.4 — Сжатие с сохранением регистра
Negative caching in resolvers is no longer optional. If a resolver caches anything it must also cache negative answers.— RFC 2308 §8 — Обязательное негативное кэширование
There are a large number of resolvers currently in existence that fail to correctly detect and process all forms of NXDOMAIN response.— RFC 2308 §2.1.1 — Совместимость NXDOMAIN
Compute the sum of the weights, and with each RR associate the running sum. Then choose a uniform random number between 0 and the sum, and select the RR whose running sum is first which is greater than or equal to the random number.— RFC 2782 — Взвешенный выбор SRV
There MUST be one or more address records for this name, the name MUST NOT be an alias.— RFC 2782 — Целевое имя SRV не псевдоним
Wildcard RRs can be thought of as instructions for synthesizing RRs. When the appropriate conditions are met, the name server creates RRs with an owner name equal to the query name.— RFC 4592 §1.2 — Синтез wildcard