Почему стоит поддерживать нелатинские домены в своем ПО

Привет, я Мария Колесникова – руководитель проекта Поддерживаю.РФ. Сегодня я хочу рассказать тем, кто делает софт и веб-проекты, почему стоит обратить внимание на поддержку IDN-доменов и EAI-адресов.

Доменные имена – важнейшая часть интернета – и, пожалуй, вторая после IP-адресов. Кажется, что DNS и сами доменные зоны остаются неизменными десятилетиями, однако на самом деле изменения есть и они накапливаются. И можно в один прекрасный момент оказаться лицом к лицу с технологией, которая стала настолько другой, что ваш продукт больше не работает, и потребуется потратить десятки часов на его адаптацию, одновременно успокаивая негодующих клиентов.

Сейчас мы как раз подходим к такому рубежу – e-mail и доменные имена, состоящие полностью из Unicode-символов (например, кириллических — срочно@напишимне.рф, вочтолюбятиграть.дети). За почти пятнадцать лет с момента появления идеи создания IDN-доменов сначала появились частичные, а затем и полностью состоящие из юникода доменные имена, но локальная часть e-mail оставалась латинской (ASCII). Кроме того, сами доменные имена обрабатывались (и, по правде говоря, обрабатываются и сейчас) с помощью «костылей», в первую очередь с использованием Punycode – специально разработанного алгоритма преобразования Unicode-доменов в ASCII.

Число интернационализированных доменных имен растет. И здесь учтены не только кириллические доменные имена, которых довольно много и они зарегистрированы в различных доменных зонах, помимо. РФ, но и китайские, и арабские доменные имена, а также домены на европейских языках (немецком, французском, языках балканской группы), использующие расширенную латиницу. Этот рост выше, чем те 4,3%, с которыми растет доменный рынок в целом.

Многие разработчики все эти годы говорили и продолжают утверждать, что e-mail с Unicode-символами (EAI-mail) и правильное отображение IDN-доменов – маргинальная тема, которая нужна единицам пользователей. Но 9 млн таких доменных имен — это факт, который уже нельзя игнорировать. Еще один важный признак того, что отношение к проблеме меняется, – деятельность ICANN, которая провозгласила универсальное принятие (Universal Acceptance) одним из своих пяти стратегических направлений на ближайшие пять лет и активно поддерживает деятельность глобальной рабочей группы в этой области — UASG.

В результате все идет к тому, что технологии поменяются. В первую очередь изменения коснутся e-mail – сейчас практически везде полные Unicode-адреса запрещены на уровне настроек, несмотря на то, что технологически многие почтовые серверы готовы обрабатывать их. Тот же Microsoft активно работает над внедрением EAI-mail — поддержка уже действует в Outlook и сервисе Office 365, сейчас идет работа над внедрением в сервер Exchange, Apple недавно объявил о реализации такой поддержки в iOS14, а в популярной среди хостеров почтовой связке Postfix (или Exim) + Courier + Roundcube уже два из трех компонентов имеют базовую поддержку и настраиваются на взаимодействие с ними.

Сейчас на уровне рекомендуемых лучших практик решается еще одна важная проблема – безопасность при использовании омоглифов (одинаково выглядящих символов из разных алфавитов) в локальной части почтовых адресов. В частности, для кириллического EAI-mail наиболее вероятна такая рекомендация: локальная часть сможет содержать либо символы латинского (a-z), либо русского алфавита (а-я), но не оба вместе.

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

Валидация – IDN-домены и EAI-mail часто не проходят валидацию на сайтах, в мобильных приложениях и сервисах просто потому, что внутри используются старые схемы: проверка доменной зоны и контроль набора допустимых символов с помощью регулярных выражений. Для своего проекта, в зависимости от того, хотите вы поддерживать все IDN и EAI или только кириллические (730 тыс. доменов, например, в зоне. РФ), вы можете выбрать разные схемы валидации.

• проверка формата EAI только на наличие @ и. (точки);

• проверка на длину доменного имени: до 255 символов в целом, максимум 63 символа в домене каждого уровня, но проверка должна выполняться после его перевода в А-метку по алгоритму Punycode;
• если требуется проверить существование доменного имени, то валидность входящей в него доменной зоны (TLD) можно проверить на официальном ресурсе IANA или сделать DNS-запрос, так же предварительно переведя доменное имя в А-метку;
• если нужно проверить существование почтового ящика, можно отправить на него тестовое письмо с подтверждением, но стоит учесть, что в ряде случаев получение ответного сообщения может занять достаточно длительное время или ответ может не прийти вовсе, хотя тестовое письмо и будет получено.

• проверка формата EAI на наличие @ и . (точки), обе части e-mail (локальная и доменная) могут содержать a-z, а-я, 0-9, — (дефис), а также _ (нижнее подчеркивание) только в локальной части;

• доменная часть e-mail может содержать a-z, а-я, 0-9, — (дефис). При этом большинство регистратур TLD запрещают регистрировать доменные имена, содержащие символы нескольких алфавитов одновременно в одном домене 2-го и ниже уровня;

• рекомендуется, чтобы локальная часть e-mail содержала либо латинский алфавит (a-z), либо русский (а-я), но не оба вместе (для защиты от омоглифических атак).

Доменные имена с Unicode-символами в приложениях чаще всего переводятся в Punycode и хранятся в таком виде. Это не идеальное решение с точки зрения универсального принятия, но вполне может применяться, чтобы не переписывать большой объем кода. Однако для удобства пользователей перед выводом доменных имен и e-mail лучше всего проверять и переводить их в Unicode-формат.

Кстати, что точно нужно исправить – это проблему с тем, что EAI-адреса при обработке нередко разбиваются на две части и обе переводятся в Punycode. Так работать не будет, т.к. этот алгоритм применяется только для доменов, и ящик [email protected] конвертируется почтовыми серверами в xn--e1aybc@тест.рф, но не в тест@тест.рф, как задумывалось.

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

Кстати, с 1 сентября в проекте Поддерживаю.РФ открылась программа IDN Bug Bounty и выплачиваются призовые тем, кто найдет проблемы поддержки IDN и EAI в известном софте или крупных веб-проектах!