Домен верхнего уровня / суффикс домена для частной сети?

В нашем офисе у нас есть локальная сеть с чисто внутренней настройкой DNS, в которой все клиенты названы как whatever.lan. У меня также есть среда VMware, и в сети только для виртуальных машин я называю виртуальные машины whatever.vm.

В настоящее время эта сеть для виртуальных машин недоступна из нашей локальной сети, но мы настраиваем производственную сеть для переноса этих виртуальных машин, которая будет доступна из локальной сети. В результате мы пытаемся договориться о соглашении для суффикса / TLD домена, которое мы применяем к гостям в этой новой сети, которую мы настраиваем, но мы не можем придумать хорошую, учитывая это .vm, .localи .lanу всех есть существующее значение в нашей среде.

Итак, какова лучшая практика в этой ситуации? Есть ли где-нибудь список TLD или доменных имен, которые можно безопасно использовать для чисто внутренней сети?

Не используйте изобретенный TLD. Если бы ICANN делегировал это, у вас были бы большие проблемы. То же самое, если вы объединяетесь с другой организацией, которая использует тот же фиктивный TLD. Вот почему глобально уникальные доменные имена являются предпочтительными.

Стандарт RFC 2606 резервирует имена для примеров, документации, тестирования, но ничего для общего пользования, и по веским причинам: сегодня получить реальное и уникальное доменное имя так просто и дешево, что нет веских оснований использовать дурачок один

Таким образом, купить iamthebest.orgи использовать его для названия ваших устройств.

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

Интрнет-серверы:
www.example.com
mail.example.com
dns1.example.com

Внутренние машины:
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com

Я использовал «corp», чтобы показать, что этот поддомен описывает машины во внутренней корпоративной сети, но вы можете использовать здесь все, что захотите, например «внутренний»: client1.internal.example.com.

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

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

Например, вы всегда используете «database = dbserv1» в своем файле конфигурации.

На сервере разработки вы установите суффикс поиска равным «dev.example.com» => используемый сервер базы данных: dbserv1.dev.example.com

На сервере QA для суффикса поиска установлено значение «qa.example.com» => используемый сервер базы данных: dbserv1.qa.example.com

А на рабочем сервере вы задаете суффикс поиска «example.com» => используемый сервер базы данных: dbserv1.example.com

Таким образом, вы можете использовать одинаковые настройки в любой среде.

Так как предыдущие ответы на этот вопрос были написаны, было несколько RFC, которые несколько изменяют руководство. В RFC 6761 обсуждаются доменные имена специального назначения без предоставления конкретных рекомендаций для частных сетей. RFC 6762 по- прежнему рекомендует не использовать незарегистрированные TLD, но также признает, что в некоторых случаях это будет сделано. Поскольку обычно используемый .local конфликтует с Multicast DNS (основной темой RFC), в Приложении G. Частные пространства имен DNS рекомендуется использовать следующие TLD:

• интрасеть
• внутренний
• частный
• АМФ
• Главная
• ЛВС

IANA, похоже, распознает оба RFC, но не включает (в настоящее время) имена, перечисленные в Приложении G.

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

Как уже было сказано, вы не должны использовать незарегистрированный TLD для своей частной сети. Особенно сейчас, когда ICANN позволяет почти любому регистрировать новые TLD. Затем вы должны использовать реальное доменное имя

С другой стороны, RFC 1918 ясно:

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

Мы склонны считать, что нет никаких отличий в виртуальном именовании хостов от физического - фактически мы взяли абстрагирование конфигурации хоста (программного обеспечения) от физического уровня.

Поэтому мы приобретаем аппаратные элементы и создаем на них хост-элементы (и используем простую связь, чтобы показать это в нашей документации).

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

Я не уверен, что это поможет вам, но для внутреннего DNS внутри моей учетной записи AWS я использую .awsв качестве tld, и, кажется, работает отлично.

Я знаю, что есть некоторые TLD, которые вы должны просто не использовать, но кроме них, я не думаю, что это слишком строго.

Я работал в нескольких крупных компаниях, где они использовали источник аутентификации в качестве ДВУ, то есть, если бы это был сервер MS / Windows, используя Active Directory в качестве источника аутентификации, это было бы .ad, а некоторые другие .ldap(почему я использую один и тот же источник или серверы, реплицирующие данные из одной и той же службы каталогов? Я не знаю, когда я туда попал)

Удачи