DNS записи и сервер имен (DNS-сервер)
Опубликовано admin в 19 февраля, 2020 19 февраля, 2020
Если вы переносили сайт с одного хоста на другой, вам приходилось обновлять записи DNS. Хотя сам процесс безболезненный, многие могут не задумываться над тем, что это такое и причем тут сервер имен или DNS сервер, кроме того, что техническая поддержка говорит, что им нужно измениться.
В статье представлено краткое руководство для исправления этого пробела в знаниях. Рассказано простыми словами не только, что это за записи, но и какую роль они выполняют на вашем ресурсе.
Что такое DNS
DNS (Domain Name System) — это система доменных имен, которая превращает доменные имена в IP-адреса для загрузки интернет страниц.
Когда люди вводят название сайтов, например «Yandex.ru», в адресную строку браузера, DNS находит надлежащий IP-адрес и указывает куда надо перейти для доступа к данным сайта.
Это позволяет менять хосты без изменения домена, поэтому пользователям не нужно запоминать цифры.
Система содержит информацию о каждом портале в Интернете. Обойти это невозможно, в отличие от некоторых других областей. Хотя вы можете никогда не обновлять свои сведения — они все равно существуют.
Миграция информации является неотъемлемой частью в глобальной сети. Обновление и указание вашего домена при переезде на новый — это все, что требуется хосту для передачи, за вычетом небольшого времени распространения.
Что такое DNS-сервер
DNS-сервер — это компьютер с базой данных, содержащей общедоступные IP, связанные с названиями веб-сайтов.
Это можно представить как своеобразную телефонную книгу для Интернета. В ней находится список с соответствующими уникальными числовыми данными, называемыми IP-адресами, вместо того, чтобы указывать людей с их телефонными номерами. Когда пользователь вводит в своем браузере запрос, происходит поиск цифрового идентификатора в компьютерной сети.
Как только DNS находит запрашиваемый IP-адрес, браузеры берут его и используют для отправки данных на исходные серверы. После этого пользователь получает доступ к информации на странице. DNS запускает процесс, выбирая соответствующий унифицированный указатель ресурса (URL).
«Сервер имен» и «DNS-сервер» часто являются взаимозаменяемыми терминами — они означают одно и то же, поэтому не запутайтесь, если услышите такую терминологию.
DNS, сервер имен и ваш сайт
Соединение этих элементов — вот что позволяет сайту выходить во всемирную паутину. Все начинается с покупки домена у регистратора. Если вы являетесь его владельцем, ваш хост должен хранить свою информацию в DNS, чтобы обрабатывать его при входе в домен.
Это относительно простой процесс. Все, что нужно сделать, это указать, на какой сервер имен ссылается домен. Вы найдете его настройки в панели управления вашего регистратора. Большинство хостов сообщают свои адреса при регистрации, но быстрый звонок в службу поддержки устранит любую путаницу, если вы не сможете ее найти.
Почти всем регистраторам требуется основной и альтернативный DNS в случае, если один из них отключен. Например, «ns1.hosting.com» и «ns2.hosting.com». Каждый хостинг организовывает это немного по-своему. Поэтому обязательно проконсультируйтесь с провайдером.
Основные типы DNS записей
Существует несколько различных типов записей, которые можете изменить у своего регистратора. Как правило, все, что надо совершить — это обновить DNS. Но знание различных типов записей может помочь, если вам нужно что-то изменить в будущем.
A Record
A Record — это то, что указывают доменные имена на IP-адрес. Является самой чистой формой DNS, позволяющая пользователям вводить легко узнаваемое название, в то время как компьютер продолжает работать с числами.
CNAME
CNAME (Canonical Name) перенаправляет один домен на другой. Позволяет обновлять только одну «запись A» каждый раз, когда вы вносите изменения. Например, CNAME позволяет «site.net» получить «www.site.net» с «www» впереди.
MX Entry
MX Entry (почтовый обменник) направляет электронную почту на определенный почтовый сервис. Как и CNAME, записи MX должны указывать на домен. Вы также можете добавить несколько MX с разными приоритетами для избыточности, если у вас настроено значительное количество почтовых ящиков.
TXT Record
Это немного универсальная запись, предназначенная не для направления какого-либо трафика, а для предоставления информации внешним источникам. TXT Record служит ряду различных целей в зависимости от потребностей. Обычно используется для проверки Google.
AAAA Record
Запись AAAA аналогична A Record, но она позволяет указать адрес сайта IPv6 вместо интернет-протокола v4.
Вывод
Не волнуйтесь, если все это кажется немного сложным. Маршрутизация сложна, и эти базовые описания едва ли касаются каждого. В большинстве случаев вам никогда не нужно трогать эти настройки, но, если это сделаете, тех.поддержка любого хостинга всегда окажет помощь.
Автоматизация компьютеров для перенаправления миллионов запросов за доли секунды требует серьезной технической оснащенности и быстрых алгоритмов, и тем более серьезных знаний происходящих процессов. Тем не менее надеюсь, что этот пост хоть немного помог прояснить ситуацию.
Пишите в комментариях ниже, какую информацию добавить или убрать по теме: DNS записи и сервер имен (DNS-сервер). Открыт для предложений по оформлению и наполнению страницы.
Имена сервера
Имена сервера задаются с помощью директивы server_name и определяют, в каком блоке server будет обрабатываться тот или иной запрос. См. также “Как nginx обрабатывает запросы”. Имена могут быть заданы точно, с помощью маски или регулярного выражения:
При поиске виртуального сервера по имени, если имени соответствует несколько из указанных вариантов, например, одновременно подходят и имя с маской, и регулярное выражение, будет выбран первый подходящий вариант в следующем порядке приоритета:
Имена с масками
Имя с маской может содержать звёздочку (“ * ”) только в начале или в конце имени, и только на границе, определяемой точкой. Имена “ www.*.example.org ” и “ w*.example.org ” являются некорректными, но их можно задать с помощью регулярных выражений, например, “
Имена, заданные регулярными выражениями
Регулярные выражения, используемые в nginx, совместимы с используемыми в языке программирования Perl (PCRE). Имя сервера, заданное регулярным выражением, должно начинаться с символа тильды:
иначе nginx откажется запускаться и выдаст сообщение об ошибке:
К именованному выделению в регулярном выражении можно впоследствии обратиться через переменную:
Библиотека PCRE поддерживает именованные выделения, используя следующий синтаксис:
? name > Совместимый с Perl 5.10 синтаксис, поддерживается начиная с PCRE-7.0 ?’ name ‘ Совместимый с Perl 5.10 синтаксис, поддерживается начиная с PCRE-7.0 ?P name > Python-совместимый синтаксис, поддерживается начиная с PCRE-4.0
Однако такое использование должно ограничиваться простыми случаями как в примере выше, поскольку нумерованные выделения легко могут быть перезаписаны.
Прочие имена
Некоторые имена имеют специальное значение.
Если необходимо обрабатывать запросы без поля “Host” в заголовке в блоке server, который не является сервером по умолчанию, следует указать пустое имя:
Если директива server_name не задана в блоке server, то nginx будет использовать пустое имя в качестве имени сервера.
Версии nginx вплоть до 0.8.48 в этом случае использовали имя хоста (hostname) машины в качестве имени сервера.
Если в запросе вместо имени сервера указан IP-адрес, то поле “Host” заголовка запроса будет содержать IP-адрес, и запрос можно обработать, используя IP-адрес как имя сервера:
В примерах конфигурации серверов, обрабатывающих все запросы, встречается странное имя “ _ ”:
Версии nginx вплоть до 0.6.25 поддерживали специальное имя “ * ”, которое многими неверно воспринималось как имя сервера для обработки всех запросов. Оно никогда так не работало, и не работало как имя с маской. Это имя действовало так же, как сейчас действует директива server_name_in_redirect. Специальное имя “ * ” объявлено устаревшим, а вместо него следует использовать директиву server_name_in_redirect. Заметьте, что с помощью директивы server_name нельзя задать ни имя сервера для обработки всех запросов, ни сервер по умолчанию. Это является свойством директивы listen, а не server_name. См. также “Как nginx обрабатывает запросы”. Можно настроить серверы, слушающие на портах *:80 и *:8080, и указать, что один из них будет сервером по умолчанию для порта *:8080, а другой — для порта *:80:
Интернационализованные имена
Для указания интернационализированных доменных имён (IDNs) в директиве server_name следует указывать Punycode-представление имени:
Выбор виртуального сервера
Сначала соединение создаётся в контесте сервера по умолчанию. Затем имя сервера может быть определено на следующих стадиях обработки запроса, каждая из которых участвует в выборе конфигурации:
предварительно во время операции SSL handshake согласно SNI
после обработки строки запроса
после обработки поля Host заголовка запроса
если после обработки строки запроса или поля Host заголовка запроса имя сервера не было выбрано, то nginx будет использовать пустое имя в качестве имени сервера.
На каждой из этих стадий могут применяться различные конфигурации сервера. Таким образом, некоторые директивы следует указывать с осторожностью:
Оптимизация
Точные имена, имена с масками, начинающиеся со звёздочки, и имена с масками, заканчивающиеся на звёздочку, хранятся в трёх хэш-таблицах, привязанных к слушающим портам. Размеры хэш-таблиц оптимизируются на фазе конфигурации таким образом, что имя может быть найдено с минимальным числом непопаданий в кэш процессора. Подробнее настройка хэш-таблиц обсуждается в отдельном документе.
В первую очередь имя ищется в хэш-таблице точных имён. Если имя не было найдено, то имя ищется в хэш-таблице имён с масками, начинающихся со звёздочки. Если и там поиск не дал результата, то имя ищется в хэш-таблице имён с масками, оканчивающихся на звёздочку.
Регулярные выражения проверяются последовательно, а значит являются самым медленным и плохо масштабируемым методом.
нежели чем использовать упрощённую форму:
Если задано большое число имён серверов, либо заданы необычно длинные имена, возможно потребуется скорректировать значения директив server_names_hash_max_size и server_names_hash_bucket_size на уровне http. Значение по умолчанию директивы server_names_hash_bucket_size может быть равно 32, 64, либо другой величине, в зависимости от размера строки кэша процессора. Если значение по умолчанию равно 32 и имя сервера задано как “ too.long.server.name.example.org ”, то nginx откажется запускаться и выдаст сообщение об ошибке:
В этом случае следует увеличить значение директивы до следующей степени двойки:
Если задано большое число имён серверов, то будет выдано другое сообщение об ошибке:
В таком случае сначала следует попробовать установить server_names_hash_max_size в величину, близкую к числу имён серверов, и только если это не поможет или время запуска nginx станет неприемлемо большим, следует попытаться увеличить server_names_hash_bucket_size.
Если сервер является единственным сервером для слушающего порта, то nginx не будет проверять имена сервера вообще (а также не будет строить хэш-таблицы для слушающего порта). За одним исключением: если имя сервера задано регулярным выражением с выделениями, то nginx’у придётся выполнить это выражение, чтобы получить значения выделений.
Выбираем имена для серверов грамотно
Linux для хакера
Специалисты из хостинговой компании MNX.io как никто другой заинтересованы в том, чтобы использовать удобную и понятную схему генерации имён для серверов. Они разработали удобный алгоритм, которым поделились с сообществом.
Первым делом, устанавливаем адресную запись для сервера, используя один из доступных списков слов.
Например, можно выбрать женские имена или названия музыкальных групп. MNX.io особенно рекомендует список, полученный в результате мнемонического кодирования. Хотя там всего 1626 слов, но это специально подобранные короткие слова (4-7 букв), которые фонетически отличаются друг от друга, хорошо понятны по телефону и, преимущественно, известны во всём мире.
Мнемонический список гораздо лучше защищён от опечаток и ошибок, чем случайно выбранные слова. В составление этого списка лингвисты вложили много времени и сил.
Итак, имя выбрано автоматически из списка. Но адресная запись не даёт никакой информации о характеристиках сервера. Всю эту информацию заносим в каноническое имя для псевдонима DNS CNAME, кодируя его следующим образом.
1. Место расположения.
2. Окружение (группа серверов отдельного предназначения), зависит от организации разработки в компании.
3. Конкретное предназначение и серийный номер.
Эту стандартную структуру можно дополнить другими словами для удобства, например, webmail, cmdb, puppet и проч.
Отдельного внимания заслуживает сетевое и энергооборудование, которые следует именовать явно и конкретно, чтобы ни с чем не перепутать.
Пример реального серверного кластера, где серверы названы по предложенной схеме.
Мнемоническая схема отлично подходит для 1500+ серверов, разбросанных в разных дата-центрах. Список слов можно расширить по необходимости. Например, добавить в него пару тысяч футбольных команд или мегаполисов.
Что такое name-сервер (NS)
Имя сайта (домен) понятен пользователю, но компьютеру для открытия страниц необходимо знать точный цифровой адрес. Преобразованием «на лету» занимается DNS-сервер (другие наименования – name-сервер, nameserver, NS). Он переводит доменное имя в IP-адрес или наоборот, в зависимости от задачи. В любом случае без этого промежуточного звена открыть веб-ресурс не получится.
Какие функции выполняет name-сервер?
Обычному пользователю и не нужно знать технические детали, NS-серверы работают в прозрачном режиме, их роль незаметна. После ввода имени сайта в адресную строку браузера и нажатия клавиши Enter «сразу» открывается запрошенная страница. Обращение к DNS будет видно только по логу работы приложения.
Часто первое открытие нового веб-ресурса происходит медленно из-за времени, необходимого для ответа DNS-сервера. Последующие запуски происходят быстрее именно благодаря кэшу со списком ранее запрошенных доменов. Технически «промежуточные» узлы делятся по функционалу на три группы:
Сайт не откроется при неправильно указанном адресе DNS-сервера (на хостинге) или при его недоступности, потому что браузер «не будет знать», на каком реальном IP находится сервер, который используется для размещения файлов веб-ресурса. Если владельцу доступна возможность внести правки в настройки хостинга, пользователю остается лишь ждать решения проблемы.
Что такое дочерний NS-сервер?
Практически все хостинг-провайдеры бесплатно предлагают DNS-серверы. И везде работает как минимум один дочерний (резервный) хост. Дочерние серверы формируются при помощи «родительского» домена, например ns1.timeweb.org, ns2.timeweb.org. Такой подход дает возможность размещать их на основном сервере (за счет этого он и предоставляется безвозмездно).
При настройке NS-записей на «родном» хостинге, где покупались домены, достаточно внести имена и сохранить изменения. В большинстве случаев они вводятся автоматически при регистрации сайта (имени). Если же приходится делегировать полномочия другим пользователям, понадобится добавить IP-адреса. Без них работать система идентификации онлайн-ресурсов не будет.
Ресурсные записи для домена
То же относится к настройке электронной почты и других веб-сервисов. Провайдер вносит данные в автоматическом режиме или вручную в панели управления хостингом. Второе чаще востребовано в случае аренды платных DNS-серверов. Например, если у компании одновременно работает сразу несколько сайтов (существуют тарифы до 150 доменов и 12 000 записей).
Базовые типы записей:
От корректности заполнения адресов DNS-сервера зависит работоспособность сайта и его продвижение. Например, MX-записи используются для повышения репутации при рассылках по email (с ними письма реже попадают в категорию «спам»). TXT-записи востребованы для работы системных администраторов и оптимизаторов, пользующихся сторонними сервисами мониторинга и анализа сайтов.
Именование узлов в сети
Хочу поднять вопрос, который, как мне кажется, никто не рассматривал ранее системно. Вопрос звучит так:
как называть узлы и интерфейсы узлов в сети?
Для начала обрисую суть проблемы: когда у вас 2-3-5-10 серверов, то их названия, адреса и т.д. вы быстро запоминаете, и особой путаницы они не вызывают. Но если у вас несколько тысяч серверов (добавим к реальным ещё виртуальные), если у вашего маршрутизатора несколько сотен реальных или виртуальных (в виланах) интерфейсов, каждому из которых нужно дать имя (хотя бы для PTR/A записей в DNS), когда у вас есть интерфейсы для конфигурирования коммутаторов, принт-серверов, сетевых принтеров… В этих условиях нужно реально садиться и думать, как их называть. Лучше садиться думать до того, как начали называть, чем после.
Простые пути
Сначала рассмотрим простые решения, которые приходят первыми в голову.
Называть их по именам собственным
Например, по элементам таблицы менделеева (кто делал трейс до яндекса, видел). Хватит на сотню с небольшим имён. Потом будет интересно читать в логах, что Helium reject mail from potassium. Плюс этого — есть готовый набор аббревиатур для коротких алиасов, и он однозначен. Аналогично можно выбрать, например, страны. Или города. Или ещё какое-то множество с именами.
Минус этого вполне понятен: глядя на имя сервера невозможно понять, что он делает. Плюс — имена ясные, запоминаемые, различимые. Ясно, что мы кальций с калием никогда не перепутаем. Никогда.
Называть их по номерам
Например, fsbk3333, fsbk32232… Вполне себе имена. Если сервера однородны. А если нет? Помнить, что «333» это почтовый сервер, а 5622 — это out-of-band интерфейс запасного vpn-шлюза… Может, лучше по IP сразу?
Называть их по ролям
mail.domain, gateway.domain, vpn.domain, radius.domain, databases.domain, printer.domain и т.д. Плюсом является точное понимание, что каждый сервер делает. Минусом — некоторая путаница при смешанном фунционале (зачем у вас маршрутизатор коннектится к радиусу на сервер mail.domain? Ах, у вас там радиус-сервер? А почему имя «mail»?)
Дальше возникает потребность в нумерации, и в явном желании сократить название, потому что печатать каждый раз webserver23 быстро надоест.
Ещё большей проблемой будет наличие деления по отделам, этажам, зданиям, городам, фирмам и т.д. Выяснять, что webserver12 — это сервер с пресидами для рабочих станций в здании администрации в Перми, а webserver22 — интравеб-сервер с корпоративной CMS в головном офисе тяжело. Да и печатать такие названия тоже тяжеловато.
LDAP shall rule!
Нет ничего более отличительного и однозначного, чем OU=MSK, OU=«Main Branch», OU=labs, CN=«intranet web server»… Особенно, если это печатать руками каждый раз. Плюс, это не очень хорошо совместимо с DNS. Если только не печатать каждый раз «intranet-web-server.labs.mainbranch.msk.our_domain».
Общее построение задачи
Перейдём теперь к рассмотрению задачи в общем виде.
Понятно, что специфичные требования могут быть во-первых расширены (например, в случае сложной административной организации сети, само кодирование административного подчинения, может быть весьма и весьма сложным, например, если речь идёт о… «группе компаний», с подразделениями в каждой с относительной автономности; аналогично можно говорить и о других полях — географическом, фунциональном. )
Так же понятно, что в зависимости от типа организации часть полей может быть невостребована. Например, географическая или административная часть.
Однако, в общем случае, мы можем остановиться на вышеприведённом списке.
Теперь следующие два вопроса: какого размера должна быть каждая часть; как эти части должны разделяться? И третий вопрос: могут ли части имени иметь разную длину или они должны быть строго фиксированными?
Начнём с длины: database вполне укладывается в ‘db’, а terminal server в ‘ts’, то закодировать в две буквы, например, ‘backup’ уже немного сложно, получится произвольная необщеупотребимая аббревиатура, которая может наложиться на другие сокращения. Аналогично касается и географических названий. Допустим, у вас филиалы на каждой из линий Васильевского острова. Допустим, вы кодируете их двумя буквами. l4 — четвёртая линия, l8 — восьмая линия… А 17 линия как? А завтра у вас будут филиалы на станциях метро «Московские ворота», «Московская», ещё филиал просто «на Московском» и ещё филиал в Москве. Загонять себя в прокрустово ложе жёсткой длины имени, ИМХО, не разумно.
Далее, какими должны быть названия? Очевидно: наменьшими из возможных, но в «естественном» сокращении. Даже если у вас нет иных филиалов на «м», сокращать Москву до «m» (вместо msk) — это снижать мнемоничность и читаемость названия.
Географическая часть
В принципе, тут довольно просто, ибо искусство аббревиатур для географических названий давно освоено и публично известно. Двухбуквенные коды штатов в США, трёхбуквенные названия городов в России (из географических доменов), двухбуквенные коды стран (из ISO)… Аналогично могут сокращаться и названия улиц, хотя тут уже придётся проявить некоторую сообразительность (см выше пример про линии Васильевского острова).
Административное подичнение
Вопрос административного подчинения чуть более сложен. Полное название отдела/филиала может быть либо неудобочитаемым, либо малознакомым. Возможно, что об этой проблеме просто никто не думал. У банка могут быть отделения, и у отделений будут номера. Но как вы назовёте сервера в промежуточной серверной, которая совсем не «отделение банка»?
Наверное, самый болезенный вопрос: использовать ли транслит или перевод? Пусть каждый это решит для себя сам (хотя я терпеть не могу транслит).
Ещё одним важным «но» является то, что раскрытие административной принадлежности сервера посторонним людям может быть самым болезенным из всего, что говорит имя компьютера постороним лицам. msk-yukos-acc-12 — явно не то имя, которое хочется показывать окружающим.
Никогда не закладывайтесь на «это снаружи никто не увидит». Вы не знаете, где и кто увидит фрагмент письма (с заголовками о пересылке), сообщение сервера о том, что он не может связаться с SQL или ещё какой-то глупый ошмёток информации, который был бы бесполезен, если бы там не фигурировали столь подробные имена серверов…
Функциональная часть
Далее, о функциональной роли. Мне кажется, неверным было бы тут писать название протокола основного сервиса хотя такой соблазн всё-таки возникает. Правильнее было бы говорить именно о роли (заодно, в этот момент, можно подумать о том, не оказывается ли слишком много в компании завязано на один сервер).
Примеры: вместо www-сервера мы можем сделать ‘pa’ (public access) или ‘ea’ (external access) сервер (где отлично будет смотреться и FTP-сервер). Вместо proxy мы можем назвать его ag (application gateway), куда, кстати, весьма логично впишется и промежуточный почтовый релей. В то же самое время, для сереверов, которым по наилучшим практикам, не следует назначать иные роли, наверное, можно позволить называться по имени основной и единственной функции: DC для контроллера домена, EX — для exchange’а, SL для выделенного сервера syslog.
От себя замечу, что названия стоит давать не только умным железкам, но и тупым (ежели таковые в вашей сети ещё есть) — иногда нужно попросить перезагрузить/выключить/включить «вот тот коммутатор», а какой из них «тот»? Наличие на нём лычки msk-al-12 сильно увеличит точность выполнения просьбы.
Многоголовость
Если у маршрутизатора 30 разных сетей, 30 разными IP-адресами, то каждый из них должен иметь своё обратное имя. Здесь есть очередной выбор: либо мы вкладываем в этот номер смысл, либо нумеруем подряд. Отдельно, наверное, стоит выделять внешние интерфейсы (на граничных маршрутизаторах), внутренние и мостовые интерфейсы (br) в случае долгих линков (собственная оптика, виртуальные интерфейсы в VPN’е, просто линки между зданиями).
Рабочие станции и переферийный хлам
Не стоит недооценивать важность именования рабочих станций. Эти имена видны в заголовках SMTP (я как-то очень смеялся, когда мне пришло письмо в ответ на резюме с именем рабочей станции (по PTR’у) tupayasuka.domain.ru, cама рабочая станция считала, что называется komputer). Что нужно от имени рабочей станции? В отличие от сервера, ей не нужна многоголовость и функциональная роль, так что номер — вполне достаточно. Если есть разные типы станций (тонкие клиенты, винды, линухи) — то, возможно, упоминание об этом. Ну и географическое положение, разумеется.
Отдельно нужно учитывать наличие ноутбуков сотрудников, на которых они «сами себе админы» — разнообразие в названиях там будет редкостное…
Разделение имён
Теперь о том, сколько разделителей? Допустим, что у нас очень крупная компания, в которой очень много айтишного железа.
Примерный состав имени:
nsk (Новосибирск), hd (от head), mf (от manufacture, производственные помещения), st (storage, хранилище), 11 (одиннадцатый однотипный сервер), второй интерфейс (из трёх, два идут к коммутаторам для резервирования, один — для headbeat’ов в кластере).
Лично мне нравится предпоследний. Он всё-таки охватен по размеру каждой части, плюс, у него разделена география (nsk+hd — место в географическом смысле, mf+st — точное место (в рамках офиса) и примерная роль).
Виртуальность
Моменты, которые следует учитывать: вероятность географической миграции (глупо называть сервер msk-. если он будет мотаться между Амстердамом и Хельсинки); наличие привязок к инфраструктуре (например, к канальному сегменту при наличии каких-то L2 приложений (vlan’ы, pppoe, arp proxy)).
В принципе, я (для себя) остановился на использовании буквы ‘h’ (host system) для хостов и ‘v’ для гвестов (виртуальных машин). Например, v-mf11, мигрирующий между nskhd-hx1 nskhd-hx15 (догадайтесь сами, на чём оно работает).
Локальные псевдонимы
Ещё одной интересной вещью в работе могут быть локальные псевдонимы. Если какие-то сервера (оборудование) замкнуто (например, группа из серверов, решающая локальную задачу), то имеет смысл дать им короткие имена. Чтобы не напрягаться с DNS (который может быть при этом совсем в чужом административном управлении), возможно, файл hosts окажется очень даже к месту (да, этот файл создавался не только для vkontakte/odnoclassniki). Например, если есть сервер-хранилище, пара контроллеров и сервер отчётов, то почему бы их (в рамках своей группы) не назвать stor, ctl1, ctl2, rep? Разумеется, это имена только для «внутреннего» употребления, их не следует анонсировать наружу или использовать для конфигураций, в которых могут меняться используемые сервера.