Dns сервер корневой зоны не может иметь имя

Обновлено: 24.01.2025

Как только мы обращаемся к онлайн-службе (например, к веб-сайту или к адресу электронной почты), корневые серверы имён или корневые серверы (DNS) играют важную роль в поиске адреса таких служб. Они являются важным компонентом системы доменных имен (DNS), фундаментальным столбцом Интернета и необходимы для разрешения имен в DNS, где доменное имя транслируется в IP-адрес. Это необходимый процесс, учитывая, что IP-адреса являются единственно возможным средством для связи с сервером онлайн-службы и получения с него необходимых данных.

Определение: корневой сервер

Корневой сервер имен (также называемый корневым сервером DNS или для краткости корневым сервером) отвечает за фундаментальные функции при преобразовании доменных имен в IP-адреса: он отвечает на запросы клиентов в корневой зоне системы доменных имен (метки корневой зоны, самый большой слой в пространстве имён DNS). Здесь корневой сервер имён не выполняет само разрешение имен, и вместо этого информирует запрашивающего клиента о том, с какого сервера имён (DNS-сервер) он может получить дополнительную информацию относительно требуемого IP-адреса.

Это осуществляется с помощью так называемого файла данных зоны, который является важным элементом каждого корневого сервера DNS. Сам файл содержит только около 2 МБ. Но он содержит все имена и IP-адреса всех доменов верхнего уровня (TLD). Эти данные принадлежат к важной функции: корневой сервер полагается на этот файл, если он называет сервер имён, который содержит необходимые детали его запроса.

Но даже если они только перенаправляют запросы, корневые серверы имён незаменимы при разрешении имен. Без них DNS не сможет функционировать в своём текущем виде. Корневой сервер работает в корне системы доменных имен и в некоторой степени играет наиболее важную роль в регистрации и наименовании веб-адресов.

Как работают корневые серверы

Но как корневой сервер имен помогает определить IP-адрес веб-сайта? Чтобы понять механизм работы корневого сервера, сначала нужно кое-что узнать о фундаментальном процессе разрешения имён в DNS.

Процесс разрешения имени

Основная роль систем доменных имен заключается в переводе доменных имен в IP-адреса (также называемые «прямой поиск»). Процесс разрешения имен в сети создает иерархически организованный процесс. Но, прежде чем DNS можно будет назначить для выполнения разрешения имен, прикладная система в целом пытается найти необходимый IP-адрес в своих собственных данных.

Количество станций, через которые проходит запрос, и порядок, в котором он проходит, зависит от множества различных факторов. Факторы, которые могут влиять на этот процесс, включают операционную систему пользователя или то, используются ли UDP или NetBIO через TCP/IP в качестве протокола. Само разрешение имён всегда обрабатывается в DNS одинаково, когда оно проходит через разные серверы. Мы покажем вам некоторые из наиболее важных этапов, через которые проходит этот процесс при поиске соответствующего IP-адреса веб-сайта и какую роль здесь играет корневой сервер DNS.

Обзор корневого сервера имен

Всего имеется 13 основных корневых серверов DNS, каждый из которых назван буквами от «A» до «M». Все они имеют адрес IPv4 и большинство имеют адрес IPv6. Ответственность за управление корневым сервером лежит на корпорации ICANN (Интернет-корпорация по присвоению имён и номеров). Но они управляются различными учреждениями, которые гарантируют, что обмен данными в корневой зоне всегда остаётся корректным, доступным и безопасным. В дополнение к их отдельным операторам в этом обзоре также отображаются отдельные корневые серверы имен.

буквы DNS корневых серверов	IPv4 адрес	IPv6 адрес	Оператор
A	198.41.0.4	2001:503:ba3e::2:30	VeriSign
B	192.228.79.201	2001:478:65::53	USC-ISI
C	192.33.4.12	2001:500:2::c	Cogent Communications
D	199.7.91.13	2001:500:2d::d	University of Maryland
E	192.203.230.10	NASA
F	192.5.5.241	2001:500:2f::f	ISC
G	192.112.36.4	U.S. DoD NIC
H	128.63.2.53	2001:500:1::803f:235	US Army Research Lab
I	192.36.148.17	2001:7FE::53	Autonomica
J	192.58.128.30	2001:503:c27::2:30	VeriSign
K	193.0.14.129	2001:7fd::1	RIPE NCC
L	199.7.83.42	2001:500:3::42	ICANN
M	202.12.27.33	2001:dc3::35	WIDE Project

Меры безопасности корневого сервера DNS

Корневые серверы ежедневно сталкиваются с большим количеством запросов. Большое количество из 13 корневых серверов имён не просто отвечает только на запросы клиентов; но также они делают это в сотрудничестве с другими серверами. Но существует гораздо больше, чем просто 13 различных серверов, которые обрабатывают запросы корневой зоны. В целом, по всему миру существуют сотни таких людей, которые несут ответственность за эту задачу. Большинство серверов находятся в США или Европе.

Тот факт, что эти серверы настолько распределены, помогает с балансировкой нагрузки и, следовательно, повышает надёжность корневых серверов: до появления Anycast только 13 основных корневых серверов имён могли отвечать на запросы. Учитывая, что 10 из них расположены в Соединенных Штатах, технология Anycast впервые сделала возможным эту относительно децентрализованную обработку запросов в корневой зоне. Кроме того, распространение серверов по всему миру сокращает время доступа к обработке запросов, поскольку сервер всегда отвечает на них в кратчайшие сроки.

Ещё одна мера безопасности с точки зрения ограничений возможностей используемого корневого сервера имён при нормальной работе: только треть доступных вычислительных ресурсов используется серверами. Это помогает гарантировать, что разрешение имён всё ещё может выполняться, когда несколько корневых серверов DNS испытывают нехватку мощности: в таких случаях остальные активные серверы принимают запросы, которые фактически предназначались для отправки на сбойный сервер.

После этого различные DDoS-атаки на корневые серверы DNS не будут иметь успеха в будущем, поскольку их настройки безопасности слишком сильные. Те, кто работает с 13 корневыми серверами, слишком хорошо знают, что их серверы значат для интернета: без них адресация интернет-сервисов будет уже невозможна.

Отличия от выделенных корневых серверов

Корневые серверы DNS, описанные в этой статье, относятся к корневому серверу имён из системы доменных имен. Это не следует путать с выделенными корневыми серверами, которые можно арендовать у провайдеров веб-хостинга. Такие хосты часто называют корневыми серверами, поскольку они отличаются от управляемых серверов тем, что имеют корневой доступ, более подробную информацию о различиях между этими двумя формами серверов можно найти в другой статье; так как эта тема не охвачена в этой записи.

В этой статье описывается, как устранять неполадки на DNS-серверах.

Проверка IP-конфигурации

Выполните ipconfig /all команду из командной строки и проверьте IP-адрес, маску подсети и шлюз по умолчанию.

Проверьте, является ли DNS-сервер полномочным для имени, которое ищется. Если это так, см. раздел Проверка на наличие проблем с достоверными данными.

Выполните следующую команду.

Если вы получаете ответ об ошибке или истечении времени ожидания, см. раздел Проверка проблем с рекурсией.

Очистка кэша сопоставителя. Для этого выполните следующую команду в окне командной строки с правами администратора:

Или в окне администрирования PowerShell выполните следующий командлет:

Повторите шаг 3.

Проверка неполадок DNS-сервера

Журнал событий

Проверьте следующие журналы, чтобы узнать, есть ли записанные ошибки:

Тестирование с помощью запроса nslookup

Выполните следующую команду и проверьте, доступен ли DNS-сервер с клиентских компьютеров.

Если сопоставитель возвращает IP-адрес клиента, у сервера нет проблем.

Если сопоставитель возвращает ответ "сбой сервера" или "Запрос отклонен", зона может быть приостановлена или сервер может быть перегружен. Чтобы узнать, приостановлен ли он, перейдите на вкладку Общие окна свойств зоны в консоли DNS.

Если сопоставитель возвращает ответ "запрос на превышение времени ожидания сервера" или "нет ответа от сервера", возможно, служба DNS не запущена. Попробуйте перезапустить службу DNS-сервера, введя следующую команду в командной строке на сервере:

Если проблема возникает при запуске службы, сервер может не прослушивать IP-адрес, который использовался в запросе nslookup. На вкладке интерфейсы страницы свойств сервера консоли DNS администраторы могут ограничить DNS-сервер прослушиванием только выбранных адресов. Если DNS-сервер настроен для ограничения службы указанным списком настроенных IP-адресов, то возможно, что IP-адрес, используемый для связи с DNS-сервером, отсутствует в списке. Можно попробовать использовать другой IP-адрес в списке или добавить IP-адрес в список.

В редких случаях DNS-сервер может иметь расширенную конфигурацию безопасности или брандмауэра. Если сервер расположен в другой сети, доступной только через промежуточный узел (например, маршрутизатор фильтрации пакетов или прокси-сервер), DNS-сервер может использовать нестандартный порт для прослушивания и получения клиентских запросов. По умолчанию программа nslookup отправляет запросы на DNS-серверы через порт UDP 53. Поэтому, если DNS-сервер использует любой другой порт, запросы nslookup завершатся ошибкой. Если вы считаете, что это может быть проблема, проверьте, используется ли промежуточный фильтр для блокировки трафика на хорошо известных портах DNS. Если это не так, попробуйте изменить фильтры пакетов или правила портов в брандмауэре, чтобы разрешить трафик через порт UDP/TCP 53.

Проверка на наличие проблем с достоверными данными

Проверьте, является ли сервер, который возвращает неверный ответ, основным сервером для зоны (основным сервером-источником для зоны или сервером, который использует интеграцию Active Directory для загрузки зоны) или сервер, на котором размещена дополнительная копия зоны.

Если сервер является сервером-источником

Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление.

Если на сервере размещается дополнительная копия зоны

Изучите зону на сервере-источнике (сервере, с которого этот сервер извлекает зоны).

Вы можете определить, какой сервер является сервером-источником, проверив свойства дополнительной зоны в консоли DNS.

Если на сервере-источнике указано неправильное имя, перейдите к шагу 4.

Если на сервере-источнике указано правильное имя, убедитесь, что серийный номер на сервере-источнике меньше или равен серийному номеру на сервере-получателе. Если это так, измените либо сервер-источник, либо сервер-получатель, чтобы серийный номер на сервере-источнике был больше, чем серийный номер на сервере-получателе.

На сервере-получателе выполните принудительную пересылку зоны с помощью консоли DNS или выполните следующую команду:

Изучите сервер-получатель еще раз, чтобы узнать, правильно ли передана зона. В противном случае у вас, вероятно, возникает проблема с переносом зоны. Дополнительные сведения см. в статье проблемы зонных передач.

Если зона была передана правильно, проверьте, правильно ли указаны данные. В противном случае данные в основной зоне неверны. Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление.

Проверка проблем с рекурсией

Чтобы рекурсия работала успешно, все DNS-серверы, используемые в пути рекурсивного запроса, должны иметь возможность отвечать и пересылать правильные данные. Если это не так, рекурсивный запрос может завершиться ошибкой по одной из следующих причин:

Время ожидания запроса истекло, прежде чем его можно будет завершить.

Сервер, используемый во время запроса, не отвечает.

Сервер, используемый во время запроса, предоставляет неверные данные.

Начните устранение неполадок на сервере, который использовался в исходном запросе. Проверьте, пересылает ли этот сервер запросы на другой сервер, изучив вкладку серверы пересылки в свойствах сервера в консоли DNS. Если флажок включить серверы пересылки установлен и в списке присутствует один или несколько серверов, этот сервер перенаправляет запросы.

Если этот сервер пересылает запросы на другой сервер, проверьте наличие проблем, влияющих на сервер, на который сервер пересылает запросы. Чтобы проверить наличие проблем, см. раздел Проверка неполадок DNS-сервера. Когда этот раздел предписывает выполнить задачу на клиенте, выполните его на сервере.

Если сервер находится в работоспособном состоянии и может пересылать запросы, повторите этот шаг и проверьте сервер, на который сервер пересылает запросы.

Если этот сервер не перенаправляет запросы на другой сервер, проверьте, может ли этот сервер запрашивать корневой сервер. Для этого выполните следующую команду:

Если сопоставитель возвращает IP-адрес корневого сервера, возможно, имеется разорванное делегирование между корневым сервером и именем или IP-адресом, который вы пытаетесь разрешить. Следуйте инструкциям по тестированию неработающей процедуры делегирования , чтобы определить, где находится неработающее делегирование.

Если сопоставитель возвращает ответ "запрос на превышение времени ожидания сервера", проверьте, указывает ли корневые ссылки на работоспособность корневых серверов. Для этого используйте для просмотра текущей процедуры корневых ссылок . Если корневые ссылки указывают на работающие корневые серверы, возможно, возникла проблема с сетью или сервер может использовать расширенную конфигурацию брандмауэра, которая не позволяет арбитру конфликтов запрашивать сервер, как описано в разделе Проверка проблем DNS-сервера . Также возможно, что рекурсивное время ожидания по умолчанию слишком мало.

Тестирование неработающего делегирования

Начните тесты в следующей процедуре, запросив допустимый корневой сервер. Этот тест позволяет выполнить запрос всех DNS-серверов из корня к серверу, который тестируется для неработающего делегирования.

В командной строке на тестируемом сервере введите следующее:

Тип записи ресурса — это тип записи ресурса, для которой был выполнен запрос в исходном запросе, а полное доменное имя — полное доменное имя, для которого выполнялись запросы (заканчивающиеся точкой).

Если ответ содержит список записей ресурсов "NS" и "A" для делегированных серверов, повторите шаг 1 для каждого сервера и используйте IP-адрес из записей ресурсов "A" в качестве IP-адреса сервера.

Если ответ не содержит запись ресурса NS, делегирование будет разорвано.

Если ответ содержит записи ресурсов "NS", но нет записей ресурсов "A", введите " задать рекурсию" и выполните запрос по отдельности для записей ресурсов "a" серверов, перечисленных в записях NS. Если вы не нашли по меньшей мере один допустимый IP-адрес записи ресурса "A" для каждой записи ресурса NS в зоне, то у вас есть неработающее делегирование.

Если вы определили, что вы используете неработающее делегирование, исправьте его, добавив или обновив запись ресурса "A" в родительской зоне, используя допустимый IP-адрес для соответствующего DNS-сервера для делегированной зоны.

Просмотр текущих корневых ссылок

Запустите консоль DNS.

Добавьте или подключитесь к DNS-серверу, который не прошел рекурсивный запрос.

Щелкните правой кнопкой мыши сервер и выберите пункт Свойства.

Щелкните корневые ссылки.

Проверьте наличие базовых подключений к корневым серверам.

Если правильно настроены корневые ссылки, убедитесь, что DNS-сервер, используемый в разрешении имен с ошибками, может проверить связь с корневыми серверами по IP-адресу.

Если корневые серверы не отвечают на проверку связи по IP-адресу, IP-адреса для корневых серверов могли измениться. Однако нередко можно увидеть перенастройку корневых серверов.

Проблемы с зонными ошибками

Выполните следующие проверки:

Проверьте Просмотр событий как для основного, так и для дополнительного DNS-сервера.

Проверьте сервер источника, чтобы узнать, не отправит ли он передачу данных для безопасности.

Проверьте вкладку зонные передачи свойств зоны в консоли DNS. Если сервер ограничит передачу зоны на список серверов, например на вкладке серверы имен в свойствах зоны, убедитесь, что сервер-получатель находится в этом списке. Убедитесь, что сервер настроен на отправку зонных передач.

Проверьте наличие проблем на основном сервере, выполнив действия, описанные в разделе Проверка проблем DNS-сервера . Когда появится запрос на выполнение задачи на клиенте, выполните задачу на сервере-получателе.

Проверьте, не работает ли на сервере-получателе другая реализация сервера DNS, например BIND. Если это так, проблема может быть вызвана одной из следующих причин:

Windows сервер-источник может быть настроен для отправки быстрых зонных передач, но сервер-получатель стороннего производителя может не поддерживать быструю передачу зоны. В этом случае отключите передачу данных с помощью быстрой зоны на сервере-источнике из консоли DNS, установив флажок включить вторичные базы данных-получатели на вкладке Дополнительно свойств сервера.

если зона прямого просмотра на Windows сервере содержит тип записи (например, запись SRV), которую сервер-получатель не поддерживает, то на сервере-получателе могут возникнуть проблемы с извлечением зоны.

Проверьте, запущена ли на сервере-источнике другая реализация сервера DNS, например BIND. если да, то возможно, что зона на сервере источника включает несовместимые записи ресурсов, которые Windows не распознает.

Если на главном или вторичном сервере используется другая реализация DNS-сервера, проверьте оба сервера, чтобы убедиться, что они поддерживают одни и те же функции. сервер Windows можно проверить на консоли DNS на вкладке дополнительно страницы свойства сервера. В дополнение к полю включить вторичные получатели привязок на этой странице содержится раскрывающийся список Проверка имен . Это позволяет выбрать принудительное соответствие требованиям RFC для символов в DNS-именах.

Причина. На активность DNS-сервера влияет неполадка в сети.

Решение. Убедитесь, что сервер имеет допустимое и работающее сетевое подключение. Сначала убедитесь, что соответствующее клиентское оборудование (кабели и сетевые платы) исправно, используя основные шаги решения вопросов, связанных с сетью или оборудованием.

Если оборудование сервера правильно настроено и работает исправно, убедитесь, что сервер может связаться с другими компьютерами или маршрутизаторами (например, со шлюзом по умолчанию), которые находятся в той же сети, что и DNS-сервер, используя команду ping.

Причина. С DNS-сервером можно связаться путем обычных сетевых проверок, но он не отвечает на DNS-запросы клиентов.

Решение. Если DNS-клиент может связываться с компьютером DNS-сервера с помощью команды ping, убедитесь, что DNS-сервер запущен и способен прослушивать подключения и отвечать на запросы клиентов. Чтобы проверить, может ли сервер отвечать DNS-клиентам, воспользуйтесь командой nslookup.

Дополнительные сведения см. в разделе Запуск и остановка DNS-сервера.

Решение. Если сервер ранее был настроен для ограничения IP-адресов, на запросы с которых он должен отвечать, возможно, что IP-адрес, используемый клиентом для связи с сервером, не включен в список IP-адресов, обслуживание которых разрешено.

Снова повторите проверку сервера, но укажите другой IP-адрес, который включен в список ограниченных интерфейсов для сервера. Если DNS-сервер ответит на запрос с этого адреса, добавьте отсутствующий IP-адрес сервера в список.

Причина. На DNS-сервере было отключено использование автоматически созданных зон обратного просмотра по умолчанию.

Решение. Убедитесь, что автоматически созданные зоны обратного просмотра действительно были созданы на этом сервере и что дополнительные изменения конфигурации не были перед этим применены к этому серверу.

По умолчанию DNS-серверы автоматически создают три стандартных зоны обратного просмотра в соответствии с рекомендациями документов RFC.

Эти зоны создаются с использованием обычных IP-адресов, которые не используются при обратном просмотре (0.0.0.0, 127.0.0.1 и 255.255.255.255). Являясь полномочной службой DNS для зон, соответствующих этим адресам, служба DNS избегает ненужной рекурсии на корневые серверы для выполнения обратного просмотр в этих типах IP-адресов.

Возможно, хотя и маловероятно, что эти автоматические зоны не были созданы. Отключение создания этих зон подразумевает дополнительные ручные изменения пользователем реестра сервера.

Чтобы убедиться, что эти зоны были созданы, выполните следующие действия:

Местонахождение

необходимый DNS-сервер

Причина. DNS-сервер использует нестандартный служебный порт, например в дополнительных настройках безопасности или брандмауэра.

Решение. Убедитесь, что DNS-сервер не использует нестандартную конфигурацию.

Это редкая, но вероятная причина. По умолчанию команда nslookup отправляет запросы на конечные DNS-серверы, используя UDP-порт 53. Если DNS-сервер находится в другой сети и достижим только через узел-посредник (например, маршрутизатор, фильтрующий пакеты, или прокси-сервер), DNS-сервер может использовать нестандартный порт для прослушивания и получения клиентских запросов.

В таком случае определите, специально ли промежуточный брандмауэр или прокси-сервер настроен на блокирование трафика, идущего через хорошо известные служебные порты, используемые для DNS. Если нет, может понадобиться добавить фильтр пакетов в эти настройки, чтобы разрешить трафик на стандартные порты DNS.

Также проверьте журнал событий DNS-сервера, чтобы узнать, происходило ли событие с кодом 414 или другие критические события, относящиеся к серверу, которые могли бы указать, почему DNS-сервер не отзывается на запросы.

DNS-сервер неправильно разрешает имена.

Причина. DNS-сервер предоставляет неверные данные в успешных ответах на запросы.

Решение. Определите причину появления неверных данных на DNS-сервере.

Ниже перечислены наиболее вероятные причины:

Чтобы предотвратить наиболее часто встречающиеся типы проблем, сначала просмотрите советы и рекомендации по развертыванию и управлению DNS-серверами. Также используйте контрольные списки, которые способствуют установке и настройке DNS-серверов и клиентов в зависимости от потребностей развертывания.

При развертывании DNS для доменных служб Active Directory обратите внимание на новые функциональные возможности интеграции в службу каталогов. Эти возможности могут отличаться от возможностей DNS-сервера по умолчанию, которые используются при традиционном хранении данных в файле.

Множество неполадок, связанных с DNS-сервером, начинаются с неудачных запросов на стороне клиента. Поэтому довольно часто решение вопросов следует начинать со стороны DNS-клиента.

Дополнительные сведения см. в разделе Устранение неполадок DNS-клиентов.

Причина. DNS-сервер не разрешает имена компьютеров и служб вне сети, например имена компьютеров и служб, находящихся во внешних сетях или в Интернете.

Решение. Сервер не может правильно выполнить рекурсию. Рекурсия используется в большинстве конфигураций DNS для разрешения имен, которые находятся вне настроенного DNS-имени домена, используемого DNS-серверами и клиентами.

Если DNS-сервер не может разрешить имена, для которых он не является полномочным, причиной, как правило, является неудачный рекурсивный запрос. Рекурсивные запросы часто используются DNS-серверами для разрешения удаленных имен, делегированных в другие DNS-зоны и серверы.

Чтобы рекурсия выполнялась успешно, все DNS-серверы на пути рекурсивного запроса должны отвечать на корректные данные и пересылать их дальше. Если нет, рекурсивный запрос может завершиться неудачно по одной из указанных ниже причин:

Причина. DNS-сервер настроен для использования других DNS-серверов, способствующих разрешению запросов.

Решение. Проверьте, может ли DNS-сервер использовать как серверы пересылки, так и рекурсию.

По умолчанию все DNS-серверы могут использовать рекурсию, однако параметр отключения рекурсии находится в диспетчере DNS, в разделе изменения дополнительных параметров сервера. Возможной причиной отключения рекурсии на сервере могла быть необходимость использования серверов пересылки, и рекурсия была специально отключена для такой конфигурации.

Если рекурсия на DNS-сервере отключена, на этом сервере невозможно будет использовать пересылку.

Причина. Текущие корневые ссылки для DNS-сервера недопустимы.

Решение. Проверьте допустимость корневых ссылок сервера.

Если они настроены и используются правильно, корневые ссылки всегда должны указывать на DNS-серверы, которые являются полномочными для зоны, содержащей корень домена и домены верхнего уровня.

По умолчанию DNS-серверы настроены на использование допустимых для конкретной сетевой среды корневых ссылок, основываясь на указанных ниже вариантах выбора при использовании диспетчера DNS для настройки сервера:

При такой конфигурации корневые ссылки на сервере отключены, так как сервер является полномочным для корневой зоны.

Причина. DNS-сервер не имеет сетевого подключения к корневым серверам.

Решение. Проверьте сетевое подключение к корневым серверам.

Если корневые ссылки настроены правильно, убедитесь, что DNS-сервер, использованный в неудавшемся запросе, может связаться с IP-адресами своих корневых серверов с помощью команды ping.

Если эта попытка завершится неудачно, это может означать, что IP-адрес корневого сервера был изменен. Однако изменение конфигурации корневых серверов - очень редкое явление.

Более вероятной причиной является потеря сетевого подключения или, в некоторых случаях, низкая сетевая производительность промежуточной сетевой инфраструктуры между DNS-сервером и его настроенными корневыми серверами. Придерживайтесь стандартных шагов по разрешению вопросов, связанных с сетевыми протоколами TCP/IP для проверки подключений и определения причин неполадок.

По умолчанию время ожидания рекурсивного запроса в службе DNS равен 15 секундам, после чего рекурсивный запрос завершается со сбоем. В обычных сетевых условиях это время ожидания менять не следует. Однако в целях увеличения производительности можно увеличить это значение.

Чтобы просмотреть дополнительные сведения, относящиеся к производительности DNS-запросов, можно включить и использовать файл журнала отладки DNS-сервера, который называется Dns.log. Этот журнал содержит подробные сведения о некоторых типах событий, относящихся к службе.

Причина. Существуют другие неполадки, связанные с обновлением данных DNS-сервера, например вопросы, связанные с зонами или динамическими обновлениями.

Решение. Определите, связана ли неполадка с зонами. При необходимости решите любые вопросы, связанные с этой областью, например возможные сбои при передаче зоны.

Невозможно представить своё существование без доступа к источникам информации, который даёт интернет. Связующим звеном сети компьютеров являются DNS серверы. К сожалению, иногда в их работе возникают ошибки. В этих случаях доступ к интернету ограничен или его нет совсем. Поэтому каждому пользователю не помешают базовые знания по теме.

Что такое DNS сервер, почему могут возникать ошибки

Видео: объяснение принципов работы DNS сервера

К сожалению, иногда в цепочке происходят сбои. Возникают ошибки. Причин может быть довольно много, рассмотрим самые распространённые:

нет подключения к интернету;
неправильные настройки роутера или модема;
некорректные настройки брандмауэра;
критически устарел драйвер сетевой карты;
заражение компьютера вирусом;
работы на DNS сервере провайдера;
ошибки программного обеспечения на сайте.

Устранение неполадок нужно начинать, проверяя простейшие настройки, и только в случае неудачи осторожно переходить к более сложным действиям.

Общие ошибки DNS

Рассмотрим самые распространённые ошибки, которые обычно легко устранить собственными силами. Как правило, исправление не занимает слишком много времени.

DNS сервер не отвечает, не удаётся найти DNS адрес сервера

Наверное, наиболее часто встречающаяся проблема.

Ошибки DNS могут появляться по причине неисправностей в работе роутера. А также в их возникновении может быть виноват интернет-провайдер. Перезагрузите или выключите на время маршрутизатор, возможно, это действие уберёт ошибку. Изменений нет — попытайтесь подключить интернет-кабель к ПК или ноутбуку напрямую, минуя роутер. Если действие не помогло, звоните своему провайдеру, вероятно, проблема на его стороне.

Когда все устройства работают нормально, а ошибка возникает на одном компьютере, скорее всего, она связана с неправильной работой самого устройства. Рассмотрение подобной ошибки достойно отдельной публикации.

Windows не удаётся связаться с устройством или ресурсом

Для выяснения причин ошибки проведите диагностику сети:

Для проведения диагностики сети нажмите значок правой кнопкой мыши

У этой ошибки могут быть разные причины возникновения. Методы решения проблемы подбираются соответственно:

некорректная работа антивирусной программы — попробуйте её временно отключить или установите другую;
возможно, сбоит DNS — клиент Windows — откройте «Панель управления» раздел «Администрирование» вкладку «Службы» и перезапустите службу DNS клиента, выключите и снова запустите компьютер.

Если все перечисленные действия не увенчались успехом попытайтесь сбросить DNS кэш. Нажмите Win+R, в появившемся окне наберите «ipconfig/flushdns», запустите процесс.

DNS кэш чистится запуском команды «ipconfig/flushdns»

После выполненных действий все должно работать нормально.

Нет доступа к DNS серверу

Для устранения возникшей ошибки произведите такие действия:

Выбираете пункт службы раздела администрирование, панели управления Windows

При работающем DNS в строке DNSP-клиент всегда есть запись «Работает»

На вкладке необходимо указать тип запуска: «Автоматический»

В ситуации, когда служба работает, а доступа к сети нет, должны помочь следующие действия:

Откройте вкладку «Центр управления сетями и общим доступом» в окне панели управления Windows

Выберите пункт «Изменение параметров адаптера» в разделе «Центр управления сетями и общим доступом»

На вкладке «Подключение по локальной сети», выберите пункт «Свойства»

Выделите пункт «Протокол интернета 4 (TCP/IP 4)», нажмите «Свойства»

Установите IP адрес сервера в ручном режиме

Если все сделано правильно, а положительного результата нет, существует большая вероятность ошибок Windows. Попробуйте провести восстановление системы в последней точке, когда все работало корректно. Для этого войдите в меню «Пуск», «Панель управления», «Восстановление». Выберите точку восстановления, запустите процедуру, перезагрузите компьютер.

Если браузер продолжает выдавать ошибку, как вариант для решения проблемы возможны такие действия:

Найдите и удалите подозрительные сетевые подключения

Последовательое завершение процессов через «Диспетчер задач Windows»

Такие манипуляции помогут выявить приложение, мешающее нормальной загрузке сайтов.

Ещё одной причиной ошибки могут быть устаревшие драйверы сетевого адаптера. Найдите его модель. На сайте производителя загрузите новые программы, установите.

Если ничего, из перечисленного выше, не помогло, тогда ваш компьютер атакован вирусом, произведите следующие действия:

Скачайте лечащую утилиту Dr. Web CureIt или другую с похожим функционалом.
Проведите полное сканирование компьютера.
Удалите заражённые файлы.

Стоит отметить ещё одну ошибку. Иногда при попытке входа в интернет можно увидеть надпись: «Не удаётся преобразовать DNS адрес сервера». Наиболее часто ошибка связана с ремонтными работами на DNS сервисе, предоставляющем услуги доступа к сети. Проверьте соединение с интернетом, подключив к нему другой компьютер или ноутбук. Если ошибка появляется на всех устройствах — свяжитесь с провайдером. В случае когда ошибка свойственна одному устройству, ваши действия подобны к исправлению ошибки «нет доступа к DNS серверу». Ваша система, по-видимому, посылает некорректные запросы на сервер DNS.

Ошибки программного обеспечения

К подобным относятся сбои DNS вызванные ошибками программного обеспечения серверов и отдельных сайтов.

Произошла временная ошибка DNS

запустите ПК или выполните перезагрузку, если компьютер включён и при запуске BIOS нажмите на клавишу F12 или Del;
для входа в настройки используются клавиши F1, F10 и другие — если вы не знаете, какую выбрать, читайте текст «Press… to enter Setup», где будет написана нужная комбинация;
в параметрах откройте раздел со словом Integrated, где вам понадобится строка On Board LAN или что-то на неё похожее;
поменяйте статус строки на Disabled, чтобы деактивировать её;
не забудьте для выхода воспользоваться кнопкой Save and Exit, чтобы сохранить изменения.

Панель БИОС, через которую вносятся изменения в конфигурацию ооборудования

Будьте осторожны, если у вас нет уверенности в своих действиях, не экспериментируйте с БИОС компьютера, лучше пригласите специалиста.

Когда сетевая карта одна или отключение второй не помогло убрать ошибку — попробуйте предпринять такие действия:

проверьте все записи DNS сервера в конфигурации сетевых карт (проверьте все сетевые адаптеры) убедитесь, что нет ссылки на сервер 127.0.0.1 в качестве DNS сервера, вместо этого используете реальный IP-адрес;
когда на сервере установлено более одного фиксированного IP-адреса, сделайте запись для всех IP адресов в файле hosts (C: Windows System 32 drivers etc hosts), отформатированном «192.168.1.1 SERVERNAME»;

Файл hosts предназначен для сопоставления доменных имен сайтов и IP адресов

Не удалось разрешить DNS имя контроллера домена

Отключите Брандмауэр Windows в разделе настройка параметров сети

Отключите протокола интерета 6 (TCP/IPv 6) на вкладке свойства сети

Не смогли загрузить страницу потому, что не нашли сайт в dns

Ошибка в основном относится к работе веб-мастеров. При регистрации нового домена DNS серверам неизвестен его адрес. Пока информация о нём на DNS серверах не появится, сайт, почта, другие элементы работать не будут. DNS сервер, прописанный для домена, выступает в роли «глашатая», благодаря которому адрес сайта станет известен другим серверам. Сначала информация о домене появляется на DNS хостинга. Если вы владелец сайта, а при попытке его открыть высвечивается ошибка «на dns сервере не найден адрес для домена этого веб-узла», обратитесь к администрации вашего хостинга.

Подобная ошибка может возникнуть при переносе домена на другой хостинг. В этом случае доменное имя сайта прежнее, а IP адрес меняется. Для решения проблемы необходимо обратиться к администрации вашего хостинга.

Другие распространённые ошибки

Кроме уже рассмотренных, могут возникнуть другие неполадки, связанные, с DNS сервером.

Таблица: часто встречающиеся ошибки DNS и способы их устранения

Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

Основные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:

Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.

Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.

Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.

FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:

Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.

Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.

Ресурсные записи

Ресурсная запись — это то, собственно ради чего в конечном счете и существует DNS. Ресурсная запись — это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена — IP адреса.

Запись ресурса состоит из следующих полей:

Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.

Т.о. после делегирования ответственности, информация хранимая делегирующей зоной уже не включает информацию по делегированному поддомену и его ресурсным записям хостов, а хранит информацию о серверах имен, являющихся для делегируемого поддомена авторитативными. Это и есть «склеивающие» записи, о чем я выше уже говорил. В таком случае, если у DNS-сервера родительского домена запрашиваются данные об адресе, принадлежащем делегированному поддомену, в ответ предоставляется список DNS-серверов, которые обладают соответствующей информацией.

Серверы DNS

Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.

Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.

Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.

Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.

Клиенты DNS (resolver)

Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовался файл /etc/host.conf. Вот фрагмент файла, который нас интересует:

Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:

Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.

Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:

Запросы DNS

В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.

Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.

Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.

Обратный запрос посылает IP и просит вернуть доменное имя.

Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.

Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запросрезолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
Резолверпосылает запрос указанному серверу имен.
Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запроссерверу, отвечающему за корневую зону.
Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
и «вложенности» доменных имен.
В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.

Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.

Ответы DNS сервера

Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).

Запись заголовка — служебную информацию о запросе.
Запись запроса — повторяет отправленный запрос.
Запись ответа — собственно, сам ответ.
Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
Дополнительную информацию — дополнительные записи, например адреса NS-серверов.

Обратное преобразование имен

DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле Type — PTR, а в поле Data — FQDN-имя соответствующее данному IP.

На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.

В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

Наглядно приведенную схему можно представить командами:

Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:

В двух словах хотел бы затронуть вопрос регистрации доменных имен.

Регистратор доменных имён — это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.

В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.

Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Резюме

Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня получилось. Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.

Что еще почитать:

Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.

Читайте также: