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


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

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

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


100
2018-06-01 21:47


Источник


Не используйте .local. Особенно, если у вас есть клиенты Apple. - RainyRat
.test выделен по этой причине: secure.wikimedia.org/wikipedia/en/wiki/.test - CWSpear
@CWSpear Это не настоящая причина  .test зарезервирован, хотя он делает его безопасным для использования для контрольная работа сети, которые не будут подключены к Интернету. - voretaq7
@ Лучшие практики помогут диктовать вам «реальное» доменное имя (под признанным ICANN TLD) и создать субдомен этого для вашего местного материала (например, register mydomain.com, делегат internal.mydomain.com к внутреннему NS, и правильно настроить DNS с разделенным горизонтом («виды» в BIND), чтобы вы не просачивали внутренние имена / адреса в Интернет. Это не так красиво, как TLD / псевдо-TLD, но он менее подвержен поломке, поскольку он находится под вашим контролем. - voretaq7
Однако: не используйте настоящее доменное имя, которое вы уже использовали для публичных услуг. Существуют различные взаимодействия, которые допускаются между www.example.com а также *.internal.example.com которые не допускаются между www.example.com а также *.example.net, в первую очередь настройку cookie для разных сайтов. Запуск внутренних и внешних служб в одном домене увеличивает риск того, что компромисс публичной службы даст некоторое проникновение во внутренние службы, и наоборот, что небезопасная внутренняя услуга может спровоцировать внутреннее неправильное использование внешней службы. - bobince


Ответы:


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

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

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


85
2018-06-02 07:39



Чтобы быть абсолютно безопасным, я бы поставил все на поддомен доменного имени моей компании, например local.company.org, vm.company.org и т. Д. - drybjed
+1 это. Предположительно, ваша компания уже имеет домен. Просто создайте поддомен из этого. Он не должен быть видимым / разрешимым вне локальной сети. - Dan Carley
Ну, даже если у вас очень хорошие юристы, у вас возникнут проблемы с требованием «.lan» или «.local», вызвав товарный знак. И аргумент «он только внутренний» крайне слаб: организации объединяются, настраивают виртуальные частные сети с партнерскими организациями и просто делают ошибки, так что «частные» имена утечки. - bortzmeyer
Моя единственная говядина с этим заключается в том, что вы не можете «купить» домен: вы можете арендовать только один. Некоторые bozo забывают оплатить счет (и это произошло в нескольких громких случаях), и основная часть вашей конфигурации относится к случайному скваттерсу. Итак, вы используете домен вашей компании? Execs решают сделать ребрендинг или выкуплены, и вы застряли со старым именем. .local используется, чтобы работать достаточно хорошо, но теперь он был вытеснен определенной компанией способами, которые отказываются играть хорошо. Мне бы очень хотелось увидеть что-то вроде .lan или .internal, официально зарезервированное для этой цели, но до тех пор это лучший вариант. - Joel Coel
Согласитесь с @Joel Coel, вы - арендатор, и больше ничего. Должно быть два зарезервированных имени TLD только для внутреннего использования которые должны считаться недействительными публичными и недоступными для сетей общего пользования. Одно имя будет использоваться для внутреннего использования дома, второе имя будет использоваться для внутреннего использования. Оба они будут считаться «частными TLD» в том же смысле, что у нас есть «частные подсети», которые не маршрутизируются (192.168.x.x и ilk). Это позволяет домашним пользователям делать что-то помимо принудительного ввода в .local и mDNS. То же самое можно сказать о малых предприятиях, работающих внутри локальной сети за NAT без домена. - Avery Payne


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


45
2018-06-02 13:03





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

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

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

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

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

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


28
2018-06-04 12:00



Это блестяще. - Chris Magnuson
Пока кто-то неправильно настраивает свою рабочую станцию ​​с суффиксом производственного поиска, чтобы протестировать проблему, а затем непреднамеренно обновляет кучу производственных записей. - Joel Coel
Это довольно грубо, записи SRV очень просты для разбора и могут быть помещены в любую зону, так что один и тот же сервер db обслуживает несколько зон. В этом случае некоторый бит кода будет заполнять значение в ваших конфигурационных файлах. И вы можете использовать имя базы данных как ключ SRV и значение, указывающее на имя хоста. Я никогда не полагался на суффиксы поиска. Вы также можете получить довольно творческий подход с записями TXT и можете набить их зашифрованными (тогда base64 закодированными) значениями, если они секреты. Вы можете использовать записи TXT для всех видов вещей. - figtrap
см., но я хочу example.com, example.dev и example.stg. Последние 2 находятся только в частной сети, можно ли настроить локальный DNS-сервер для нулевого доступа к конфигурации? Все еще используя подобную конфигурацию здесь для всех сайтов, просто перемещая изменения до tld. Легко для .dev с файлом hosts, но zero config ... - DigitalDesignDj


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

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

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


10
2018-06-02 12:41





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

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

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


8
2018-06-01 21:52





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

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

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

Удачи


-4
2018-02-29 14:28



Amazon теперь зарегистрирована .aws как ДВУ, чтобы вы могли вначале увидеть проблемы: nic.aws - Mark McKinstry
Для информации, зарегистрированные ранее зарегистрированные «25 марта 2016 года» => newgtlds.icann.org/en/program-status/delegated-strings - Bruno Adelé
Хотя я не думаю, что использование фальшивого TLD - это большая сделка, по крайней мере, нет, если вся система закрыта и использует прокси для связи с интернетом в целом, «.aws» - действительно плохой выбор, если только вы «НЕ в AWS! Там слишком много мыслимых сценариев, где вы больше не сможете общаться с AWS. - figtrap