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

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

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

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

98 голосов | спросил Otto 2 J0000006Europe/Moscow 2009, 01:47:14

6 ответов


84

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

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

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

ответил bortzmeyer 2 J0000006Europe/Moscow 2009, 11:39:09
45

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

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

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

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

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

ответил Jay Michaud 2 J0000006Europe/Moscow 2009, 17:03:34
28

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

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

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

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

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

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

ответил geewiz 4 J0000006Europe/Moscow 2009, 16:00:37
9

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

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

  

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

ответил Benoit 2 J0000006Europe/Moscow 2009, 16:41:43
8

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

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

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

ответил Mike Fiedler 2 J0000006Europe/Moscow 2009, 01:52:15
-4

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

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

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

Удачи.

ответил Justin 29 FebruaryEurope/MoscowbMon, 29 Feb 2016 17:28:14 +0300000000pmMon, 29 Feb 2016 17:28:14 +030016 2016, 17:28:14

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132