it-swarm-ru.tech

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

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

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

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

121
Otto

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

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

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

96
bortzmeyer

Используйте поддомен зарегистрированного домена вашей компании для внутренних машин, имена которых вы не хотите, чтобы в Интернете. (Тогда, конечно, только размещайте эти имена на своих внутренних 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 местоположений, каждое со своей подсетью, но все местоположения используют одно и то же (внутреннее) доменное имя. И наоборот, у вас может быть только одна или несколько подсетей, но много равноправных внутренних доменов или уровней поддоменов, которые помогут вам организовать ваши машины.

52
Jay Michaud

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

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

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

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

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

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

33
geewiz

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

  • интрасеть
  • внутренний
  • частный
  • аМФ
  • дом
  • лВС

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

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

26
blihp

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

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

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

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

13
Benoit

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

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

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

10
Mike Fiedler