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

Не используйте изобретенный 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

Я использовал "корпорацию", чтобы показать, что этот субдомен описал машины во внутренней корпоративной сети, но Вы могли использовать что-либо, что Вы хотите здесь, такой как "внутренние": client1.internal.example.com.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи

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

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

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

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

Как всегда, существуют стандарты де-юре и де-факто.

Пока «некоммерческая» ICANN играет в политику и деньги, мы, простые люди, страдаем. IETF однажды представила .home (RFC 7788) для персональных домашних интрасетей, но они не имеют власти над игроками IANA, работающими только за вознаграждение, и повторно ввели домен под .home.arpa (RFC 8375), так как IETF контролирует только .arpa.

В Приложении G к https://tools.ietf.org/html/rfc6762 упоминается:

.intranet .internal .private .corp .home .lan

для использования, если вы действительно хотите внутренний TLD.

Крупные игроки (Google, Amazon) используют .internal для виртуальных интрасетей:

• https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html — частное (внутреннее) имя хоста DNS разрешается в частный IPv4-адрес экземпляра. То частное DNS-имя хоста принимает форму ip-private-ipv4-address.ec2.internal для us-east-1 Регион и ip-private-ipv4-address.region.compute.internal для других регионов (где private-ipv4-address — IP-адрес обратного просмотра).
• https://cloud.google.com/compute/docs/internal-dns Зональный DNS [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal для всех организаций или отдельно проекты, в которых был включен API Compute Engine после 6 сентября 2018 года.

Эти компании могут покупать Интернет. Таким образом, де-факто безопасно использовать .internal TLD внутри страны ))

Настоящий ответ согласно спецификации IETF таков:

.localhost
.test
.example
.invalid

Я удивлен всеми агрессивными ответами, когда с 1999 г. существовало реальное конкретное руководство.

Я не могу сказать, является ли это всегда будет обходить HSTS. Это все еще может быть открытым вопросом.