Аннотация
Система доменных имен (DNS) предоставляет важную услугу в Интернете, сопоставляя структурированные имена с различными данными, обычно с IP-адресами. Эти имена появляются в адресах электронной почты, универсальных идентификаторах ресурсов (URI) и других идентификаторах прикладного уровня, которые часто предоставляются пользователям. В связи с этим возникла серьезная потребность в приобретении имен, которые имеют значение для людей, благодаря их эквивалентности зарегистрированным товарным знакам, названиям компаний, типам услуг и т. д. В этой тенденции есть опасность; люди и автоматы, которые потребляют и используют такие имена, будут связывать определенную семантику с некоторыми именами и тем самым делать предположения об услугах, которые предоставляются или должны предоставляться хостами, связанными с именами. Эти предположения часто могут быть ложными, что приводит к различным условиям отказа. Этот документ обсуждает эту проблему более подробно и дает рекомендации о том, как ее можно избежать.
Скачать оригинальный документ на английском языке RFC 4367 PDF
Оглавление
1. Введение
2. Целевая аудитория
3. Моделирование использования DNS
4. Возможные предположения
4.1. Пользователем
4.2. Клиентом
4.3. Сервером
5. Последствия ложных предположений
6. Причины, почему предположения могут быть ложными
6.1. Эволюция
6.2. Просачивание
6.3. Передоверие
6.4. Мобильность
6.5. Человеческая ошибка
7. Рекомендации
8. Примечание к RFC 2219 и RFC 2782
9. Вопросы безопасности
10. Благодарности
11. Члены IAB
12. Информационные ссылки
Статус этой заметки
Эта памятка содержит информацию для интернет-сообщества. Он не определяет интернет-стандарт любого вида. Распространение этой заметки не ограничено.
Уведомление об авторских правах
Copyright (C) Интернет-общество (2006).
1. Введение
Система доменных имен (DNS) [1] предоставляет важную услугу в Интернете, сопоставляя структурированные имена с различными типами данных. Чаще всего он используется для получения IP-адреса хоста, связанного с этим именем [2] [1] [3]. Тем не менее, он может быть использован для получения другой информации, и предложения были сделаны практически для всего, в том числе географической информации [4].
Доменные имена чаще всего используются в идентификаторах, используемых прикладными протоколами. Наиболее известными являются адреса электронной почты и URI, такие как URL-адрес HTTP [5], URL-адрес протокола потоковой передачи в реальном времени (RTSP) [6] и URI SIP [7]. Эти идентификаторы вездесущи и встречаются на визитных карточках, веб-страницах, уличных указателях и т. Д. В связи с этим возникла серьезная потребность в приобретении доменных имен, которые имеют значение для людей благодаря их эквивалентности зарегистрированным товарным знакам, названиям компаний, типам услуг и т. Д. Такие идентификаторы служат многим деловым целям, включая расширение бренда, рекламу и т. д.
Люди часто делают предположения о типе услуги, которая предоставляется или должна быть предоставлена хостом, связанным с этим именем, исходя из их ожиданий и понимания того, что подразумевается под именем. Это, в свою очередь, инициирует попытки организаций зарегистрировать доменные имена на основе этого предполагаемого ожидания пользователя. Примерами этого являются различные предложения для домена верхнего уровня (TLD), которые могут быть связаны с контентом для взрослых [8], запросы на создание TLD, связанные с мобильными устройствами и услугами, и даже фишинговые атаки.
Когда эти предположения кодифицируются в поведение автомата, такого как клиент приложения или сервер, в результате выбора разработчика, директивы управления или политики владельца домена, вся система может выйти из строя различными способами. В этом документе описан ряд типичных способов кодификации этих предположений, как они могут быть ошибочными, последствия этих ошибок и рекомендуемые способы их предотвращения.
Раздел 4 описывает некоторые из возможных предположений, которые клиенты, серверы и люди могут сделать относительно доменного имени. В этом контексте «предположение» определяется как любое поведение, которое ожидается при доступе к сервису по имени домена, даже если это поведение явно не кодифицировано в спецификациях протокола. Часто эти допущения включают игнорирование частей спецификации, основанных на предположении, что клиент или сервер развернут в среде, более жесткой, чем допускает спецификация. Раздел 5 содержит обзор некоторых последствий этих ложных предположений. Вообще говоря, эти последствия могут включать множество различных сбоев взаимодействия, сбоев взаимодействия с пользователем и сбоев системы. В разделе 6 обсуждается, почему эти предположения могут быть ложными с самого начала или стать ложными в какой-то момент в будущем. Чаще всего они становятся ложными, потому что среда со временем меняется неожиданным образом, и то, что раньше было верным предположением, уже не существует. В других случаях предположения оказываются неверными, потому что они основаны на убеждении, что в нем участвует определенное сообщество клиентов и серверов, и элемент вне этого сообщества начал участвовать.
Раздел 7 затем предоставляет некоторые рекомендации. Эти рекомендации включают в себя некоторые технические мантры, которые лежали в основе разработки протоколов Интернета на протяжении десятилетий. Они включают:
- Следуйте спецификации.
- Используйте методы согласования возможностей, представленные в протоколах.
- Будьте либеральны в том, что вы принимаете, и консервативны в том, что вы посылаете. [18]
В целом, автоматы не должны изменять свое поведение в рамках протокола на основе доменного имени или некоторого компонента доменного имени хоста, с которым они общаются.
2. Целевая аудитория
Этот документ имеет несколько аудиторий. Во-первых, оно предназначено для разработчиков, которые в конечном итоге разрабатывают программное обеспечение, которое делает ложные предположения, которые являются предметом этого документа. Описанные здесь рекомендации призваны усилить технические рекомендации, которые часто понимаются разработчиками, но часто забываются при приближении сроков и повышении давления.
Документ также предназначен для менеджеров по технологиям, которые часто разрабатывают требования, которые приводят к этим ложным предположениям. Для них этот документ служит средством для подчеркивания важности отказа от ярлыков в рамках применимости проекта.
Наконец, этот документ предназначен для политиков и администраторов доменных имен. Для них это указывает на опасности в создании доменных политик, которые кодифицированы в работу приложений, работающих в этом домене.
3. Моделирование использования DNS
На рисунке 1 показана простая концептуальная модель использования DNS приложениями. Пользователь приложения получает идентификатор для конкретного контента или услуги, которые он желает получить. Этот идентификатор часто является URL или URI, который содержит имя домена. Пользователь вводит этот идентификатор в свое клиентское приложение (например, вводя URL-адрес в окне веб-браузера). Клиент — это автомат (программная и / или аппаратная система), который связывается с сервером для этого приложения, чтобы предоставлять обслуживание пользователю. Для этого он связывается с DNS-сервером, чтобы преобразовать имя домена в идентификаторе в IP-адрес. Затем он связывается с сервером по этому IP-адресу. Эта простая модель применяется к прикладным протоколам, таким как HTTP [5], SIP [7], RTSP [6] и SMTP [9].
Из этой модели ясно, что три объекта в системе могут потенциально делать ложные предположения об услуге, предоставляемой сервером. Пользователь-человек может сформировать ожидания, относящиеся к контенту услуги, на основе анализа имени хоста, из которого был получен контент. Сервер может предположить, что клиент, подключающийся к нему, поддерживает протоколы, которые он не поддерживает, может обрабатывать контент, который он не может, или имеет возможности, которые у него нет. Точно так же клиент может предположить, что сервер поддерживает протоколы, контент или возможности, которые он не поддерживает. Кроме того, приложения могут потенциально содержать множество людей, клиентов и серверов, каждый из которых может независимо делать эти ложные предположения.
4. Возможные предположения
Для каждого из трех элементов существует множество ложных предположений.
4.1. Пользователем
Множество возможных предположений здесь почти безгранично. Пользователи могут предположить, что URL-адрес HTTP, который выглядит как название компании, сопоставляется с сервером, управляемым этой компанией. Они могут предположить, что электронное письмо с адреса электронной почты в домене .gov на самом деле принадлежит государственному служащему. Они могут предположить, что контент, полученный с веб-сервера внутри ДВУ, помеченного как содержащий материалы для взрослых (например, .sex), на самом деле содержит контент для взрослых [8]. Эти предположения неизбежны, все они могут быть ложными и не являются предметом данного документа.
4.2. Клиентом
Несмотря на то, что клиент является автоматом, он может делать некоторые из тех же предположений, что и человек-пользователь. Например, многие клиенты предполагают, что любой хост с именем хоста, начинающимся с «www», является веб-сервером, даже если это предположение может быть ложным.
Кроме того, клиент интересуется протоколами, необходимыми для связи с сервером. В результате он может делать предположения о работе протоколов для связи с сервером. Эти допущения проявляются в реализации, когда игнорируется стандартизированная методика согласования протокола, определяемая протоколом, и вместо этого в программное обеспечение кодируется некое правило, которое приходит к собственному заключению о том, что согласование определило бы. Результатом часто является потеря функциональной совместимости, снижение надежности и ухудшение пользовательского опыта.
Алгоритм аутентификации (Authentication Algorithm): хотя протокол может поддерживать множество методов аутентификации, клиент может предположить, что сервер всегда поддерживает тот, который является необязательным в соответствии с протоколом. Например, клиент SIP, связывающийся с сервером SIP в домене, который, очевидно, используется для идентификации мобильных устройств (например, www.example.cellular), может предположить, что сервер поддерживает дополнительную методику дайджеста аутентификации и соглашения о ключах (AKA) [10 ], только из-за доменного имени, которое использовалось для доступа к серверу. В качестве другого примера, веб-клиент может предположить, что сервер с именем https.example.com поддерживает HTTP через безопасность транспортного уровня (TLS) [16].
Форматы данных (Data Formats): хотя протокол может позволять отправлять множество форматов данных с сервера на клиент, клиент может использовать определенный формат, а не использовать возможности маркировки содержимого и согласования базового протокола. Например, клиент RTSP может предполагать, что весь аудиоконтент, доставленный ему из media.example.cellular, использует кодек с низкой пропускной способностью. В качестве другого примера, почтовый клиент может предположить, что содержимое сообщений, которые он извлекает с почтового сервера по адресу mail.example.cellular, всегда является текстовым, вместо проверки заголовков MIME [11] в сообщении для определения фактического типа содержимого.
Расширения протокола (Protocol Extensions): клиент может попытаться выполнить операцию на сервере, которая требует от сервера поддержки дополнительного расширения протокола. Однако вместо реализации необходимой резервной логики клиент может ошибочно предположить, что расширение поддерживается. Например, клиент SIP, который требует надежных предварительных ответов на свой запрос (RFC 3262 [17]), может предположить, что это расширение поддерживается на серверах в домене sip.example.telecom. Кроме того, клиент не будет реализовывать резервное поведение, определенное в RFC 3262, так как он будет предполагать, что все серверы, с которыми он будет связываться, находятся в этом домене и поэтому все поддерживают это расширение. Однако, если предположения окажутся неверными, клиент не сможет совершать какие-либо телефонные звонки.
Языки (Languages): клиент может поддерживать средства для обработки текстового содержимого по-разному в зависимости от языка текста. Вместо того, чтобы определять язык по маркерам в сообщении от сервера, клиент может использовать язык, основанный на имени домена. Это предположение может быть легко ошибочным. Например, клиент может предположить, что любой текст на веб-странице, полученный с сервера внутри домена верхнего уровня .de (ccTLD), написан на немецком языке, и попытаться выполнить перевод на финский язык. Это резко не сработало бы, если бы текст был на французском языке. К сожалению, такое поведение клиента иногда проявляется, потому что сервер не правильно пометил язык содержимого, во-первых, часто потому, что сервер полагал, что такая маркировка не нужна. Это пример того, как эти ложные предположения могут создавать порочные циклы.
4.3. Сервером
Сервер, как и клиент, является автоматом. Давайте рассмотрим один обслуживающий конкретный домен — например, www.company.cellular. Можно предположить, что все клиенты, подключающиеся к этому домену, поддерживают определенные возможности, а не используют базовый протокол для такого определения. Вот некоторые примеры:
Алгоритм аутентификации (Authentication Algorithm): сервер может предположить, что клиент поддерживает определенный, дополнительный, метод аутентификации, и поэтому он не поддерживает обязательный метод.
Язык (Language): сервер может обслуживать контент на определенном языке, исходя из предположения, что клиенты, обращающиеся к домену, говорят на определенном языке, или исходя из предположения, что клиенты, приходящие с определенного IP-адреса, говорят на определенном языке.
Форматы данных (Data Formats): сервер может предполагать, что клиент поддерживает определенный набор типов MIME и способен отправлять только те из них, которые находятся в этом наборе. Когда он генерирует контент в ответе протокола, он игнорирует любые заголовки согласования контента, которые присутствовали в запросе. Например, веб-сервер может игнорировать поле заголовка HTTP Accept и отправлять определенный формат изображения.
Расширения протокола (Protocol Extensions): сервер может предполагать, что клиент поддерживает определенное необязательное расширение протокола, и поэтому он не поддерживает резервное поведение, необходимое в случае, когда клиент не поддерживает.
Характеристики клиента (Client Characteristics). Сервер может принимать определенные данные о физических характеристиках своих клиентов, таких как объем памяти, вычислительная мощность, размеры экрана, цвета экрана, указывающие устройства и т. д. Исходя из этих предположений, он может выбирать конкретные варианты поведения при обработке запроса. Например, веб-сервер может всегда предполагать, что клиенты подключаются через сотовые телефоны, и, следовательно, возвращать контент, в котором отсутствуют изображения и который настроен для таких устройств.
5. Последствия ложных предположений
Существует множество отрицательных результатов, которые могут возникнуть из-за ложных предположений, которые могут сделать пользователи, серверы и клиенты. Они включают:
Сбой взаимодействия (Interoperability Failure): в этих случаях клиент или сервер предполагали какую-то операцию протокола, и это предположение было неверным. В результате они не могут общаться, и пользователь получает какую-то ошибку. Это представляет собой полный сбой взаимодействия, который проявляется в недостатке обслуживания пользователей системы. К сожалению, этот вид сбоя сохраняется. Повторные попытки со временем клиента получить доступ к сервису потерпят неудачу. Только изменение в программном обеспечении сервера или клиента может решить эту проблему.
Отказ системы (System Failure): в этих случаях клиент или сервер неверно истолковали операцию протокола, и эта неверная интерпретация была достаточно серьезной, чтобы обнаружить ошибку в реализации. Ошибка приводит к сбою системы или некоторому сбою, либо временному, либо постоянному (до сброса пользователя). Если этот сбой происходит на сервере, подключающийся клиент не только потеряет обслуживание, но и другие клиенты, пытающиеся подключиться, не получат обслуживание. Например, если веб-сервер предполагает, что контент, передаваемый ему от клиента (созданный, например, цифровой камерой), имеет определенный тип контента, и он всегда передает контент изображения в кодек для распаковки перед хранением, кодек может дать сбой, когда он неожиданно получает изображение, сжатое в другом формате. Конечно, это может привести к сбою, даже если тип содержимого указан правильно, но сжатый поток битов недопустим. Ложные предположения просто вводят дополнительные случаи неудач.
Плохой пользовательский опыт (Poor User Experience): в этих случаях клиент и сервер взаимодействуют, но пользователь получает уменьшенный пользовательский опыт. Например, если клиент на ПК подключается к веб-сайту, который предоставляет контент для мобильных устройств, контент может быть не в восторге при просмотре на ПК. Или клиент, получающий доступ к услуге потокового мультимедиа, может получать контент с очень низкой скоростью передачи битов, даже если клиент поддерживает лучшие кодеки. Действительно, если пользователь желает получить доступ к контенту как с сотового устройства, так и с ПК, используя общую адресную книгу (то есть адресную книгу, совместно используемую несколькими устройствами), пользователю потребуется две записи в этой адресной книге, и ему потребуется используйте правильный от правильного устройства. Это плохой пользовательский опыт.
Ухудшенная безопасность (Degraded Security): в этих случаях используется более слабый механизм безопасности, чем тот, который следовало бы использовать. Например, сервер в домене может предполагать, что с ним связываются только клиенты с ограниченным набором алгоритмов аутентификации, даже если клиенты были недавно обновлены для поддержки более сильного набора.
6. Причины, почему предположения могут быть ложными
Сделанные клиентами и серверами предположения о работе протоколов при обращении к конкретному домену являются хрупкими и могут быть ошибочными по многим причинам. На стороне сервера многие из предположений основаны на представлении о том, что доменное имя будет предоставлено или использоваться только ограниченным набором клиентов. Если владелец доменного имени предполагает что-то об этих клиентах и может предположить, что доменные имена используют только эти клиенты, он может настроить или запрограммировать сервер для работы именно с этими клиентами. Обе части этого предположения могут быть неверными, как более подробно обсуждается ниже.
На стороне клиента это понятие аналогично, поскольку основано на предположении, что сервер в конкретном домене будет предоставлять определенный тип услуг. Подразделение и эволюция, которые обсуждаются ниже, могут сделать эти предположения неверными.
6.1. Эволюция
Интернет и устройства, которые к нему получают доступ, постоянно развиваются, часто быстрыми темпами. К сожалению, есть тенденция строить здесь и сейчас, а потом беспокоиться о будущем. Многие из приведенных выше предположений основаны на характеристиках современных клиентов и серверов. Поддержка определенных протоколов, методов аутентификации или контента основана на современных стандартах и современных устройствах. Хотя они, по большей части, могут быть правдой, они не всегда будут такими. Отличный пример — мобильные устройства. Сервер, обслуживающий домен, к которому получают доступ мобильные устройства, может попытаться сделать предположения о протоколах, расширениях протоколов, механизмах безопасности, размерах экрана или мощности процессора таких устройств. Однако все эти характеристики могут и будут меняться со временем.
Когда они меняются, изменения обычно эволюционные. В результате предположения остаются в силе в одних случаях, но не в других. Такие системы трудно исправить, поскольку для этого требуется, чтобы сервер обнаружил, к какому типу подключается клиент, и каковы его возможности. Если система не построена и не развернута с использованием этих методов согласования возможностей, встроенных для начала, такое обнаружение может быть чрезвычайно трудным. Фактически, исправление этого часто потребует добавления таких функций согласования возможностей, которые, если бы они были на месте и использовались с самого начала, могли бы полностью избежать этой проблемы.
6.2. Просачивание
Серверы также делают предположения из-за убеждения, что к ним будут обращаться только конкретные клиенты, и в частности те, которые настроены или подготовлены для использования доменного имени. По сути, существует предположение сообщества — что конкретное сообщество знает и использует доменное имя, в то время как другие за пределами сообщества не знают.
Проблема в том, что это понятие сообщества является ложным. Интернет глобален. DNS является глобальным. Не существует технического барьера, который отделяет людей внутри сообщества от тех, кто снаружи. Легкость, с которой информация распространяется по Интернету, делает крайне вероятным, что такие доменные имена в конечном итоге попадут в клиентов за пределами предполагаемого сообщества. Повсеместное присутствие доменных имен в различных форматах URI в сочетании с простотой передачи URI делает такую утечку просто вопросом времени. Кроме того, поскольку DNS является глобальным и поскольку он может иметь только один корень [12], клиенты за пределами сообщества могут искать, находить и использовать такие «специальные» доменные имена.
Действительно, эта утечка является сильной стороной архитектуры Интернета, а не слабостью. Он обеспечивает глобальный доступ к сервисам с любого клиента, подключенного к Интернету. Это, в свою очередь, обеспечивает быстрый рост числа клиентов для любой конкретной услуги.
6.3. Передоверие
Клиенты и пользователи делают предположения о доменах из-за того, что существует какой-то централизованный контроль, который может обеспечить выполнение этих предположений. Однако DNS не централизован; это распространяется. Если домен не делегирует свои субдомены и имеет свои записи в одной зоне, можно поддерживать централизованную политику в отношении работы своего домена. Однако, как только домен становится достаточно большим, чтобы администраторы домена начали делегировать субдомены другим органам, становится все труднее поддерживать какой-либо центральный контроль над характером сервиса, предоставляемого в каждом субдомене.
Точно так же использование доменных имен с человеческой семантической коннотацией ведет к регистрации нескольких доменов, в которых должна работать конкретная служба. Например, поставщик услуг с именем «example» может зарегистрировать и настроить свои сервисы в «example.com», «example.net» и, как правило, example.foo для каждого foo, который является допустимым TLD. Это, как и перераспределение, приводит к росту числа доменов, над которыми трудно поддерживать централизованный контроль.
Не то чтобы это невозможно, так как существует множество примеров успешного администрирования политик в поддоменах на многих уровнях. Однако для достижения этого результата требуются все большие усилия, поскольку для этого требуется вмешательство человека и создание процесса и процедуры. Автоматическую проверку соблюдения политик очень сложно выполнить, поскольку невозможно автоматически проверить многие политики, которые могут быть введены в действие.
Менее дорогостоящий процесс обеспечения централизованного управления политиками заключается в том, чтобы просто надеяться на соблюдение любых централизованных политик, а затем ждать жалоб или проводить случайные проверки. У этих подходов много проблем.
Недействительность допущений из-за пере-делегирования более подробно обсуждается в разделе 4.1.3 [8] и в разделе 3.3 [20].
В результате хрупкости преемственности политики между подделегациями, если клиент или пользователь принимает какое-либо свойство, связанное с TLD (например, «.wifi»), это становится все более вероятным с количеством поддоменов, что это свойство не будет существовать на сервере, идентифицированном конкретным именем. Например, в «store.chain.company.provider.wifi» может быть четыре уровня делегирования из «.wifi», что делает весьма вероятным, что, если держатель «.wifi» не будет усердно работать, свойства, которые Владелец «.wifi» желает исполнить нет. Эти свойства могут отсутствовать из-за человеческой ошибки или из-за преднамеренного решения не придерживаться их.
6.4. Мобильность
Одним из основных ценностных предложений имени хоста в качестве идентификатора является его постоянство. Клиент может изменять IP-адреса, но при этом сохранять постоянный идентификатор, используемый другими хостами для его достижения. Поскольку их значение определяется их постоянством, имена хостов, как правило, перемещаются вместе с хостом не только при изменении IP-адресов, но и при изменении поставщиков и технологий сети доступа. По этой причине предположения, сделанные относительно хоста на основе предполагаемой сети доступа, соответствующей этому имени хоста, как правило, со временем ошибочны. Например, ПК обычно может быть подключен к своему широкополосному провайдеру, а через динамический DNS иметь имя хоста в домене этого провайдера. Однако нельзя предположить, что какой-либо хост в этой сети имеет доступ по широкополосной линии связи; пользователь может подключить свой компьютер по беспроводной сети с низкой пропускной способностью и при этом сохранить свое доменное имя.
6.5. Человеческая ошибка
Конечно, человеческая ошибка может быть источником ошибок в любой системе, и то же самое здесь. Есть много примеров, имеющих отношение к обсуждаемой проблеме.
Клиентская реализация может исходить из того, что, поскольку запись DNS SRV существует для конкретного протокола в конкретном домене, что указывает на то, что служба доступна на каком-либо порту, эта служба фактически работает там. Это предположение может быть неверным, поскольку системные записи не были обновлены системными администраторами, чтобы отразить службы, запущенные в данный момент. В качестве другого примера клиент может предположить, что определенная политика домена применяется ко всем поддоменам. Однако системный администратор мог не применять политику к серверам, работающим в одном из этих поддоменов.
7. Рекомендации
Исходя из этих проблем, можно сделать четкий вывод, что клиенты, серверы и пользователи не должны делать предположений о характере услуг, предоставляемых домену или посредством домена. Более конкретно, однако, можно сказать следующее:
Следуйте спецификациям (Follow the specifications): когда спецификации определяют обязательные базовые процедуры и форматы, их следует внедрять и поддерживать, даже если ожидается, что чаще всего будут использоваться необязательные процедуры. Например, если спецификация предписывает конкретный метод базовой проверки подлинности, но позволяет согласовывать и использовать другие, то реализации должны реализовывать алгоритм базовой проверки подлинности, даже если другие используются большую часть времени. Проще говоря, поведение механизма протокола никогда не должно меняться в зависимости от доменного имени хоста.
Использование согласования возможностей (Use capability negotiation): многие протоколы разработаны с механизмами согласования возможностей. Например, структура согласования контента была определена для протоколов, использующих контент MIME [13] [14] [15]. SIP позволяет клиентам согласовывать типы мультимедиа, используемые в мультимедийном сеансе, а также параметры протокола. HTTP позволяет клиентам согласовывать типы мультимедиа, возвращаемые в запросах на контент. Когда такие функции доступны в протоколе, клиент и серверы должны использовать их, а не делать предположения о поддерживаемых возможностях. Следствием этого является то, что разработчики протокола должны включать такие механизмы, когда ожидается использование протокола.
«Будьте либеральны в том, что вы принимаете, и консервативны в том, что вы отправляете» [18] (Be liberal in what you accept, and conservative in what you send): эта аксиома дизайна интернет-протокола применима и здесь. Реализации должны быть готовы к полному охвату того, что протокол позволяет другому объекту отправлять, а не ограничивать то, что он желает получить.
Подводя итог — никогда не нужно делать предположений. Вместо этого используйте спецификации и возможности согласования, которые они предоставляют, и вся система будет надежной и совместимой.
8. Примечание к RFC 2219 и RFC 2782
Основываясь на приведенном здесь определении предположения, поведение, на которое намекают записи в DNS, также представляет собой предположение. RFC 2219 [19] определяет общеизвестные псевдонимы, которые можно использовать для создания доменных имен для достижения различных общеизвестных услуг в домене. За этим подходом позже последовало определение новой записи ресурса, записи SRV [2], которая указывает, что конкретная служба работает на сервере в домене. Хотя оба эти механизма полезны как подсказка о том, что конкретная служба работает в домене, оба они представляют предположения, которые могут быть ложными. Однако они различаются по ряду причин, по которым эти предположения могут быть ложными.
Клиент, который предполагает, что «ftp.example.com» является FTP-сервером, может быть ошибочным, поскольку предполагаемое соглашение об именах в RFC 2219 не было известно или не соблюдено владельцем domain.com. В RFC 2782 запись SRV для конкретной службы будет присутствовать только при явном выборе администратора домена, и, таким образом, клиент, который предполагает, что соответствующий хост предоставляет эту услугу, будет ошибочным только из-за человеческой ошибки в конфигурации. В этом случае предположение с меньшей вероятностью будет ошибочным, но это, безусловно, может быть.
Единственный способ с уверенностью определить, что служба работает на хосте, — это инициировать соединение с портом для этой службы и проверить. Реализации должны быть осторожны, чтобы не кодифицировать любое поведение, которое вызывает сбои, если информация, представленная в записи, фактически является ложной. Это граничит со здравым смыслом для надежных реализаций, но важно поднять этот вопрос явно.
9. Вопросы безопасности
Одним из допущений, которые могут быть сделаны клиентами или серверами, является доступность и использование (или их отсутствие) определенных протоколов и алгоритмов безопасности. Например, клиент, получающий доступ к услуге в определенном домене, может использовать определенный алгоритм аутентификации или хэш-функцию в протоколе приложения. Вполне возможно, что со временем в такой технике будут обнаружены недостатки, требующие использования другого механизма. Точно так же система может начать с небезопасного механизма, а затем принять решение использовать безопасный. В любом случае допущения, сделанные для свойств безопасности, могут привести к сбоям взаимодействия или, что еще хуже, к предоставлению услуг небезопасным способом, даже если клиент запрашивал и думал, что получит безопасный сервис. Такие предположения в корне не обоснованы, даже если сами записи защищены DNSSEC.
10. Благодарности
IAB хотел бы поблагодарить Джона Кленсина, Кита Мура и Питера Коха за их комментарии.
11. Члены IAB
Членами Совета по архитектуре Интернета на момент написания данного документа являются:
Bernard Aboba
Loa Andersson
Brian Carpenter
Leslie Daigle
Patrik Faltstrom
Bob Hinden
Kurtis Lindqvist
David Meyer
Pekka Nikander
Eric Rescorla
Pete Resnick
Jonathan Rosenberg
12. Информационные ссылки
[1] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.
[2] Gulbrandsen, A., Vixie, P., and L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, February 2000.
[3] Mealling, M., «Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database», RFC 3403, October 2002.
[4] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, «A Means for Expressing Location Information in the Domain Name System», RFC 1876, January 1996.
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.
[6] Schulzrinne, H., Rao, A., and R. Lanphier, «Real Time Streaming Protocol (RTSP)», RFC 2326, April 1998.
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, «SIP: Session Initiation Protocol», RFC 3261, June 2002.
[8] Eastlake, D., «.sex Considered Dangerous», RFC 3675, February 2004.
[9] Klensin, J., «Simple Mail Transfer Protocol«, RFC 2821, April 2001.
[10] Niemi, A., Arkko, J., and V. Torvinen, «Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)», RFC 3310, September 2002.
[11] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, November 1996.
[12] Internet Architecture Board, «IAB Technical Comment on the Unique DNS Root», RFC 2826, May 2000.
[13] Klyne, G., «Indicating Media Features for MIME Content», RFC 2912, September 2000.
[14] Klyne, G., «A Syntax for Describing Media Feature Sets», RFC 2533, March 1999.
[15] Klyne, G., «Protocol-independent Content Negotiation Framework», RFC 2703, September 1999.
[16] Rescorla, E., «HTTP Over TLS», RFC 2818, May 2000.
[17] Rosenberg, J. and H. Schulzrinne, «Reliability of Provisional Responses in Session Initiation Protocol (SIP)», RFC 3262, June 2002.
[18] Braden, R., «Requirements for Internet Hosts — Communication Layers«, STD 3, RFC 1122, October 1989.
[19] Hamilton, M. and R. Wright, «Use of DNS Aliases for Network Services», BCP 17, RFC 2219, October 1997.
[20] Faltstrom, P., «Design Choices When Expanding DNS», Work in Progress, June 2005.
Адрес автора
Jonathan Rosenberg, Editor
IAB
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
