Доменные имена – важнейшая часть интернета – и, пожалуй, вторая после IP-адресов. Кажется, что DNS и сами доменные зоны остаются неизменными десятилетиями, однако на самом деле изменения есть и они накапливаются. И можно в один прекрасный момент оказаться лицом к лицу с технологией, которая стала настолько другой, что ваш продукт больше не работает, и потребуется потратить десятки часов на его адаптацию, одновременно успокаивая негодующих клиентов.
Вы очень сильно упростили схему валидации/нормализации таких доменов. Она гораздо сложнее. Весь 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-доменов. Их поддержка на техническом уровне – это очень затратная история.
Павел, спасибо за комментарий! Нам важно, что есть люди, которым вопросы поддержки IDN действительно интересны.
Вопрос нормализации заслуживает отдельного поста, а что касается валидации IDN/EAI, то мы специально упрощаем схему, чтобы ей можно было пользоваться в реальности. Вы сами убедились, что форматная валидация полного IDN – практически нерешаемый вопрос, поэтому мы и советуем для таких случаев либо совсем простую проверку длины, либо перевести в Punycode и сделать DNS-запрос. А для кириллических доменов – да, можно проверять формат, там все просто.
Если вас интересует эта тема, присоединяйтесь к нашему сообществу – у нас есть Bug Bounty программа, а скоро будет программа для контрибуторов opensource.
Проверять DNS запросами это недопустимое решение. Если так сделает значительное количество разработчиков - это может положить корневые DNS, потому что весь мусор, не проходящий проверки, будет проходить до них.
мы специально упрощаем схему, чтобы ей можно было пользоваться в реальности
Мария, ею небезопасно пользоваться в реальности в таком виде. Это вопрос безопасности проектов.
Например, при авторизации по емейлу: в случае неверной валидации и нормализации IDN-емейлов можно войти в систему под другим пользователем, потому что два емейла оказываются для системы равнозначными. С этим багом в своё время сталкивался даже GitHub.
Павел, по-моему, вы смешиваете кислое с мягким. Валидация, это проверка возможности существования e-mail в природе -либо форматная, либо такая как Мария описала. В случае неверной валидации вы просто пропустите в базу несуществующий адрес, при отправке писем на который, пойдут ошибки. Вопрос оценки эквивалентности имейлов и нормализации при этом - вопрос совершенно другой, потому что нужно рассматривать тему IDNA.
Валидация разная бывает. От бизнес-логики зависит. Кому-то нужно проверять доступность, кому-то формат и так далее. "Корректный домен" – это штука очень расплывчатая.