Технические вопросы работы с «русскоязычными» доменами

Утро вчера началось с того, что Иван Тиуков отправил мне ссылку с новостью о начале предварительной регистрации доменов .рф (для владельцев торговых марок за неоправданную цену) и выразил свое негативное к этому отношение. Идею доменов на национальных языках я тоже считаю глупой, бессмысленной и порочной, но это субъективное мнение. А вот что работать с такими доменами с большой вероятностью придется — уже суровая правда жизни.

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

Суть технологии

Конечно, внутреннее представление русскоязычных имен доменов существенно отличается от того, что видит пользователь. DNS все так же использует английский алфавит, дефис и цифры, а для хранения имен с отличными от этих символами был разработан метод представления unicode через них. Метод называется punycode, если кому-то интересны подробности, можно обратиться к первоисточнику — RFC 3492. Если вникать в подробности нет желания, то можно посмотреть на пример. Имя «сайт.пример.тест», которое мы будем использовать для тестирования, после перекодировки в punycode превращается в «xn--80aswg.xn--e1afmkfd.xn--e1aybc». Не слишком эстетично выглядит, и еще хуже воспринимается.

Тестовый сервер

Для тестирования мы используем существующий сервер моей локальной сети. На нем как раз уже установлены dns-сервер bind, веб-сервер Apache, ftp-сервер vsftpd и прокси-сервер squid. Для начала настроим наш тестовый домен. Ради интереса мы сделаем это через родной для SuSE инструмент yast2. Набираем в консоли yast2 dns-server и вводим имя нашего домена прямо как есть, русскими буквами. Примерно вот так:

Смотрим в файлы конфигурации, которые он сгенерировал. Как ни странно, он все понял и сам перекодировал в punycode.

Описание зоны:
zone "xn--e1afmkfd.xn--e1aybc" in {
 file "master/xn--e1afmkfd.xn--e1aybc";
 type master;
};

A-запись:
xn--80aswg      IN A            10.91.19.5

Что ж, уже неплохо. Теперь создадим virtual host в apache. Здесь, увы, придется писать уже перекодированное имя руками. Примерно так:

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName xn--80aswg.xn--e1afmkfd.xn--e1aybc
    DocumentRoot /srv/www/htdocs/site.local
    HostnameLookups Off
    UseCanonicalName Off
    ServerSignature Off
    <Directory "/srv/www/htdocs/site.local">
 Order allow,deny
 Allow from all
    </Directory>
</VirtualHost>

Теперь положим ему в каталог в качестве index.html простейшую статическую страницу, и перейдем к тестированию браузеров. Squid и vsftpd никаких изменений конфигурации не требуют.

Тестирование браузеров

Посмотрим на все сколько-нибудь популярные браузеры. Специально для такой цели нашел компьютер с Windows XP. Сценарий везде будет одинаковый: сначала проверяем, что будет при вводе русскоязычного имени в адресную строку; а потом поймет ли он русскоязычный адрес прокси-сервера.

Internet Explorer 7

Адрес понимает, и даже корректно отображает.

Настраиваем ему прокси-сервер и смотрим результат. Чтобы убедится, что мы пошли именно через прокси, введем в адресной строке заведомо несуществующий адрес — если все в порядке, мы увидим сгенерированную прокси-сервером страницу с сообщением об ошибке.

Можно считать, что IE успешно выдержал испытание. В том числе и в режиме «Проводника»:

Firefox

Далее будут приводены только комментарии о результатах, потому как делать мы будем в точности одно и то же. Это Firefox 3.5.5 под Windows.

Теперь те же тесты с Firefox 3.0.9 на Linux.

Вывод: поддерживает, но в адресной строке отображает уже перекодированную строку. Неприятный недостаток, но на работоспособность не влияет.

Opera

Opera 10.1 под Windows Opera 9.64 под Linux Итог: Opera полностью прошла тест.

Safari под Windows

Mac OS X у меня под рукой, к сожалению, нет, поэтому тестировал только на Windows. Весьма вероятно, что результат там будет таким же.

Итог: поддерживает, но с той же проблемой, что в Firefox. Тоже показывает перекодированную строку в качестве адреса.

Google Chrome

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

Konqueror из KDE3

Им мало кто пользуется, но для комплекта пусть будет. Его версию для KDE4 не проверял, никакого желания его ставить у меня нет. Как видим, он вообще не понял, что от него хотят.

Вывод

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

Еще некоторые программы для работы с сетью

Были проверены клиент обмена мгновенными сообщениями Pidgin, ftp-клиент FileZilla и клиент терминального доступа PuTTY. Никто из них адрес не воспринял вообще. Можно посмотреть на снимках экрана.

Диагностические утилиты

Пользователей это не особо касается, однако специалисты пользуются утилитами диагностики сети не один раз в день. Такими как ping, traceroute, host, dig и так далее. Их реализации ни под Windows, ни под Linux русскоязычные имена не понимают, и в обозримом будущем не будут. То есть, им каждый раз потребуется уже перекодированный в punycode адрес.

[baturin@zax ~]$ping сайт.пример.ру
ping: unknown host сайт.пример.ру
[baturin@zax ~]$traceroute сайт.пример.ру
сайт.пример.ру: Имя или служба не известны
[baturin@zax ~]$host сайт.пример.ру 
Host сайт.пример.ру not found: 3(NXDOMAIN)
[baturin@zax ~]$ping xn--80aswg.xn--e1afmkfd.xn--e1aybc
PING xn--80aswg.xn--e1afmkfd.xn--e1aybc (10.91.19.5) 56(84) bytes of data.
64 bytes from suse.tomsk.ru (10.91.19.5): icmp_seq=1 ttl=64 time=0.201 ms
^C
--- xn--80aswg.xn--e1afmkfd.xn--e1aybc ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.201/0.201/0.201/0.000 ms
[baturin@zax ~]$host xn--80aswg.xn--e1afmkfd.xn--e1aybc
xn--80aswg.xn--e1afmkfd.xn--e1aybc has address 10.91.19.5

Вывод

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

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