Стандартизованные суффиксы имен

Секции .mil и .gov принадлежат исключительно американским сетям (хотя и многие другие трехсимвольные секции адреса, например .edu, чаще, но не всегда, принадлежат американским университетам и другим учебным организациям). Структура имен обычно отражает структуру организации, которой принадлежат сети или ЭВМ, но не архитектуру сети в этой организации. Так, имя itep.ru – это имя домена itepnet (Институт теоретической и экспериментальной физики, Москва).

По имени, как правило, нельзя определить, является ли оно именем сети, маршрутизатора или конкретной ЭВМ. Для записи символьных имен используется исключительно латинский алфавит.

Для администраторов, обслуживающих DNS, весьма полезно ознакомиться с документом RFC-1536 («Common DNS Implementation Errors and Suggested Fixes»). Ошибки при конфигурации DNS-сервера могут привести к досадным ошибкам и отказам системы. Обычно при получении запроса DNS сначала определяется его зона и просматривается кэш. Если запрос не может быть выполнен, просматривается список вышестоящих DNS-серверов, которые могут содержать необходимую информацию, и запрос пересылается одному из них.

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

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

Иногда DNS-сервер в ответ на запрос не присылает сообщений об ошибке и каких-либо данных клиенту. Это случается когда запрашиваемое имя вполне корректно, но записей нужного типа не найдено. Например, запрошен адрес почтового сервера домена xxx.com. Домен этот существует, но рекорда типа MX не обнаружено. Дальнейшие события зависят от характера программного обеспечения клиента. Если клиент считает такого рода «отклик» некорректным, он может послать запрос повторно и т.д. По этой причине в случае, если программное обеспечение это позволяет, рекомендуется ограничить число повторных запросов клиента. Приведенные примеры показывают, насколько актуальна корректная конфигурация DNS клиента и сервера.

В последнее время развивается технология DDNS динамического обновления ресурсных записей зоны DNS внешними ЭВМ или процессами (Dynamic DNS; RFC-2136). Клиенты с возможностями DDNS могут сами обновлять записи локальных серверов имен.