Связность и идентификаторы Интернета

Павел Храмцов

Аннотация: У компании Sun Microsystems (поглощена компанией Oracle в 2010 году) был cлоган: «The Network is the Computer». Это показывает, насколько многогранно понятие «Сеть» («Network»). Мы как раз и будем рассматривать термин «Сеть» («Network») в контексте сети Интернет, т.е. сети TCP/IP.

В статье мы введём понятие связности. Опираясь на модель стека TCP/IP, рассмотрим «связность» на каждом из четырёх уровней этой модели. Определим, какую роль играют идентификаторы на каждом из этих уровней.

Обнаружим, что никакой статической связности в Интернете нет. Она, возможно, была в DARPANET или в NSFNET, но в настоящее время связность динамическая – это краеугольный камень построения сетей передачи данных на основе стека протоколов TCP/IP.

Общие замечания относительно понятия «связность» и интернет-идентификаторов

Довольно часто слово «связность» отождествляют с английской калькой термина «connectivity» – «коннективность». А правильно ли это?

Google переводит слово «connectivity» как «возможность подключения». Искусственный интеллект в лице DeepSeek (куда же без него) даёт более развёрнутое определение, «например, «internet connectivity» означает возможность подключения к Интернету», т.е. речь идёт о возможности установления такой связи.

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

Документ RFC-1122 определяет только четыре уровня протоколов.

Структурная модель сети TCP/IP определена в разделе 1.1.3 RFC-1122 и состоит из:
– протоколов обмена данными уровня приложений (application layer);
– протоколов транспортного уровня (transport layer);
– протоколов сетевого уровня (internet layer);
– протоколов канального уровня (уровень взаимодействия с сетью, или link layer).

Интернет – это сеть сетей, по этой причине возможность установки связи на уровне канала, т.е. «на уровне взаимодействия с сетью» не даст ответа на вопрос о возможности установления связи между двумя хостами из разных сетей. Основным идентификатором на уровне канала является MAC-адрес интерфейса.

На уровне протоколов межсетевого обмена (Internet Protocol – IP) идентификаторы этого уровня – это IP-адреса и их агрегаты.

На транспортном уровне в TCP/IP используются два основных протокола – UDP и TCP.

Приложения «привязаны» к так называемым транспортным портам. Общий список портов ведётся в реестре IANA – «Service Name and Transport Protocol Port Number Registry» [4]. Основными идентификаторами в протоколах TCP/UDP являются номера портов.

Связность в графах

Сеть Интернет (TCP/IP) – это сеть коммутации пакетов. IP-пакет путешествует от одного хоста (узла сети) к другому хосту через систему шлюзов – хостов, которые по определённым правилам передают пакеты из одной локальной сети в другую.

Сами правила передачи и процесс их определения и трансформации называют маршрутизацией. В рамках этих процессов применяют разные протоколы маршрутизации. Например, OSPF (Open Shortest Path First) [6] сетевого уровня или протоколы прикладного уровня типа RIP (Routing Information Protocol) [7], или BGP4 (Border Gateway Protocol 4).

Протоколы маршрутизации опираются на математические модели. Например, в протоколе RIP применяется алгоритм Форда-Фалкерсона [8] (известен также как алгоритм Белмана-Форда), а в протоколе OSPF применяется алгоритм Дейкстры [9].

Исследования сходимости BGP-таблиц (устойчивое состояние всех таблиц BGP) основано также на графовых моделях с применением различных топологий (иерархическая сеть, кольцо, смешанная сеть) [10]. В теории графов существуют понятия пути и маршрута, и связность, таким образом, – это возможность существования путей и маршрутов в каждый конкретный момент времени.

Стек протоколов, идентификаторы и связность

Мы имеем четыре уровня стека протоколов TCP/IP. Вообще говоря, стек в том виде, как его используют сейчас, появился не сразу. В статье «A Protocol for Packet Network Intercommunication» [3], которая дала начало внедрению сетей TCP/IP, Vinton G. Cerf и Robert E. Kahn обсуждали только один протокол.

Уровень канала

На уровне взаимодействия с сетью (уровне канала) принято говорить о MAC – Media Access Control.

Основным идентификатором является MAC-адрес. Каждое устройство подключения к сети, будь то Ethernet-карточка или Wi-Fi-модуль, имеют MAC-адрес.

Адрес нужен тогда, когда к одной среде подключено сразу несколько устройств, как, например, в Ethernet или Wi-Fi.

Исторически первые MAC-адреса для идентификации устройств в локальной сети появились в Ethernet. Ethernet относится к технологиям множественного доступа к общей передающей среде в локальной компьютерной сети с контролем коллизий CSMA/CD [4] (IEEE 802.3). На рисунке1 представлен формат MAC-адреса.

Рис. 1. Формат 48-битового MAC-адреса.

Отметим, что первый октет адреса начинается с идентификатора организации. Выделяет адреса производителям оборудования реестр IEEE Registration Authority [5]. Каждый адрес уникален. IEEE относит группу протоколов 802.3 к протоколам не только канального уровня, но и физического уровня модели OSI.

Уровень канала в общем случае позволяет теоретически построить «большую» сеть на MAC-адресах. Но практически так по разным объективным причинам не поступают.

Адресация в сетях TCP/IP обеспечивается на сетевом уровне или уровне межсетевого обмена за счёт введения IP-адресов.

Классическим протоколом канального уровня для определения соответствия «MAC-IP» является протокол ARP [6]. В RFC826 название протокола звучит буквально так: «An Ethernet Address Resolution Protocol or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware». Реализации протокола поддерживают таблицу соответствия между IP-адресами версии IPv4 и MAC-адресами.

В IPv6-сетях ARP не применяют. При инициализации интерфейса используется 64-битный EUI-64 [7] идентификатор, при вычислении которого используют MAC-адрес. На основе EUI назначается локальный IPv6-адрес. Затем по запросу ICMP или DHCPv6 можно получить IPv6 для отправки/получения данных из Интернета.

Следует отметить, что часто для обеспечения информационного обмена на уровне канала используются протоколы прикладного уровня. Например, протокол DHCP (Dynamic Host Configuration Protocol) [8] в сетях IPv4.

Итак, на уровне канала в качестве идентификатора используются MAC-адреса и строятся таблицы соответствия между этими адресами и IP-адресами.

Уровень сети

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

К слову сказать, в контексте сетевого уровня протоколов правильно говорить именно о маршрутах, как мы их определили ранее.

К сетевому уровню стека протоколов (internet layer) TCP/IP принято относить IPv4 [9], IPv6 [10], ICMP [11], NDP [12], IGMP [13], IPSec [14] и ряд других.

Ядро протоколов этого уровня – это Internet Protocol версий 4 и 6.

Основное назначение интернет-протокола IP – это передача пакета битов (an internet datagram) от источника данных к получателю данных через систему взаимосвязанных сетей. При этом в протоколе нет механизмов контроля надёжности передачи, последовательности приёмо/передачи или других, которые характерны для обмена данными по протоколам типа «хост-хост».

Единственным механизмом, который позволяет передавать пакет по множеству взаимосвязанных сетей, является анализ IP-адреса.

Особую роль в процессе маршрутизации имеет структура IP-адреса. Старшие биты адреса определяют адрес сети, а младшие – адрес хоста в этой сети. При чём этот принцип общий и для протокола версии 4, и для протокола версии 6.

Как распределяются части IP-адреса, определено в Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan [15] (RFC-4632).

IP-адреса уникальны. Здесь придётся сделать небольшое отступление и рассказать, как устроено распределение такого ограниченного ресурса, как адресное пространство.

IANA-функции, или Кто управляет Интернетом

Распределение адресного пространства является одной из так называемых IANA-функций. ICANN в своём информационном буклете [16] описывает их как:

а) IANA-functions: protocol parameters;
б) IANA-functions: internet number resources;
в) IANA-functions: root-zone management of the domain name system;
г) IANA-functions: other services.

В первом блоке речь идёт о таких параметрах, как, например, порты транспортного уровня стека протокола, закреплённые за определёнными сервисами (WKS – Well Known Services), или медиа-типы, которые используются в HTTP-протоколе при передаче контента.

Работы по стандартизации в соответствии с меморандумом о взаимопонимании (MOU – memorandum of understanding) между ICANN, IETF, IAB [17] ведутся в IETF, a IANA как часть ICANN обеспечивает контроль и бесплатный доступ к этой информации.

С 2016 года функции IANA переданы в учреждённую ICANN некоммерческую организацию PTI – Организация по открытым техническим идентификаторам [18].

Вторая функция, наиболее интересная для нас, – распределение адресного пространства. Для реализации этой функции создан иерархический механизм, в который входят разные организации в разных регионах и странах.

Описание этой системы изложено в RFC7020 – «The Internet Numbers Registry System» [19].

На вершине иерархии распределения ресурсов находится IANA. В контексте документа – это не организация, а функция начального распределения блоков адресов и номеров AS. Организационно эта функция возложена на ICANN, сейчас ее выполняет PTI.

Блоки распределяются по региональным интернет-реестрам (Regional Internet Registries – RIRs). Сейчас определено пять таких реестров:

AfriNIC – Африканский регион;
APNIC – Азиатско-Тихоокеанский регион;
ARIN – Северо-Американский регион и часть Карибского региона;
LACNIC – регион Латинской Америки и часть Карибского региона;
RIPE NCC – Европейский регион, Регион Ближнего Востока и часть Азиатского региона.

Эти региональные реестры созданы в соответствии с политикой ICANN [20].

Региональные реестры из выделенных им блоков выделяют подблоки локальным интернет-реестрам – LIR-ам (Local Internet Registry), которые обычно являются интернет-провайдерами, хотя, например, один из крупнейших российских LIR-ов – РосНИИРОС [21] – реально таковым не является.

Локальные интернет-реестры уже распределяют адреса между своими клиентами, которые назначают их хостам.

Рис. 2. Распределение мирового адресного пространства.

Есть регионы, где между RIR и LIR есть ещё один уровень иерархии – National Internet Registries (NIRs). Например, национальные реестры есть в Азиатско-Тихоокеанском регионе и регионе Латинской Америки:

– IDNIC-APJII (Индонезия и Полинезия);
– CNNIC (Китай);
– JPNIC (Япония);
– KRNIC (Южная Корея);
– TWNIC (Тайвань);
– VNNIC (Вьетнам);
– IRINN (Индия);
– NIC Mexico (Мексика);
– NIC.br (Бразилия).

Адресное пространство – это ограниченный ресурс. Например, свободных блоков адресов для работы в Интернете по протоколу IPv4 формально уже не осталось. Они, конечно, есть. Но их осталось немного, и их реально продают. Просто вдумаемся: 232 (4 294 967 296) адресов распределено по провайдерам Интернета [22].

На рисунке 3 представлена цена за адрес в зависимости от времени и размера блока адресов. А на рисунке 4 – общий объём рынка адресов IPv4.

Рис. 3. Стоимость адреса IPv4.

Рис. 4. Оценка объёма глобального рынка адресов IPv4.

В RIPE блоки закончились в 2019 году, объёмы трансферов начали расти с 2013. На свои максимальные показатели вышли в 2022, но уже в 2017 нехватка ощущалась, судя по графику на рисунке 4, достаточно остро.

Проблем с выделением адресного пространства IPv6 не наблюдается. Количество сетей, которые поддерживают эту реинкарнацию Интернета, постоянно растёт [23]. Google ведёт статистику обращений конечных пользователей из разных типов IP-сетей (представлена на рисунке 5). Она показывает, что пользователей с адресами IPv6 чуть меньше 50% от общего числа пользователей Google, и этот процент продолжает увеличиваться. Для России Google дает оценку в 45,97% (рисунок 6) от общего числа обращений из России. Но вот оценкам по России от Google доверять следует с осторожностью. Ряд организационных решений компаний в 2022 году существенно ограничили трафик из России на сервисах, что неизбежно сказалось на их репрезентативности [24].

Рис. 5. Доля пользователей Google c адресами IPv6.

Рис. 6. Использование адресов IPv6 в России по оценке Google.

Теперь о том, «кто управляет Интернетом». Считается [25], что управляет тот, кто выделяет необходимые для работы в Интернете ресурсы. Нет IP-адреса – нет связности. Нет возможности отправить пакет по сети.

Вывод: на сетевом уровне стека протоколов TCP/IP основным идентификатором и ограниченным ресурсом является IP-адрес.

Уровень транспорта

На уровне транспорта стека TCP/IP находятся два протокола: TCP и UDP. Назначение TCP – обеспечить потокоориентированный надёжный способ передачи данных от приложения на одном хосте приложению на другом хосте. К UDP требований надежности и обеспечения потокоориентированности не выставляется. Контроль целостности сообщений между приложениями возложен на сами эти приложения.

Протокол UDP довольно часто использовался там, где сами размеры пакетов данных были невелики: например, в DNS (53 порт UDP). Основным ограниченным ресурсом на уровне транспорта являются порты, к которым привязаны приложения.

В IANA/PTI существует справочник стандартных номеров портов для публичных сервисов, таких как почта (25 порт TCP), веб (HTTP – 80 TCP, HTTPS – 443), SSH (22 -TCP) и т.п. Вообще говоря, если приложение-сервер и приложение-клиент делает один разработчик, то он волен выбрать любые порты, но желательно, выше 1024. Тем не менее, например, протокол прикладного уровня MTProto (Telegram) стандартно использует 80, 443, 5222 порты TCP непосредственно (plain TCP socket) [26].

Здесь мы рассмотрели классический транспортный уровень, например, упомянутый выше MTProto может в качестве транспорта использовать Websoket-протокол [27]. Таким образом, транспорт может быть многослойным.

Итак, для транспортного уровня основным ограниченным ресурсом являются транспортные порты. Проверка наличия связности на уровне транспорта при использовании протокола TCP происходит на уровне TCP-handshake [27].

Уровень приложений

Мы уже упоминали протокол DHCP. Протокол используется при подключении хоста к сети TCP/IP. В этот момент у хоста нет IP-адреса. Хост свой адрес, адрес шлюза и адрес кеширующего DNS-резолвера (опционно) получает по этому протоколу. Соответственно, заполнение ARP-таблицы и таблицы маршрутизации происходит только после того, как будет завершён обмен информацией по DHCP.

DHCP использует в качестве транспорта UDP [28]. Клиент обращается к серверу по 67 порту, а сервер отвечает на 68 порт.

Здесь следует сделать несколько замечаний о связности. Получение IP-адреса хостом – это вопрос связности в рамках локальной сети. Получение хостом адреса шлюза – это вопрос связности в рамках сети Интернет на уровне транспорта. А вот получение адреса кеширующего DNS-резолвера – это уже вопрос связности на уровне приложений, большинство из которых используют либо непосредственно DNS для поиска IP-адресов, либо в качестве части URL (универсального локатора ресурсов) [29].

Теперь поднимемся по стеку протоколов выше, на уровень IP. Здесь мы имеем дело с таблицами маршрутизации. В простейшем виде такая таблица на хосте может быть заполнена при применении DHCP. Но заполнить таким образом таблицу маршрутизации шлюза представляется сложным.

Для этой цели используют протоколы обмена маршрутной информацией. Например, такие, как RIP. Протоколы базируются на алгоритмах, разработанных в своё время на основе алгоритма Форда-Фалкерсона для графовой модели.

Протокол RIP использует для обмена маршрутной информацией 520 порт UDP. Таблицы маршрутизации в первой версии протокола обновляются каждые 25-35 секунд – и за это время процесс формирования таблиц должен завершиться (сойтись, т.е. динамический граф конечен).

Протокол BGP4, в отличие от RIP и OSPF, которые относятся к типу протоколов «внутренней» маршрутизации, является протоколом «внешней» маршрутизации.

Собственно, в этом месте мы подобрались к ещё одному ограниченному ресурсу идентификаторов, распределение которого входит в понятие IANA-functions – это номера автономных систем.

Мы будем опираться на определение AS, которое дано в RFC1930 [30]: «Автономная система – это одна или несколько IP-сетей, которая управляется одним или несколькими операторами в соответствии с единственной чётко определённой политикой маршрутизации».

Собственно, в этом определении суть Интернета как сети автономных систем. «Внутренняя» маршрутизация – это маршрутизация IP-пакетов внутри автономной системы. «Внешняя» маршрутизация – это маршрутизация IP-пакетов между автономными системами.

В качестве графа в BGP рассматривается граф, где в качестве вершин выступают AS, а в качестве дуг – связи между ними.

Транспортным протоколом для сообщений BGP является протокол TCP (порт 179). Протокол обеспечивает проверку наличия связности между автономными системами, а по сути, между их маршрутизаторами. Если нельзя установить TCP-соединение, то и связности между системами нет.

Количество автономных систем растёт. Согласно данным проекта iddb.ru [31], всего IANA/PTI через RIR выделено 118 394 автономные системы. Из них для российских LIR выделено 5759, причём 5758 номеров выделено через RIPE, а один номер – через APNIC. При этом, по данным APNIC, активно используются 76 709 номеров AS [32]. Самой большой российской автономной системой является одна из автономных систем «Ростелекома» (ROSTELECOM-AS, 12389).

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

Рассмотрим только одну – DNS.

Domain Name System (DNS) – это ещё одна сторона IANA-функций. DNS обеспечивает независимость имени информационного ресурса в сети Интернет от IP-адреса. Да и запоминать доменные имена значительно проще, чем IP-адреса.

DNS – это распределённая информационная система, построенная вокруг протокола DNS [33].

Распределённая база данных DNS – это описание соответствий между доменными именами и идентификаторами информационных ресурсов; эту базу данных поддерживает множество авторитетных серверов.

Иерархический характер БД DNS определяется структурой доменных имён. Фрагмент этой иерархии представлен на рисунке 7.

Рис. 7. Фрагмент иерархии доменных имён.

Каждый узел этой иерархии поддерживается несколькими (не менее двух) авторитетными DNS-серверами. Задача этих серверов – хранить описание зоны домена и отвечать на запросы информации из этой зоны.

В качестве инструмента поиска в DNS используется распределённое множество кеширующих DNS-резолверов, которые осуществляют поиск запрошенного соответствия в БД DNS.

Зона домена в формате загрузки на авторитетный сервер – это файл, содержащий ресурсные записи. В ответ на запросы резолверов авторитетный сервер отдаёт соответствующий запросу список ресурсных записей. Если сервер этих записей не отдаст, то никакой связности не будет.

На уровне приложений количество идентификаторов, ответственных за связность, возрастает драматически. Каждый протокол, который стандартизирован в RFC, имеет свой набор. Приложения написаны разными людьми в разных компаниях, но за счёт открытых стандартов эти приложения оказываются совместимыми и работоспособными.

В качестве заключения

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

Совершенно очевидно, что никакой априорно заданной связности в сети Интернет нет. Её наличие обнаруживается только в тот самый момент, когда инициируется запрос на обслуживание в сети Интернет.

Кстати, о графах. World Wide Web – это тоже граф. Гипертекстовый.

Список литературы

1. ISO, 35.100, Open System Interconnection, https://www.iso.org/ics/35.100/x/
2. Д.И. Карпов, Теория графов, МЦНМО; ISBN: 978-5-4439-1690-3; 2022, https://logic.pdmi.ras.ru/~dvk/graphs_dk.pdf
3. Vinton G. Cerf and Robert E. Kahn, A Protocol for Packet Network Intercommunication, IEEE Trans on Comms, Vol Com-22, No 5 May 1974, https://www.cs.princeton.edu/courses/archive/fall06/cos561/papers/cerf74.pdf
4. IEEE, 802.3-2022 – IEEE Standard for Ethernet, https://ieeexplore.ieee.org/document/9844436
5. IEEE SA, Registration Authority, https://standards.ieee.org/products-programs/regauth/
6. David C. Plummer, RFC826 – An Ethernet Address Resolution Protocol – or – Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware, MIT-MC, 1982, https://datatracker.ietf.org/doc/html/rfc826
7. IEEE, Guidelines for 64-BIT Global Identifier (EUI-64) Registration Authority, https://web.archive.org/web/20100706041937/http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
8. R. Droms, RFC2131 – Dynamic Host Configuration Protocol, Bucknell University, 1997, https://datatracker.ietf.org/doc/html/rfc2131
9. DARPA, RFC791 Internet Protocol, 1981, https://datatracker.ietf.org/doc/html/rfc791
10. S. Deering, R. Hinden, RFC8200 – Internet Protocol Version 6 (IPv6) Specification, Check Point Software, 2017, https://datatracker.ietf.org/doc/html/rfc8200
11. J. Postel, RFC792 – Internet Control Message Protocol, 1981, https://datatracker.ietf.org/doc/html/rfc792
12. N. Narten, E. Nordmark, W. Simpson, H. Soliman, RFC4861 – Neighbor Discovery for IP version 6 (IPv6), 2007, https://datatracker.ietf.org/doc/html/rfc4861
13. W. Renner, RFC2236 – Internet Group Management Protocol, Version 2, Xerox PARC, 1997.
14. S. Kent, K. Seo, RFC4301 – Security Architecture for the Internet Protocol, BBN Technologies, 2005.
15. V. Fuller, T. Li, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan, 2006, https://datatracker.ietf.org/doc/html/rfc4632
16. IANA, https://www.iana.org/about/informational-booklet.pdf
17. B. Carpenter, F. Baker, V. Roberts, RFC2860 – Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority, IAB, IETF, ICANN, 2000, https://datatracker.ietf.org/doc/html/rfc2860
18. PTI, https://pti.icann.org/
19. R. Housley, J. Curran, G. Huston, D. Conrad, RFC7020 – The Internet Numbers Registry System, 2013, https://www.rfc-editor.org/rfc/rfc7020
20. RIPN, https://ripn.su/
21. IPv4 Market Group, Ipv4 Transfer Pricing, https://ipv4marketgroup.com/ipv4-pricing/
22. Google, IPv6, https://www.google.com/intl/en/ipv6/statistics.html
23. Храмцов Павел, Повторение – мать учения, или Конференция TLDCON 2024 (5-6 сентября 2024, Минск) Интернет изнутри, №21, стр. 34-41, https://www.ccni.ru/download/InternetInside/InternetInside_N21.pdf
24. RIGF, https://rigf.ru/
25. Telegram, https://core.telegram.org/mtproto/transports
26. I. Hickson, draft-hixie-thewebsocketprotocol-76, Google, Inc, 2010, https://datatracker.ietf.org/doc/html/draft-hixie-thewebsocketprotocol-76
27. W. Eddy, Ed, RFC9293 – Transmission Control Protocol (TCP), MTI Systems, 2022, https://datatracker.ietf.org/doc/html/rfc9293#handshake
28. R. Droms, RFC2131 – Dynamic Host Configuration Protocol, Bucknell University, 1997, https://datatracker.ietf.org/doc/html/rfc2131
29. T. Berners-Lee, R. Fielding, L. Masinter, RFC985 – Uniform Resource Identifier (URI): Generic Syntax, 2005, https://datatracker.ietf.org/doc/html/rfc3986
30. J. Hawkinson, N. Bates, RFC1930 – Guidelines for creation, selection, and registration of an Autonomous System (AS), MCI, 1996, https://datatracker.ietf.org/doc/html/rfc1930#section-3
31. Фонд «ИнДата», IDDB, https://www.ididb.ru/rir/
32. APNIC, https://thyme.apnic.net/current/data-summary
33. P. Mackapetris, RFC1035 – Domain Names – Implementation and Specification, ISI, 1987, https://datatracker.ietf.org/doc/html/rfc1035
34. IANA, Resource Record (RR) Types, https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4

Скачать статью: Связность и идентификаторы Интернета