RFC 799 | Домены Имен Интернета

Оглавление

1. Введение
2. Общая топология
3. Соглашения об именах
4. Принципы почтовой транспортировки
5. Экспедиторские операции
6. Источник и обратная маршрутизация
7. Редактирование заголовка RFC-733
8. Заключительные замечания

 

1. Введение

В конечном счете, для каждого интернет-хоста будет непрактично включать все интернет-хосты в свои таблицы имен и адресов. Даже сейчас с более чем четырьмя сотнями имен и псевдонимов в комбинированных таблицах ARPANET-DCNET это стало неудобным. Некоторый вид иерархического разделения пространства имен может быть легко разработан для решения этой проблемы; тем не менее, было чрезвычайно трудно найти одну, совместимую с известными почтовыми системами в сообществе. Один из предложенных здесь является продуктом нескольких дискуссий и встреч и считается совместимым с существующими системами и расширяемым для будущих систем с участием тысяч хостов.

Скачать оригинальный документ на английском языке RFC 799 PDF

 

2. Общая топология

Сначала мы заметим, что каждый интернет-хост однозначно идентифицируется одним или несколькими 32-битными интернет-адресами и что вся система полностью подключена. На данный момент проблема совместимости протокола будет проигнорирована, так что все хосты могут считаться MTP-компетентными. Затем мы накладываем топологическое покрытие на пространство всех интернет-адресов с набором так называемых доменов имен. В естественной модели домены имен будут соответствовать учреждениям, таким как ARPA, UCL и COMSAT, и не обязательно будут непересекающимися или полными. Хотя в принципе домены имен могут быть иерархически структурированы, в дальнейшем мы будем предполагать только одноуровневую структуру.

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

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

 

3. Соглашения об именах

В наиболее общем виде стандартное имя почтового ящика в Интернете имеет синтаксис

<user>.<host>@<domain>

где <user> — это имя пользователя, известного на хосте <host> в домене имен <domain>. Этот синтаксис предназначен для того, чтобы предложить трехуровневое иерархически структурированное имя (чтение справа), которое является уникальным во всей интернет-системе. Однако хосты в пределах одного домена могут согласиться принять другую структуру, если это не противоречит приведенному выше синтаксису и пока серверы пересылки для этого домена готовы выполнить необходимые преобразования. Например, пусть имя домена, включая DCNET, будет COMSAT, а имя одного из его хостов — COMSAT-DLM, а Mills — пользователь, известный этому хосту. В домене COMSAT имя Mills @ COMSAT-DLM однозначно идентифицирует этот почтовый ящик, как, например, имя Mills.COMSAT-DLM@COMSAT из любой точки системы Интернета. Однако Mills @ COMSAT-DLM не обязательно имеет смысл где-либо за пределами домена COMSAT (но это может быть так).

Типичный набор доменов имен, охватывающих текущую интернет-систему, может включать ARPA (ARPANET), COMSAT (DCNET), DCA (EDNET, WBNET), UCL (UCLNET, RSRENET, SRCNET), MIT (CHAOSNET), INTELPOST (INTELPOSTNET) и различные публичные сети передачи данных. Сервер пересылки ARPA будет использовать таблицу «имя-адрес», созданную на основе последней версии таблицы HOSTS.TXT в базе данных NIC. Другие экспедиторы построят свои собственные, но ожидается, что они разместят копию в базе данных NIC.

 

4. Принципы почтовой транспортировки

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

Есть несколько причин, по которым некоторые сообщения должны быть размещены на промежуточном ретрансляторе, среди них следующие:

1. Хосты отправителя и получателя могут быть невозможны или не удобны для одновременного подключения к интернет-системе на время передачи.
2. Хост-отправитель может не располагать ресурсами для выполнения всех необходимых преобразований имя-адрес.
3. Путь прямого соединения может оказаться невозможным из-за нормативных экономических ограничений или ограничений безопасности.
4. Хосты отправителя и получателя могут не распознавать один и тот же транспортный протокол нижнего уровня (например, TCP и NCP).

Ретрансляция почты — это интернет-процесс, оборудованный для хранения сообщения MTP для последующей передачи. Пересылка почты — это пересылка почты, но не все пересылки являются пересылками, поскольку они могут не включать в себя возможность полного имени-адреса, необходимую для пересылки. Кроме того, ретрансляторы могут быть не компетентны во всех областях. Например, ретранслятор MTP / TCP может не понимать NCP. Другими словами, серверы пересылки должны быть полностью подключены, а реле — нет.

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

1. Ожидается, что консультативные сообщения, возвращенные отправителю узлом-ретранслятором или узлом получателя, будут проходить маршрут в обратном порядке.
2. Имена хостов ретрансляции следуют тем же правилам именования, что и все имена хостов, относящиеся к их домену. Поскольку может быть невозможно (см. Ниже) использовать интернет-адреса для устранения неоднозначности домена, полное стандартное интернет-имя. <Host> @ <domain> требуется везде.
3. В настоящее время нет положений о строгих / свободных маршрутах. Если бы фактически использовалась «обычная» спецификация хоста @ <host>, каждый ретранслятор или сервер пересылки использовали бы правила, описанные в следующем разделе, для маршрутизации. Это может привести к дополнительным переходам реле.

 

5. Экспедиторские операции

В этом разделе описывается вероятный сценарий с участием хостов, ретрансляторов и серверов пересылки и типичных интернет-маршрутов. Когда сервер пересылки получает сообщение для <user>. <Host> @ <domain>, при необходимости он преобразует <host> и перенаправляет сообщение по адресу, указанному в таблице «имя-адрес» для <domain>. Обратите внимание, что один хост может быть пересылкой для нескольких независимых доменов в этой модели и что эти домены могут пересекаться. Таким образом, имена Mills @ USC-ISIE, Mills.USC-ISIE@ARPA и Mills.USC-ISIE@COMSAT могут относиться к одному и тому же почтовому ящику, а имена USC-ISIE, ARPA и COMSAT, возможно, все известны в тот же домен. Такое использование будет допустимо только в том случае, если имя USC-ISIE не конфликтует с другими именами в этом домене.

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

В модели RFC-780 сообщение, поступающее на сервер пересылки, обрабатывается сервером MTP. Сервер извлекает первую запись в поле маршрута получателя команды MRCP. Есть два случая, в зависимости от того, указывает ли эта запись имя домена или имя хоста. Если доменное имя, определенное поиском в универсальной таблице, относится к одному из доменов, которые представляет сервер. В противном случае это должно быть имя или псевдоним хоста сервера относительно ooe доменов, к которым принадлежит отправитель. Это позволяет проводить различие между доменами COMSAT и INTELPOST, с одной стороны, и COMSAT-хостом COMSAT, с другой, которые могут быть представлены одним и тем же интернет-адресом, и подразумевает, что доменные имена должны быть уникальными во всех доменах.

Затем сервер извлекает вторую запись в поле маршрута получателя команды MRCP и разрешает его адрес относительно домена, установленного первой записью. Если вторая запись указывает явный домен, то она переопределяет первую запись. Если нет, и первая запись указывает домен, то этот домен действует. Однако, если первая запись указывает хост сервера, может быть неясно, какой домен предназначен. Например, рассмотрим следующие две команды MRCP:

MRCP to:<@COMSAT,Mills@HOST> and MRCP to:<@INTELPOST,Mills@HOST>

где Mills.HOST@COMSAT и Mills.HOST@INTELPOST — это отдельные почтовые ящики на разных хостах. Принимающий хост, поддерживающий серверы пересылки для COMSAT и INTELPOST, может затем сохранить это различие и правильно переадресовать, используя приведенные выше правила.

Теперь пусть хост-сервер пересылки имеет имя FORWARDER в доменах COMSAT и INTELPOST и учитывает его параметры при получении команды

MRCP to:<@FORWARDER,Mills@HOST>

Экспедитору предлагается просто выполнить ретрансляцию в домене отправителя; однако он принадлежит более чем одному домену! Очевидный способ решить эту проблему — запретить использование неявных доменов, представленных Mills @ HOST, и требовать полные имена почтовых ящиков в Интернете Mills.HOST@COMSAT или Mills.HOST@INTELPOST. Также можно устранить неоднозначность домена, проверив первую запись поля sender-route команды MAIL (см. Ниже).

 

6. Источник и обратная маршрутизация

В модели RFC-780 маршруты можно указывать в поле получателя-маршрута команды MRCP и в поле маршрута-отправителя команды MAIL. На самом деле, ни маршрут получателя, ни маршрут отправителя не нужны, если отправитель указывает стандартные имена почтовых ящиков в Интернете. Пока маршруты, когда они используются, состоят только из доменных имен, нет конфликта с текущей спецификацией RFC-780. Если по какой-либо причине переадресация должна выполняться через другие узлы, необходимо использовать полный и однозначный синтаксис, например. <Host> @ <domain>, чтобы избежать проблем, подобных описанным выше.

Настоящая спецификация RFC-780 требует, чтобы получатель создал имя отправителя и вставил его в начале маршрута отправителя. Предположительно, единственная информация, которую он имеет для построения этого имени, — это интернет-адрес отправителя. Рассмотрим случай, как в примере выше, когда несколько доменов поддерживаются одним сервером на конкретном хосте. Если хосты, получающие сообщение, ретранслируемое через этот сервер, должны были сопоставить его адрес с именем, невозможно было бы определить, какой домен был предназначен. Мы заключаем, что хост-отправитель должен обновить маршрут отправителя, а также маршрут получателя. Это делается путем простого копирования первой записи в маршруте получателя, полученной в качестве новой первой записи в маршруте отправителя.

 

7. Редактирование заголовка RFC-733

Следует приложить все усилия, чтобы избежать редактирования заголовка RFC-733, поскольку это инвазивная процедура, требующая тщательного анализа. Ожидается, что недавно разработанные почтовые системы будут знать о стандартном синтаксисе почтовых ящиков в Интернете и обеспечат его использование повсюду в полях RFC-733 и RFC-780. В тех случаях, когда это невозможно, например, во многих современных хостах ARPANET, необходимо выполнить необходимое редактирование при первом входе в почтовую систему Интернета из локальной почтовой системы. Это позволяет избежать проблем, упомянутых выше, и упрощает функции ответа.

В случае хостов ARPANET операции редактирования предполагают, что все имена в форме <anything>@<domain>, где <domain> — это имя домена, не изменены. Имена в форме <anything>@<host>, где <хост> — это имя хоста в домене ARPA, преобразуются в форму <что-нибудь>. <Хост> @ARPA. Все остальное является ошибкой. Перед передачей в почтовую программу ARPANET NCP, ARPA MTP-сервер пересылки может при желании преобразовать <что-нибудь>. <Хост> @ARPA в <что-нибудь> @ <хост>, чтобы уменьшить трафик сервера пересылки, когда доступны локальные почтовые системы. Подобные ситуации могут существовать в другом месте.

 

8. Заключительные замечания

Этот меморандум призван стимулировать обсуждение, а не имитировать его.

 

Автор документа

D. L. Mills, COMSAT Laboratories

 

Дата выпуска документа

Сентябрь 1981 года