Вспомогательные механизмы

Разрешение доменных имен в среде IPv6

Предположим, серверы и клиенты DNS учли изменения, предложенные в §2.11. После этого приложение, обращаясь к DNS посредством сетевой библиотеки, может встречаться не только с адресами IPv4, но также с адресами IPv6. Более того, в переходный период вероятен "винегрет" из адресов, когда одному имени сопоставлены адреса обоих семейств. Например:

www.example.org. IN A 192.0.2.77

AAAA

2001:db8:c001::beef

Правильная работа с адресами из разных семейств пусть будет на совести программистов. Во-первых, они должны избавиться от ложного убеждения , будто все сетевые адреса — IPv4. Во-вторых, им следует принять во внимание правила выбора адресов, к которым мы пришли §6.6. Мы же сейчас позаботимся, чтобы приложение получило по своему запросу полный список адресов, отвечающих данному доменному имени.

Между клиентом DNS в составе сетевой библиотеки и приложением обычно находится дополнительный уровень абстракции, который позволяет обращаться посредством одного простого API к разным системам разрешения имен: HOSTS.TXT, DNS, NIS и т.п. Скажем, в классическом API BSD Unix приложения использовали функцию gethostbyname(). Оттуда эта функция проникла в стандарт POSIX и в API Windows Sockets. К сожалению, функция gethostbyname() не готова к работе со смешанными семействами сетевых адресов: она может вернуть список адресов только из одного семейства. По умолчанию она возвращает адреса IPv4, а способ переключить ее на IPv6 системно-зависим.

По всей видимости, нужны новые функции для доступа к системам разрешения имен. Как показывает опыт, пересматривать общепринятый API еще труднее и опаснее, чем модифицировать сетевой протокол. Но раз уж нам придется это сделать, новые функции должны быть максимально гибкими и универсальными. По этой причине мы не можем просто добавить к уже существующей поддержке IPv4 поддержку IPv6.

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

Именно так поступает новая функция getaddrinfo() [§6.1 RFC 3493]. Значение поля "семейство адреса", возвращаемое этой функцией, можно прозрачно передавать функциям из API сокетов Беркли [RFC 3493], так что приложениям не нужно обрабатывать каждое известное им семейство отдельно. Теперь правильно написанное приложение не потребует никаких изменений после появления следующей версии IP или даже перехода на новый стек протоколов с похожими свойствами.

Каковы будут отношения нового API и зонной адресной архитектуры IPv6? Если узел использует не DNS, а другую систему разрешения имен, которая каким-то образом позволяет ему получать правильные идентификаторы зон zone_id в адресах, то функция getaddrinfo() готова дать ему доступ к этой информации. Она возвращает адреса IPv6 в виде структур sockaddr_in6, где есть поле идентификатора зоны.

Если же адрес IPv6 получен из записи AAAA, опубликованной в DNS, то доступно только его численное значение, не уточненное идентификатором зоны zone_id. Причины этого были изложены в §2.11. Тем не менее, отсутствие zone_id в записи AAAA еще не значит, что такая запись не может содержать в правой части адрес IPv6 с ограниченной областью действия. К примеру, если организация использует внутрисайтовые адреса, то все они заведомо принадлежат одной зоне — внутренней сети организации. С одной стороны, такие адреса вполне можно поместить в частную зону DNS этой организации. С другой стороны, они не имеют смысла вне данной организации.

Утечка записей с внутрисайтовыми адресами в Internet может иметь неприятные последствия. Рассмотрим следующий пример. Организация А поместила в свою публичную зону DNS такие записи:

www.example.org. IN AAAA 2001:db8::beef

AAAA fec0::beef

Организация Б тоже использует внутрисайтовые адреса. Ее хост Х собирается обратиться к www.example.org. У хоста Х есть внутрисайтовый адрес, и по правилам выбора (§6.6) хост Х предпочтет удаленный адрес FEC0::BEEF, потому что у него наименьшая область. Но, с точки зрения хоста Х, зона адреса FEC0::BEEF — сайт Б, а не сайт А! Когда хост Х попытается установить сеанс по этому адресу (см. рис. 9.5), возможны три основных исхода, один другого хуже:

• хост Х не сможет установить сеанс, потому что в сети Б нет узла с адресом FEC0::BEEF; этот исход не фатальный, так как хост Х перейдет к следующему адресу www.example.org, 2001:DB8::BEEF, по тем же правилам выбора;
• хост Х установит сеанс с легитимным узлом сети Б, чей адрес — FEC0::BEEF; результат будет непредсказуемым;
• злоумышленник, забравшийся в сеть Б, присвоит себе свободный адрес FEC0::BEEF и без труда перехватит сеанс; вдобавок, хосты могут применять разные политики безопасности к сеансам внутри и вне сайта; например, хост Х может отказаться от аутентификации и шифрования сеанса, полагая, что ведет диалог с доверенным узлом; в результате безопасность пострадает еще сильнее.
  

  
  Рис. 9.5. Последствия необдуманной публикации внутрисайтового адреса в DNS

Выводы напрашиваются сами собой:

• >в общедоступной зоне DNS следует регистрировать только глобальные адреса IPv6;
• клиент DNS не должен возвращать приложению запись из общедоступной зоны DNS, если она содержит адрес IPv6 с ограниченной областью.

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