В TON DNS используются знакомые доменные имена, состоящие из строки в кодировке UTF-8 длиной до 126 байт, с различными разделами доменного имени, разделенными точками (.). Нулевые символы (т.Е. Нулевые байты) и, в более общем смысле, байты в диапазоне 0..32 не допускаются в доменных именах. Например, test.tonи mysite.temp.tonявляются действительными доменами TON DNS. Основное отличие от обычных доменных имен заключается в том, что домены TON DNS чувствительны к регистру; можно преобразовать все домены в нижний регистр перед выполнением поиска TON DNS, чтобы при желании получить нечувствительность к регистру.
В настоящее время только домены, оканчивающиеся на.ton, признаются действительными доменами TON DNS. Это может измениться в будущем. Обратите внимание, однако, что это плохая идея определять домены первого уровня, совпадающие с доменами первого уровня, уже существующими в Интернете, такими как .comor.to, потому что тогда можно зарегистрировать домен TONgoogle.com, развернуть там сайт TON, создать скрытую ссылку на страницу на этом сайте TON со своегодругой невинно выглядящий сайт TON и крадет google.comфайлы cookie у ничего не подозревающих посетителей.
Внутренне TON DNS преобразует доменные имена https://smoservice.vc следующим образом. Сначала доменное имя разбивается на его компоненты, разделенные символами точки .. Затем к каждому компоненту добавляются нулевые символы, и все компоненты объединяются в обратном порядке. Например, google.comстановится com\0google\0.
2. Разрешение DNS-доменов TON
DNS-домен TON решается следующим образом. Во-первых, смарт-контракт корневого DNS определяется путем проверки значения параметра конфигурации # 4 в последнем состоянии мастерчейна. Этот параметр содержит 256-битный адрес корневого смарт-контракта DNS внутри мастерчейна.
Затем dnsresolveдля смарт-контракта корневого DNS вызывается специальный get-метод (идентификатор метода 123660) с двумя параметрами. Первый параметр — это ячейка с 8n битами данных, содержащая внутреннее представление разрешаемого домена, где n — длина внутреннего представления в байтах (не более 127). Второй параметр представляет собой 16-разрядное целое число со знаком, содержащее требуемую категорию. Если категория равна нулю, то запрашиваются все категории.
Если этот get-метод завершается с ошибкой, то поиск TON DNS завершается неудачно. В противном случае метод get возвращает два значения. Первый — 8m, длина (в битах) префикса внутреннего представления домена, который был разрешен, 0 < m <= n. Вторая — это ячейка с записью TON DNS для требуемого домена в требуемой категории или корневой словарь a с 16-битными целочисленными ключами (категориями) со знаком и значениями, равными сериализации соответствующих записей TON DNS. Если домен не может быть разрешен смарт-контрактом корневого DNS, т.е. Если ни один непустой префикс не является допустимым доменом, известным смарт-контракту, то возвращается (0, null). Другими словами, m = 0 означает, что DNS-поиск TON не нашел данных для требуемого домена. В этом случае поиск TON DNS также не увенчается успехом.
Если m = n, то второй компонент результата представляет собой либо ячейку с допустимой записью TON DNS для требуемого домена и категории, либо Null, если для этого домена с этой категорией нет записи TON DNS. В любом случае процесс разрешения останавливается, и полученная таким образом DNS-запись TON десериализуется и содержит требуемую информацию (например, тип записи и ее параметры, такие как адрес смарт-контракта или адрес ADNL).
Наконец, если m < n, то поиск пока проходит успешно, но для m-байтового префикса исходного внутреннего представления домена доступен только частичный результат. Возвращается самый длинный из всех таких префиксов, известных смарт-контракту DNS. Например, попытка поиска mysite.test.ton(т. Е. ton\0test\0mysite\0Во внутреннем представлении) в интеллектуальном контракте корневого DNS может вернуть 8m = 72, что соответствует префиксу ton\0test\0i.например, для поддомена “test.ton” в обычном представлении домена. В этом случае dnsresolve() возвращает значение для категории -1 для этого префикса независимо от категории, первоначально запрошенной клиентом. По соглашению, категория -1 обычно содержит DNS-запись TON типа dns_next_resolver, содержащую адрес смарт-контракта next resolver (который может находиться в любой другой рабочей цепочке, такой как базовая цепочка). Если это действительно так, процесс разрешения продолжается путем запуска get-метода dnsresolveдля следующего преобразователя, при этом внутреннее представление доменного имени содержит только его часть, которая пока не решена (если мы искалиton\0test\0mysite\0, и префикс ton\0test\0был найден интеллектуальным контрактом корневого DNS, тогда dnsresolveбудет вызван следующий с mysite\0в качестве своего первого аргумента). Затем либо следующий смарт-контракт распознавателя сообщает об ошибке или отсутствии каких-либо записей для требуемого домена или любого из его префиксов, либо получается конечный результат, либо возвращается другой смарт-контракт с префиксом и следующим распознавателем. В последнем случае процесс продолжается таким же образом, пока не будет разрешен весь исходный домен.