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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В то время как "некоммерческая" 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 для всех организаций или отдельных проектов, в которых включен Compute Engine API после 6 сентября 2018 г.

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

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

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

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

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

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

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

Это полезный вопрос, и ответы здесь действительно полезны. Я собрал основные соображения, как я их вижу:

• Не рекомендуется использовать поддомены общедоступного домена.
• Amazon.com и Google используют .
• В Приложении G к RFC 6762 говорится , что многие люди используют , говоря (перефразируя): «Не используйте собственный TLD, но если вы это делаете, мы видели, как некоторые из них используются, в том числе «.
• SAC113: В рекомендациях SSAC по TLD для частного использования говорится, что ICANN действительно следует разработать TLD для частных сетей. Он использует в качестве гипотетического примера (возражая при этом, что на самом деле не рекомендует). На графике реальных запросов он показан как один из самых популярных, и SAC113 выделяет его (наряду с.homeи.lan) в качестве примера.

Понимая, что лучшей практикой будет покупка отдельного домена, но принимая во внимание вышеизложенное, с 2023 года я решил перейти на.internal. Я не читал ни одного реалистичного сценария, который мог бы вызвать проблемы на практике.

Просроченный Интернет-проект под названием « Домены верхнего уровня для частных Интернетов» санкционировал бы использование 42 двухбуквенных «элементов кода, назначаемых пользователем» в качестве ДВУ для частного использования.

• AA
• QMкQZ
• XAкXZ
• ZZ

Таким образом, мы могли бы использовать

• aaaaaa.aaaaaaaaaa.aa
• gg.qq
• tired.zz
• windows.xp

и так далее.

Хотя срок действия этого проекта истек и, следовательно, он не станет предлагаемым стандартом, на IETF-111 группа dnsop представила обновленную информацию по этому предложению: протоколы видео слайды1 слайды2

Обновление заканчивается (выделено мной):

Измените подход проекта следующим образом:

• Признайте, что элементы кода User Assigned 3166 используются различными способами, включая частные сети.
• Признайте, что эти элементы не были делегированы и, как известно, используются некоторыми людьми для привязки частных пространств имен.
• Ничего не рекомендуйте, ничего не резервируйте, никаких реестров
• Не продвигайте какую-либо конкретную интерпретацию действующих стандартов.
• Задокументируйте потенциальные будущие ловушки при использовании этих кодов для частных пространств имен.
• Предоставьте читателям возможность принимать собственные решения

Итак, читая между строк и в духе недопустимых инноваций...

А если серьезно, посмотрите видео или хотя бы прочитайте минуты, прежде чем использовать что-либо из этого!

Относительно , ниже приведенhostsфайл, демонстрирующий простую настройку жилой/офисной сети. До строки 23 он точно такой же, как и Windows 11. Исключен из Глобальной системы DNS и поэтому является самым безопасным вариантом для тех, кто не арендует доменное имя .

Комментарии включают соответствующие части:

RFC952 - СПЕЦИФИКАЦИЯ ТАБЛИЦЫ ИНТЕРНЕТ-ХОСТОВ DOD

RFC1123 — Требования к интернет-хостам — применение и поддержка

RFC6762 — многоадресный DNS

RFC 8375 — Домен специального использования «home.arpa».RFC8375 — Домен специального использования home.arpa.

      # Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.lan          # source server
#       38.25.63.10     x.acme.lan              # x client host

# localhost name resolution is handled within DNS itself.
#   127.0.0.1       localhost
#   ::1             localhost


# --------------------------------------------------------------------------
# RFC 952 and RFC 1123 Hosts File
# https://www.rfc-editor.org/rfc/rfc952
# https://www.rfc-editor.org/rfc/rfc1123
# 
# This file contains hostname to IP address mappings for TCP/IP networks.
# 
# RFC 952 and RFC 1123 are standards that define the rules for hostnames in 
# the Internet. According to these standards, a compliant hostname must 
# meet the following criteria:
# 
# It can contain letters (A-Z, a-z), digits (0-9), hyphens (-), and periods (.).
# It must start with an alphanumeric character (letter or digit) and end 
# with an alphanumeric character.
# Hyphens (-) can be used as a separator but must not be at the beginning 
# or end of a label (part of the hostname separated by periods).
# Periods (.) are used to separate labels, which usually represent
# different levels of the domain hierarchy.
# Hostnames are case-insensitive.
# 
# RFC 1123 updated the original hostname requirements in RFC 952 to allow
# hostnames to start with digits. However, it did not change the maximum
# hostname length. The maximum length of a fully qualified domain name (FQDN)
# is 253 characters (excluding the trailing dot). This limit is based on the
# maximum size of a DNS message, which is 512 bytes, and the requirement to
# accommodate other data fields within the DNS message, such as the query
# type and class.
# 
# The format for entries in a hosts file is <IP-address> <hostname> <alias(es)>
# 
# RFC 6762 - Multicast DNS
# https://www.rfc-editor.org/rfc/rfc6762
# https://serverfault.com/a/1041148
# 
# Appendix G. Private DNS Namespaces
# 
# The special treatment of names ending in ".local." has been
# implemented in Macintosh computers since the days of Mac OS 9, and
# continues today in Mac OS X and iOS. There are also implementations
# for Microsoft Windows [B4W], Linux, and other platforms.
# 
# Some network operators setting up private internal networks
# ("intranets") have used unregistered top-level domains, and some may
# have used the ".local" top-level domain. Using ".local" as a private
# top-level domain conflicts with Multicast DNS and may cause problems
# for users. Clients can be configured to send both Multicast and
# Unicast DNS queries in parallel for these names, and this does allow
# names to be looked up both ways, but this results in additional
# network traffic and additional delays in name resolution, as well as
# potentially creating user confusion when it is not clear whether any
# given result was received via link-local multicast from a peer on the
# same link, or from the configured unicast name server. Because of
# this, we recommend against using ".local" as a private Unicast DNS
# top-level domain. We do not recommend use of unregistered top-level
# domains at all, but should network operators decide to do this, the
# following top-level domains have been used on private internal
# networks without the problems caused by trying to reuse ".local." for
# this purpose:
# 
#     .intranet.
#     .internal. (Google, Amazon) virtual intranets
#     .private.
#     .corp.
#     .home.
#     .lan.
# 
# RFC 8375 - Special-Use Domain 'home.arpa.'
# https://www.rfc-editor.org/rfc/rfc8375
# 
# 3.  General Guidance
# 
# The domain name 'home.arpa.' is to be used for naming within
# residential homenets. Names ending with '.home.arpa.' reference a
# zone that is served locally, the contents of which are unique only to
# a particular homenet and are not globally unique. Such names refer
# to nodes and/or services that are located within a homenet (e.g., a
# printer or a toaster).
# 
# DNS queries for names ending with '.home.arpa.' are resolved using
# local resolvers on the homenet. Such queries MUST NOT be recursively
# forwarded to servers outside the logical boundaries of the homenet.
# 
# Some service discovery user interfaces that are expected to be used
# on homenets conceal information such as domain names from end users.
# However, in some cases, it is still expected that users will need to
# see, remember, and even type names ending with '.home.arpa.'. The
# Homenet Working Group hopes that this name will in some way indicate
# to as many readers as possible that such domain names are referring
# to devices in the home, but we recognize that it is an imperfect
# solution.
# 
# --------------------------------------------------------------------------

# loopback address
127.0.0.1       localhost
::1             localhost

# RFC 952-compliant host entries using RFC 8375 Special-Use Domain 'home.arpa.'

# [IPv4]        DNS server                [Alias(es)]
10.0.0.2        dnsserver1.home.arpa      dns.home.arpa

# [IPv4]        DHCP server               [Alias(es)]
10.0.0.3        dhcpserver1.home.arpa     dhcp.home.arpa

# [IPv4]        Proxy server              [Alias(es)]
10.0.0.4        proxyserver1.home.arpa    proxy.home.arpa

# [IPv4]        Web server                [Alias(es)]
10.0.0.5        webserver1.home.arpa      www.home.arpa

# [IPv4]        File server               [Alias(es)]
10.0.0.6        fileserver1.home.arpa     files.home.arpa sftp.home.arpa

# [IPv4]        Application server        [Alias(es)]
10.0.0.7        appserver1.home.arpa      app.home.arpa api.home.arpa

# [IPv4]        Database server           [Alias(es)]
10.0.0.8        dbserver1.home.arpa       db.home.arpa

# [IPv4]        Mail server               [Alias(es)]
10.0.0.9        mailserver1.home.arpa     smtp.home.arpa imap.home.arpa

# [IPv4]        Print server              [Alias(es)]
10.0.0.10       printer1.home.arpa        printer.home.arpa

# [IPv4]        Backup server             [Alias(es)]
10.0.0.11       backupserver1.home.arpa   backup.home.arpa

# [IPv4]        Remote Desktop Services   [Alias(es)]
10.0.0.12       rds1.home.arpa            rds.home.arpa

# end of file

Реальный ответ согласно спецификации IETF :

      .localhost
.test
.example
.invalid

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

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

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

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

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

Удачи