Полный русский перевод · RFC2219

RFC2219 · Использование псевдонимов DNS для сетевых служб

Use of DNS Aliases for Network Services

Карточка документа · Архив принятого перевода · Официальный источник

Network Working Group                                        M. Hamilton
Request for Comments: 2219                       Loughborough University
BCP: 17                                                        R. Wright
Category: Best Current Practice             Lawrence Berkeley Laboratory
                                                            October 1997

                Использование псевдонимов DNS для сетевых служб

Этот документ определяет одну из лучших современных практик Интернета
   для интернет-сообщества и запрашивает обсуждение и предложения по
   улучшениям. Распространение этого меморандума не ограничено.

Стало обычной практикой использовать символические имена (как правило,
   CNAME) в службе доменных имён (DNS — [RFC-1034, RFC-1035]) для
   обращения к сетевым службам, таким как серверы анонимного FTP [RFC-959],
   серверы Gopher [RFC-1436] и, в особенности, серверы HTTP Всемирной
   паутины [RFC-1945]. Это желательно по ряду причин. Такой подход
   позволяет прозрачно переносить службы с одной машины на другую, а также
   предоставляет механизм, с помощью которого люди или агенты могут
   программно обнаружить, что организация, например, эксплуатирует сервер
   Всемирной паутины.

   Хотя этот подход был принят почти повсеместно, для этих часто
   используемых имён не существует документа стандартов или аналогичной
   спецификации. Этот документ стремится исправить эту ситуацию, собрав
   существующие «традиционные знания» о соглашениях по именованию, и
   предлагает механизм для учёта новых протоколов.

   Важно отметить, что эти соглашения по именованию не предоставляют
   полного долгосрочного решения проблемы поиска конкретной сетевой службы
   для сайта. В других рабочих группах IETF ведётся работа над долгосрочным
   решением этой проблемы, например работа над ресурсными записями
   расположения сервера (DNS SRV) [RFC-2052].

Для поиска сетевых служб, предлагаемых в конкретном домене Интернета,
   приходится выбирать между растущим числом централизованных баз данных —
   обычно Web- или Usenet News-«странников» — либо пытаться вывести
   существование сетевых служб из любой доступной информации DNS. Первый
   подход в некоторых случаях непрактичен, в особенности когда сведения о
   службе ищет программа.

   Возможно, наиболее заметный пример работы последнего подхода — случай
   серверов HTTP Всемирной паутины. Обычной практикой является попытка
   добавить к доменному имени организации префикс "http://www.", чтобы
   попасть на её сайт Всемирной паутины, например взять "hivnet.fr" и
   получить "http://www.hivnet.fr." Некоторые популярные браузеры
   Всемирной паутины зашли настолько далеко, что обеспечивают
   автоматическую поддержку такого развёртывания доменного имени.

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

   Первый случай — когда DNS уже предоставляет возможность поиска для типа
   искомой информации. Например: записи Mail Exchanger (MX) определяют,
   как должна маршрутизироваться почта для конкретного домена [RFC-974],
   записи Start of Authority (SOA) позволяют определить, кто отвечает за
   данный домен, а записи Name Server (NS) указывают, какие хосты
   предоставляют службу имён DNS для данного домена.

   Второй случай — когда DNS не предоставляет подходящей возможности
   поиска, но существует некоторое широко принятое соглашение для поиска
   этой информации. В этом сценарии некоторое применение нашли записи Text
   (TXT) [RFC-1035], но в подавляющем большинстве случаев для указания
   хоста или хостов, предоставляющих службу, используется указатель записи
   Canonical Name (CNAME) или Address (A). Этот документ предлагает
   небольшую формализацию этого хорошо известного подхода с псевдонимами.

   Следует отметить, что DNS предоставляет возможность поиска Well Known
   Services (WKS) [RFC-1035], позволяющую определить сетевые службы,
   предлагаемые для данного доменного имени. На практике она широко не
   используется, возможно из-за отсутствия подходящего программного
   интерфейса. Использование WKS для маршрутизации почты было объявлено
   устаревшим в спецификации требований к хостам [RFC-1123] в пользу записи
   MX, и в долгосрочной перспективе возможно, что записи SRV заменят как
   WKS, так и MX.

Наш подход к работе с псевдонимами протоколов прост. Мы определяем
   стандартный набор псевдонимов DNS для наиболее популярных существующих
   в настоящее время сетевых служб (см. ниже раздел «Особые случаи»). Для
   протоколов, которые явно не перечислены в этом документе, спецификация
   протокола должна предложить имя.

Особые случаи:
        -----------------------------------------------------------
        Псевдоним Служба
        -----------------------------------------------------------
        archie    archie [ARCHIE]
        finger    Finger [RFC-1288]
        ftp       File Transfer Protocol [RFC-959]
        gopher    Internet Gopher Protocol [RFC-1436]
        ldap      Lightweight Directory Access Protocol [RFC-1777]
        mail      SMTP mail [RFC-821]
        news      Usenet News via NNTP [RFC-977]
        ntp       Network Time Protocol [RFC-1305]
        ph        CCSO nameserver [PH]
        pop       Post Office Protocol [RFC-1939]
        rwhois    Referral WHOIS [RFC-1714]
        wais      Wide Area Information Server [RFC-1625]
        whois     NICNAME/WHOIS [RFC-954]
        www       World-Wide Web HTTP [RFC-1945]
        -----------------------------------------------------------

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

   Реализаторам следует понимать, что существование записи DNS вида

        www.hivnet.fr

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

   Сказав это, псевдонимы всё же предоставляют полезные «подсказки» о
   предлагаемых службах. Мы предлагаем воспринимать их именно в этом духе.

   Соглашения, описанные в этом документе, по существу полезны только тогда,
   когда можно определить доменное имя организации — например, из некоторой
   внешней базы данных. Ряд групп, включая IETF, работают над способами
   поиска доменных имён по набору информации, такой как название
   организации, местоположение и тип деятельности. Есть надежда, что одно
   или несколько таких решений в конечном итоге позволят дополнить базовую
   службу поиска, предоставляемую DNS, более обобщённой возможностью поиска
   и извлечения.

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

   Существуют два традиционных подхода к созданию этих записей DNS. Один из
   них состоит в добавлении единственной записи CNAME в конфигурацию вашего
   DNS-сервера, например:

        ph.hivnet.fr. IN CNAME baby.hivnet.fr.

   Обратите внимание, что в этом сценарии в DNS не следует размещать
   никакой информации о ph.hivnet.fr, кроме записи CNAME. Например,
   ph.hivnet.fr не мог бы содержать запись MX.

   Альтернативный подход состоял бы в создании записи A для каждого из
   IP-адресов, связанных с ph.hivnet.fr, например:

        ph.hivnet.fr. IN A 194.167.157.2

   Нельзя просто рекомендовать CNAME вместо записей A. У каждого сайта есть
   собственный набор требований, вследствие которого один подход может быть
   лучше другого. RFC 1912 [RFC-1912] обсуждает некоторые вопросы
   конфигурации, связанные с использованием CNAME.

   Последние реализации DNS-серверов предоставляют функцию «round-robin»,
   из-за которой IP-адреса хоста возвращаются в разном порядке при каждом
   поиске адреса.

   Начинают появляться сетевые клиенты, которые, встретив хост с
   несколькими адресами, используют эвристики для определения адреса, с
   которым следует установить связь, например выбирают адрес с наименьшим
   временем кругового прохода. Таким образом, если сервер зеркалируется
   (реплицируется) в нескольких местах, может быть желательно перечислить
   IP-адреса зеркальных серверов как записи A основного сервера. Это, скорее
   всего, подходит только в том случае, если зеркальные серверы являются
   точными копиями исходного сервера.

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

В настоящее время в общем употреблении находятся по меньшей мере три
   различных псевдонима для сервера имён CCSO, например "ph", "cso" и
   "ns". Представляется, что в интересах всех было бы сузить выбор
   псевдонима до одного имени. "ns", по-видимому, был бы наилучшим выбором,
   поскольку это наиболее часто используемое имя. Однако "ns" также
   используется DNS для указания на DNS-сервер. Фактически наиболее
   распространённое использование "ns" — именование DNS-серверов. По этой
   причине мы предлагаем использовать "ph" как лучшее имя для серверов
   имён CCSO.

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

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

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

   Ведётся работа по исправлению этой ситуации в той мере, в какой она
   касается DNS [RFC-2065]. Тем временем следует отметить, что более
   сильные механизмы аутентификации, такие как криптография с открытым
   ключом при больших размерах ключей, являются необходимой предпосылкой,
   если DNS используется в каких-либо чувствительных ситуациях. Примерами
   этого служат финансовые операции в режиме онлайн и любая ситуация, где
   важна приватность, — например запрос медицинских записей по сети. Для
   защиты от «захвата» TCP-соединений и сниффинга (пассивного анализа)
   пакетов также может быть целесообразно криптографически стойкое
   шифрование сетевого трафика.

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

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

Благодарим Jeff Allen, Tom Gillman, Renato Iannella, Thomas
   Lenggenhager, Bill Manning, Andy Powell, Sri Sataluri, Patrik
   Faltstrom, Paul Vixie и Greg Woods за их комментарии к черновым версиям
   этого документа.

   Эта работа была поддержана грантом 12/39/01 программы UK Electronic
   Libraries Programme (eLib), грантом RE 1004 программы Telematics for
   Research Европейской комиссии и контрактом Министерства энергетики США
   номер DE-AC03-76SF00098.

Документы Request For Comments (RFC) доступны по адресу
   <URL:ftp://ftp.internic.net/rfc> и на многочисленных зеркальных сайтах.

   [ARCHIE]    A. Emtage, P. Deutsch. "archie - An Electronic
               Directory Service for the Internet", Winter Usenix
               Conference Proceedings 1992.  Pages 93-110.


[PH]        R. Hedberg, S. Dorner, P. Pomes.  "The CCSO
            Nameserver (Ph) Architecture", Work in Progress.

[RFC-768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
            August 1980.

[RFC-793]   Postel, J., "Transmission Control Protocol", STD 7,
            RFC 793, September 1981.

[RFC-821]   Postel, J., "Simple Mail Transfer Protocol", STD 10,
            RFC 821, August 1982.

[RFC-954]   Harrenstien, K., Stahl, M., and E. Feinler,
            "NICNAME/WHOIS", RFC 954, October 1985.

[RFC-959]   Postel, J., and J.K. Reynolds, "File Transfer
            Protocol", STD 9, RFC 959, October 1985.

[RFC-974]   Partridge, C., "Mail routing and the domain
            System", STD 14, RFC 974,  January 1986.

[RFC-977]   Kantor, B., and P. Lapsley, "Network News Transfer
            Protocol", RFC 977, February 1986.

[RFC-1034]  Mockapetris, P., "Domain names - concepts and
            facilities", STD 13, RFC 1034, November 1987.

[RFC-1035]  Mockapetris, P., "Domain names - implementation
            and specification", STD 13, RFC 1035, November 1987.

[RFC-1123]  Braden, R., "Requirements for Internet hosts -
            application and support", STD 3, RFC 1123, October 1989.

[RFC-1288]  Zimmerman, D., "The Finger User Information
            Protocol", RFC 1288, December 1992.

[RFC-1305]  Mills, D., "Network Time Protocol (Version 3)
            Specification, Implementation", RFC 1305,  March  1992.

[RFC-1436]  Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
            Torrey, D., and B. Albert, "The Internet Gopher Protocol
            (a distributed document search and retrieval protocol)",
            RFC 1436, March 1993.

[RFC-1590]  Postel, J., "Media Type Registration Procedure",
            RFC 1590, March 1994.

[RFC-1625]  St. Pierre, M., Fullton, J., Gamiel, K., Goldman, J.,
            Kahle, B., Kunze, J., Morris, H., and F. Schiettecatte,
            "WAIS over Z39.50-1988", RFC 1625, June 1994.

[RFC-1700]  Reynolds, J.K., and J. Postel,  "ASSIGNED NUMBERS",
            STD 2, RFC 1700, October 1994.

[RFC-1714]  Williamson, S., and M. Kosters, "Referral Whois
            Protocol (RWhois)", RFC 1714, November 1994.

[RFC-1777]  Yeong, W., Howes, T., and S. Kille, "Lightweight
            Directory Access Protocol", RFC 1777, March 1995.

[RFC-1912]  Barr, D., "Common DNS Operational and Configuration
            Errors", RFC 1912, Feburary 1996.

[RFC-1939]  Myers, J., and M. Rose, "Post Office Protocol - Version
            3", STD 53, RFC 1939, May 1996.

[RFC-1945]  Berners-Lee, T., Fielding, R., and H. Nielsen,
            "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May
            1996.

[RFC-2052]  Gulbrandsen, A., and P. Vixie, "A DNS RR for specifying
            the location of services (DNS SRV)", RFC 2052, October
            1996.

[RFC-2065]  Eastlake, D., and C. Kaufman, "Domain Name System
            Security Extensions", RFC 2065, January 1997.

Martin Hamilton
Department of Computer Studies
Loughborough University of Technology
Leics. LE11 3TU, UK

EMail: m.t.hamilton@lut.ac.uk

Russ Wright
Information & Computing Sciences Division
Lawrence Berkeley National Laboratory

Mail-Stop: 50A-3111
CA 94720, USA

EMail: wright@lbl.gov