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

115

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

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

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

— эфирное масло
источник

2

Не используйте .local. Особенно, если у вас есть клиенты Apple.

— RainyRat

2

По этой причине .test отложен: secure.wikimedia.org/wikipedia/en/wiki/.test

— CWSpear

1

@CWSpear Это не настоящая причина .test зарезервировано, хотя это делает его безопасным доменом для использования в тестовых сетях, которые не будут подключены к Интернету.

— voretaq7

10

@ В соответствии с передовой практикой вы должны приобрести «реальное» доменное имя (в рамках TLD, признанного ICANN) и создать его субдомен для своего локального персонала (например, зарегистрироваться mydomain.com, делегировать internal.mydomain.comвнутреннюю NS и правильно настроить DNS с разделением горизонта ( "views" в BIND), поэтому вы не пропускаете внутренние имена / адреса в Интернет. Это не так красиво, как TLD / псевдо-TLD, но оно менее подвержено поломкам, так как находится под вашим контролем

— voretaq7

9

Однако : не используйте реальное доменное имя, которое вы уже использовали для общедоступных производственных служб. Существуют различные взаимодействия, которые разрешены между www.example.comи *.internal.example.comкоторые не разрешены между, www.example.comи *.example.net, в частности, межсайтовый параметр cookie. Запуск внутренних и внешних служб в одном и том же домене повышает риск того, что компрометация общедоступной службы даст некоторый доступ внутренним службам, и наоборот, что небезопасная внутренняя служба может спровоцировать внутреннее неправильное использование внешней службы.

— Бобинц

94

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

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

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

— bortzmeyer
источник

53

Чтобы быть в полной безопасности, я бы поместил все в поддомен доменного имени моей компании, например local.company.org, vm.company.org и так далее.

— Drybjed

4

+1 это. Предположительно у вашей компании уже есть домен. Просто создайте поддомен из этого. Это не должно быть видимым / разрешимым за пределами вашей локальной сети.

— Дэн Карли

3

Ну, даже с очень хорошими юристами у вас будут проблемы требовать ".lan" или ".local", вызывая товарный знак. А аргумент «это только для внутреннего использования» чрезвычайно слаб: организации объединяются, устанавливают виртуальные частные сети с партнерскими организациями и просто допускают ошибки, которые приводят к утечке «частных» имен.

— bortzmeyer

8

Единственное, о чем я могу сказать, это то, что вы не можете «купить» домен: вы можете арендовать только один. Некоторые бозо забывают оплатить счет (и это произошло в нескольких громких случаях), и основная часть вашей конфигурации идет на случайный скваттер. Так вы используете домен своей компании? Execs решили ребрендинг или выкупить, и вы застряли со старым именем. Раньше .local работал достаточно хорошо, но теперь его вытесняет определенная компания таким образом, что он отказывается играть хорошо. Мне бы очень хотелось, чтобы что-то вроде .lan или .internal формально зарезервировано для этой цели, но до тех пор это лучший вариант.

— Джоэл Коэль

6

Согласитесь с @Joel Coel, вы арендатор, и больше ничего. Должно быть два зарезервированных имени TLD только для внутреннего использования, которые следует считать публичными недействительными и недоступными для общедоступных сетей. Одно имя будет для внутреннего домашнего использования, второе имя будет для внутреннего коммерческого использования. Оба будут считаться «частными TLD» в том же смысле, что у нас есть «частные подсети», которые не маршрутизируются (192.168.xx и тому подобное). Это позволяет домашним пользователям делать что-то помимо того, что их принудительно вводят в .local и mDNS. То же самое для небольших предприятий, использующих внутреннюю локальную сеть за NAT без домена.

— Эйвери Пейн

49

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

— Джей Мишо
источник

32

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

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

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

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

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

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

— geewiz
источник

2

Это великолепно.

— Крис Магнусон

19

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

— Джоэл Коэль

1

Это довольно грубо, записи SRV очень просты для анализа и могут быть размещены в любой зоне, так что один и тот же сервер БД обслуживает несколько зон. В этом случае часть кода будет заполнять значение в ваших файлах конфигурации. И вы можете использовать имя базы данных в качестве ключа SRV и значение курса, указывающее на имя хоста. Я никогда не буду полагаться на суффиксы поиска. Вы также можете проявить творческий подход к записям TXT и добавить в них зашифрованные значения aes-256 (затем закодированные в base64), если они являются секретными. Вы можете использовать записи TXT для всех видов вещей.

— figtrap

видите, но я хочу, чтобы example.com, example.dev и example.stg. Последние 2 находятся только в частной сети. Могу ли я настроить локальный DNS-сервер для доступа без конфигурации? Все еще использую подобную конфигурацию здесь для всех сайтов, просто перемещая изменения до tld. Легко для .dev с файлом hosts, но без конфигурации ...

— DigitalDesignDj

15

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

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

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

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

— blihp
источник

В Приложении G перед списком, который вы цитируете, указано: «Мы не рекомендуем использовать незарегистрированные домены верхнего уровня». Это больше ключевой момент. Указанные имена не «рекомендуются» для использования, это просто наблюдаемые имена, которые будут работать лучше, чем те, .localкоторые зарезервированы для MulticastDNS, что обсуждается в Приложении G.

— Патрик Мевзек,

2

Я бы не согласился. Ключевым моментом является абсурдность совета: «не делайте этого ... но когда вы делаете ...» Ожидание того, что домашние / малые предприятия / непубличные сети должны зарегистрировать ДВУ, нереально. Люди будут использовать незарегистрированные TLD намного лучше, чтобы помочь всем и сказать: «Хорошо, вот список незарегистрированных TLD, которые вы можете использовать внутри страны», а не притворяться, что все будут следовать жестким советам.

— Блихп

Мы останемся в разногласии тогда. Тот факт, что некоторые люди использовали ДВУ, как они являются внутренними (например, .MAIL во многих документах), является именно той причиной, по которой эти ДВУ невозможно было делегировать, и теперь они на неопределенный срок умерли. Следовательно, продолжение рекомендовать людям использовать TLD таким образом является плохой услугой для мирового интернет-сообщества. В рекомендации говорится, что, поскольку некоторые ДВУ уже используются таким образом, если людям приходится злоупотреблять этим, им следует повторно использовать те, а не новые. В RFC2606 ясно, что TLD должны использовать внутренне, что будет работать:.EXAMPLE .TEST .INVALID

— Патрик Мевзек

12

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

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

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

— Benoit
источник

10

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

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

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

— Майк Фидлер
источник

-4

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

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

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

Удачи

— Джастин
источник

2

Amazon теперь зарегистрирован .awsкак TLD, так что в конечном итоге вы можете столкнуться с

— Mark McKinstry

1

Для информации .aws недавно зарегистрирован «25 марта 2016 года» => newgtlds.icann.org/en/program-status/delegated-strings

— Бруно Аделе

Хотя я не думаю, что использование фальшивого ДВУ является настолько важным делом, по крайней мере, если вся система закрыта и использует прокси-сервер для связи с Интернетом в целом, «.aws» - действительно плохой выбор, если вы НЕ в AWS! Существует слишком много возможных сценариев, когда вы не сможете больше общаться с AWS.

— figtrap