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

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

Привет, я Мария Колесникова – руководитель проекта Поддерживаю.РФ. Сегодня я хочу рассказать тем, кто делает софт и веб-проекты, почему стоит обратить внимание на поддержку 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 тыс. доменов, например, в зоне. РФ), вы можете выбрать разные схемы валидации.

Схема валидации, поддерживающая любые IDN/EAI:

  • проверка формата 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), либо русский (а-я), но не оба вместе (для защиты от омоглифических атак).

Вывод IDN и EAI

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

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

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

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

33
17 комментариев

Вы очень сильно упростили схему валидации/нормализации таких доменов. Она гораздо сложнее. Весь StackOverflow завален вопросами про корректные алгоритмы валидации IDN, при этом там нет ни одного исчёрпывающего ответа. Ни одного.

Например, для валидации IDN в PHP-проектах можно использовать валидатор laminas: https://github.com/laminas/laminas-validator/blob/master/src/Hostname.php – это кусок бывшего Zend-фреймворка. Одна из лучших реализаций в OpenSource сейчас.

Но даже в ней куча багов, этот валидатор приходится обвешивать дополнительными проверками. Например, я отправил в этом году им баг с капсом в кириллических доменах: https://github.com/laminas/laminas-validator/pull/64

И именно вся эта сложность и становится преградой для повсеместного внедрения IDN-доменов. Их поддержка на техническом уровне – это очень затратная история. 

1
Ответить

Павел, спасибо за комментарий! Нам важно, что есть люди, которым вопросы поддержки IDN действительно интересны.

Вопрос нормализации заслуживает отдельного поста, а что касается валидации IDN/EAI, то мы специально упрощаем схему, чтобы ей можно было пользоваться в реальности. Вы сами убедились, что форматная валидация полного IDN – практически нерешаемый вопрос, поэтому мы и советуем для таких случаев либо совсем простую проверку длины, либо перевести в Punycode и сделать DNS-запрос. А для кириллических доменов – да, можно проверять формат, там все просто.

Если вас интересует эта тема, присоединяйтесь к нашему сообществу – у нас есть Bug Bounty программа, а скоро будет программа для контрибуторов opensource.

Ответить

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

Ответить

мы специально упрощаем схему, чтобы ей можно было пользоваться в реальности

Мария, ею небезопасно пользоваться в реальности в таком виде. Это вопрос безопасности проектов.

Например, при авторизации по емейлу: в случае неверной валидации и нормализации IDN-емейлов можно войти в систему под другим пользователем, потому что два емейла оказываются для системы равнозначными. С этим багом в своё время сталкивался даже GitHub.

Ответить

Павел, по-моему, вы смешиваете кислое с мягким. Валидация, это проверка возможности существования e-mail в природе -либо форматная, либо такая как Мария описала. В случае неверной валидации вы просто пропустите в базу несуществующий адрес, при отправке писем на который, пойдут ошибки. Вопрос оценки эквивалентности имейлов и нормализации при этом - вопрос совершенно другой, потому что нужно рассматривать тему IDNA. 

Ответить

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

Ответить