Доменные имена Web3: методика проверки безопасности и результаты теста

Проблема в том, что один и тот же «красивый» идентификатор в разных системах может вести в разные кошельки. Увидеть это без отдельной проверки нельзя. Чтобы не отправить токены мошеннику, полезно понимать, как устроена резолюция Web3-имён и что именно можно проверить перед транзакцией.

Архитектура резолюции: почему Web3-имя живёт не в DNS

Web3-домен внешне напоминает имя сайта, но работает по другим правилам. Под капотом находится смарт-контракт с реестром, к которому обращаются через резолвер. Прямая резолюция ENS превращает имя в адрес кошелька и подтягивает связанные записи, например другие адреса или аватар. Обратная резолюция идёт от адреса к имени. У Unstoppable Domains логика похожая: это словарь ключ-значение на стороне смарт-контракта. Однако подходы к хранению и использованию записей различаются. Поэтому один и тот же запрос в разных приложениях может вернуть разные ответы, а пользователь этого не заметит, если сверяется только в одном месте.

Есть и технический нюанс, о котором легко забыть: согласно отчёту ICANN Security and Stability Advisory Committee от 15 декабря 2023 года, документу SAC123, расширение .eth не находится в корневой зоне DNS и не зарегистрировано в специальном реестре доменов IANA. Для классической DNS-системы .eth не является доменом верхнего уровня: у него нет стандартных whois-данных и привычной инфраструктуры, через которую проходят site.com или site.org. Поэтому обычные инструменты проверки доменов здесь могут ничего не показать. Они просто не знают о таком адресе.

Web3-имя хранится как запись в смарт-контракте. Проверять его нужно через блокчейн-инструменты и резолверы. Пустой ответ whois в этом случае сам по себе не означает сбой.

Отсюда возникает практическое трение при первом знакомстве с Web3-доменами. Пользователь видит понятное имя и ожидает, что сможет проверить его привычным способом, а сервис отвечает молчанием. Это расхождение между интерфейсом и архитектурой приходится учитывать: для разных типов имён нужны разные инструменты.

DNSSEC и криптографическая подпись: где заканчивается защита DNS

Когда Web3-имя связывают с обычным DNS-именем вроде mysite.com, появляется дополнительный слой — DNSSEC, система криптографической проверки DNS-данных. ENS требует DNSSEC для импортируемых DNS-имён, а подписи проверяет отдельный компонент DNSSECOracle. Если подписи нет, запись может не пройти валидацию, либо резолверы и кошельки покажут, что домен не подтверждён.

Документация ENS описывает формат обычного подключения через TXT-запись: TXT _ens a=<eth-address>;. Для пользователя смысл в том, что владелец DNS-зоны указывает адрес в записи, а DNSSEC позволяет криптографически подтвердить её подлинность. Без DNSSEC импорт может не сработать или будет помечен как недоверенный. Конкретное отображение зависит от резолвера и приложения, поэтому важно смотреть не только на имя, но и на статус его проверки.

При этом DNSSEC защищает только тот фрагмент, который находится в DNS. Сам ENS-контракт, словарь записей внутри домена и адрес, который там хранится, относятся к другому уровню. Подпись DNS подтверждает, что TXT-запись принадлежит владельцу зоны и не была незаметно изменена по пути. Она не доказывает, что указанный адрес принадлежит именно тому человеку, за которого выдаёт себя домен. DNSSEC снижает риск подмены данных в DNS-инфраструктуре, но не защищает от владельца зоны, который сам оказался злоумышленником или потерял контроль над аккаунтом.

Это важное ограничение. Криптографическая подпись помогает установить, кто опубликовал запись и менялась ли она после публикации. Она не оценивает добросовестность владельца и не подтверждает назначение кошелька. Поэтому DNSSEC — один из слоёв проверки, а не универсальный знак безопасности.

Словари записей: почему «в профиле указан правильный адрес» — слабая гарантия

Документация Unstoppable Domains указывает, что пользовательские записи хранятся как словарь ключ-значение и не проверяются на уровне смарт-контракта. Само наличие записи в домене ничего не говорит о правильности значения или о том, соответствует ли оно ожиданиям пользователя. Запись мог добавить тот, кто получил контроль над доменом.

ENS устроен более структурированно: записи можно изменить владельцу домена или уполномоченным им операторам. Однако структура не делает значения неизменными. В ENS-домене могут находиться адреса для ETH и BTC, а также поля для Discord, Twitter, GitHub и электронной почты. Если сверяться только с одним из них, можно ошибиться: имя действительно может принадлежать нужному человеку, но его актуальный адрес уже изменился. Возможен и худший сценарий, когда контроль над доменом или связанным аккаунтом был скомпрометирован и запись ведёт на чужой кошелёк.

Записи домена содержат значения, внесённые владельцем или тем, кому он делегировал управление. Сам факт их наличия не подтверждает, что адрес правильный и что получатель платежа тот, за кого себя выдаёт.

Представим, что в заметках сохранилась прошлогодняя визитка: у partner.eth указан рабочий адрес. С тех пор проект мог сменить кошелёк или перейти на мультисиг. Запись могла измениться, а старая копия адреса остаться в переписке. Просто открыть домен и убедиться, что поле заполнено, недостаточно. Нужно проверить, совпадает ли актуальное значение с тем, которое подтверждено получателем по независимому каналу.

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

Практическая методика аудита Web3-доменов перед транзакцией

Для проверки возьмём строку вида имя.eth, ник.crypto, mysite.com или похожий идентификатор. Задача не в том, чтобы объявить домен безопасным, а в том, чтобы понять, куда уйдут средства и какие неопределённости остаются.

Шаг 1. Определить сеть получателя. Web3-домен может содержать разные адреса для разных сетей: например, ETH, BTC и другие. До проверки нужно понять, в какой сети будет транзакция, и открыть соответствующую запись. Если резолвер показывает значение по умолчанию, не следует считать его подходящим для любого перевода.

Шаг 2. Сверить резолюцию в независимом источнике. Для ENS можно обратиться к ens.app или проверить результат в кошельке, например MetaMask. Для Unstoppable Domains подходит их собственный резолвер. Сравнить стоит адреса для нужной сети, а не только визуально похожие имена. Если два источника возвращают разные значения, лучше остановиться и выяснить причину до отправки средств.

Шаг 3. Сопоставить адрес с окном подтверждения транзакции. Скопируйте адрес из резолвера и сравните его с получателем, который отображается в кошельке перед подписанием. Особое внимание нужно уделить началу и концу адреса, но для значимого перевода лучше сверить всю строку. Так можно заметить подмену в интерфейсе или ошибку при копировании. Похожее написание имени, например partneг.eth с кириллической буквой вместо латинской, тоже не означает, что перед вами нужный домен.

Шаг 4. Проверить срок действия имени. У ENS есть льготный период продления в 90 дней после истечения срока. Если домен близок к окончанию срока, выясните, кто контролирует его сейчас и может ли ситуация с владением измениться. Дата продления легко теряется из виду, когда внимание сосредоточено на содержимом переписки или срочности платежа.

Шаг 5. Для DNS-имени компании проверить DNSSEC и запись _ens. Это уместно, если в Telegram, письме или на сайте предлагают использовать адрес вроде pay.company.com. Проверка DNSSEC помогает удостовериться в подлинности DNS-записи, но сама по себе не устанавливает, кто управляет кошельком и верен ли указанный адрес. Результат нужно рассматривать вместе с данными резолвера и подтверждением получателя.

Эта методика не покрывает все классы атак. Она помогает заметить несоответствия и заставляет остановиться перед подписанием, если данные вызывают сомнение. Главный практический шаг — проверить адрес получателя в самом кошельке. Резолвер может показать запись, но последнее решение о переводе принимается в транзакции.

Слепые зоны проверки

Один из менее очевидных рисков — рассинхрон между системами. Если имя существует в ENS и Unstoppable Domains, в каждой системе могут быть собственные записи и адреса. Пользователь может открыть правильное имя, но выбрать не ту сеть или неверно истолковать результат. Поэтому проверка должна начинаться с вопроса, какой именно реестр и какая сеть используются в конкретной транзакции. Резолвер по умолчанию не всегда подходит для этой задачи.

Следующий риск связан с операционными изменениями. Команда проекта может сменить кошелёк получателя, перейти на мультисиг или провести ребрендинг имени. Резолвер покажет текущую запись, но адрес из старой переписки останется старым. Если сравнивать его на глаз с новым, ошибка легко проскочит. Для платежа лучше получить адрес или подтверждение напрямую через уже известный канал связи с получателем.

Есть и предел самой идеи проверки домена. Даже корректно разрешённое имя не гарантирует, что сайт, письмо или аккаунт в мессенджере, где оно указано, подлинные. Фишинговая страница может использовать знакомый логотип, похожий адрес или убедительный текст. Имя и канал связи нужно оценивать раздельно: корректная запись не делает безопасной страницу, на которую вас привела подозрительная ссылка.

Проверка Web3-домена не заменяет сверку адреса получателя перед подписанием. Если адрес в окне подтверждения отличается от результата резолюции, остановитесь и выясните причину.

Фишинг: где проходит граница между проверкой и ловушкой

ENS и Unstoppable Domains в справочных материалах предупреждают о схемах, в которых пользователей просят раскрыть seed-фразу, пароль или приватный ключ. Если сайт предлагает ввести мнемонику из 12 или 24 слов под предлогом проверки домена или подтверждения владения именем, это признак фишинга. Для резолюции имени не требуется раскрывать секреты, которые дают контроль над кошельком.

Насторожить должны и другие детали: подозрительный отправитель письма, клон известного сервиса в рекламе или мессенджере, просьба срочно подтвердить транзакцию. В рекомендациях ENS советуют проверять URL перед подключением кошелька и читать содержимое каждой транзакции. Материалы поддержки Unstoppable Domains также обращают внимание на фишинговые письма и сайты-клоны. Перед подписанием стоит самостоятельно проверить адрес сайта, а не полагаться на ссылку из неожиданного сообщения.

В таких схемах эксплуатируют привычку доверять знакомому имени. Но домен может быть подменён похожим набором символов, а сайт вокруг него может оказаться копией. Даже правильный Web3-идентификатор не отменяет проверки URL и содержимого операции. Если интерфейс кошелька показывает действие, которого вы не ожидали, не подтверждайте его только потому, что имя выглядит знакомым.

Проверка безопасности без иллюзии универсального балла

Безопасность Web3-домена складывается из нескольких разных вопросов. Какое имя разрешает выбранный сервис? Какую запись он возвращает для нужной сети? Подтверждена ли DNS-запись, если используется импортируемое DNS-имя? Совпадает ли итоговый адрес с тем, что показано в кошельке? Ответ на один вопрос не закрывает остальные.

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

Доменные имена Web3 делают адреса удобнее для чтения, но не превращают их в гарантию личности или безопасности. Перед переводом нужно выбрать правильную сеть, проверить результат в резолвере, сопоставить его с адресом в кошельке и учитывать, кто может менять записи. Если проверка требует seed-фразу или приватный ключ, закройте страницу. Ни имя, ни резолвер не оправдывают передачу этих данных.