Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

  • интранет
  • внутренний
  • частный
  • корп
  • домой
  • лан

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи