Кратко

  • По RFC 10023 TXT размещается в _for-sale.<домен>, начинается с точной, чувствительной к регистру строки v=FORSALE1; и может нести одну подсказку fcod, ftxt, furi или fval. Домен при этом продолжает работать.
  • Это объявление о доступности, а не механизм сделки. fval задаёт необязательную цену, URI может быть опасным, а DNSSEC подтверждает происхождение и целостность DNS-данных, но не право распоряжаться доменом.
  • Покупателю нужны отдельные доказательства наблюдения, контроля зоны, личности регистранта, полномочия представителя, условий, защищённого расчёта, переноса у регистратора и непрерывности сервисов.

Машина нашла продавца, которого ещё никто не проверял

Система поиска цифровых активов ставит домену высокий приоритет. В DNS виден v=FORSALE1;fval=USD75000, рядом опубликован HTTPS-адрес, проверка DNSSEC успешна. Система помечает запись «продажа подтверждена» и запускает приобретение. Домен в это время обслуживает корпоративную почту и вход клиентов.

Система могла правильно прочитать каждый технический факт и ошибиться в выводе.

Право менять зону не обязательно включает право продавать регистрационный контроль. API-ключ мог быть скомпрометирован. Посредник по ссылке мог потерять мандат. Сумма могла устареть. Под «продажей» могла пониматься аренда или право пользования, а не смена регистранта. Наконец, успешный transfer способен оставить покупателя без DNSSEC, почты, сертификатов и работающих приложений.

RFC 10023, опубликованный в июле 2026 года как Informational RFC, описывает небольшую операционную договорённость. Держатель добавляет в зону зарезервированный leaf _for-sale и тем самым показывает доступность родительского домена. Термин понимается широко и включает аренду либо передачу договорного права использования. Запись можно включать и удалять без изменения протокола и без остановки текущей эксплуатации.

Регистрационные сервисы помогают узнать, зарегистрировано ли имя. Регистрация не отвечает, готов ли держатель его уступить. Новый механизм делает приглашение к переговорам обнаружимым. Переговоры и исполнение сознательно остаются вне его рамок.

Строгая версия, свободное продолжение

Начало записи задано точно: v=FORSALE1;, без пробелов и с тем же регистром. Затем допускается не более одной пары tag-value:

  • fcod= — непрозрачный код, смысл которого согласовали взаимодействующие процессоры;
  • ftxt= — краткий текст для человека;
  • furi= — ровно один URI или IRI для информации или контакта;
  • fval= — заглавные буквы валюты и числовая сумма.

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

Следовательно, карточка — результат локальной политики. Одна площадка понимает только собственный fcod, индекс цен забирает только fval, человек видит ftxt и телефон. Ни одна проекция не равна полному RRset. Для аудита сохраняются исходный набор и правило выбора.

При корректной версии и отсутствующем либо неверном дополнительном содержимом процессор обычно должен считать домен продаваемым, если локальная политика не решила иначе. Контакт можно искать обычными средствами регистрации. Но текст без корректной версии не образует индикатор; если ни один TXT не проходит проверку, узел игнорируется.

Версия подтверждает принадлежность сигнала к конвенции. Она не подтверждает представителя держателя.

Смысл fcod живёт вне публичного DNS

Значение fcod определяется соглашением между процессорами. Реестр или группа регистраторов может распознать префикс и направить пользователя на нужную страницу. Адрес меняется централизованно без перепубликации зоны. Это упрощает контроль назначения.

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

ftxt допускает полезное пояснение и вредный ввод. Там возможны управляющие символы, обманный Unicode и опасная разметка. Последовательность ;ftxt= внутри допустимого значения fcod не создаёт второй tag. Парсер, который просто разрезает строку по пунктуации, выдумывает структуру.

furi содержит один машиночитаемый адрес. Рекомендованы HTTP, HTTPS, mailto и tel; при возможности предпочтителен HTTPS. Синтаксическая корректность не означает безопасность. RFC предупреждает о фишинге, вредоносном ПО и скриптах и запрещает автоматическое перенаправление без явного согласия пользователя.

fval делает цену удобной для извлечения. Для фиатных валют рекомендованы стандартные трёхбуквенные коды в верхнем регистре; грамматика допускает и известные обозначения криптоактивов. Сумма прямо названа ориентировочной и необязательной. Автоматическая система не должна обещать покупку по одному этому полю.

Четыре tag помогают начать контакт. Они не описывают объём прав, личность, гарантии, налоги, принятие, escrow или перенос.

255 октетов не превращаются в договор

RDATA каждой TXT-записи состоит из одной character-string длиной не более 255 octets. Разные подсказки публикуются отдельными записями. RFC 1035 задаёт основу TXT и TTL, а RFC 10023 — прикладную грамматику.

Разбор ведётся по сырому RDATA, а не по экранированному представлению утилиты. Для не-ASCII рекомендованы UTF-8 и Network Unicode. Проблемные управляющие символы следует безопасно отображать, не уничтожая оригинал, нужный для проверки.

Короткий формат дисциплинирует полномочия. DNS разносит компактный сигнал, а не контрактное досье. Любое расширенное значение в частном коде принадлежит слою платформы и должно быть проверяемым там.

Положение leaf определяет предмет объявления

_for-sale.example относится к example. Форма xyz._for-sale.example не соответствует правилам, потому что _for-sale уже не leaf. _for-sale.*.example не выставляет все имена зоны одной записью. RFC 4592 объясняет wildcard DNS, а RFC 10023 исключает такую конструкцию.

Существующий wildcard всё же может синтезировать вводящий в заблуждение ответ, особенно вместе с CNAME или DNAME. Сборщик хранит имя запроса, owner ответа, цепочку alias, авторитетность и признаки синтеза. Финальный TXT способен относиться не к тому имени, которое показала витрина.

Leaf разрешён на разных уровнях. Под поддоменом без публичного реестра прав сторонам может потребоваться отдельное соглашение о предмете передачи. Записи под .arpa должны игнорироваться, чтобы их не приняли за продажу адресного пространства или E.164. Special-Use Domains находятся вне области применения.

RFC 8552 описывает регистрацию глобальных подчёркнутых имён для предотвращения столкновения значений. В IANA DNS Parameters теперь есть TXT / _for-sale / RFC 10023. Это свидетельство выделения имени, а не внедрения, истинности или полномочий продавца.

В реестре errata RFC 10023 есть один технический erratum 9090 со статусом Reported. Он оспаривает “Root zone” в первой строке таблицы раздела 2.6 и предлагает TLD или zone apex. Reported не равен Verified; это вопрос для обзора, а не утверждённая нормативная правка.

TTL заканчивается раньше, чем жизнь копии

Когда домен перестаёт быть доступным, индикатор следует удалить. RFC рекомендует TTL не более 3 600 секунд, чтобы старое объявление или цена меньше вводили покупателя в заблуждение.

TTL управляет DNS-кэшем, но не индексом crawler, скриншотом или базой брокера. Он не устанавливает срок юридического предложения. Наблюдение сохраняет время, TTL, resolver, полный ответ и валидацию, а авторитетная перепроверка повторяется при контакте, оферте, акцепте, высвобождении средств и переносе.

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

DNSSEC не проверяет корпоративное решение

RFC 4033 определяет аутентификацию происхождения и целостность DNS-данных в цепочке доверия. Конфиденциальности DNSSEC не даёт. Успешная валидация усиливает утверждение, что RRset аутентифицирован соответствующими DNS-ключами.

Она не доказывает, кто имел право инициировать публикацию.

DNS-провайдер может редактировать зону без контроля регистратора. Украденный токен может внести данные, которые signer добросовестно подпишет. Старая автоматизация может продолжать работу. Контроль ключей зоны и право распоряжения активом — разные полномочия.

RFC 9083 описывает JSON-ответы RDAP с entities, status и nameservers. Данные могут быть скрыты или представлены по ролям. Они сами по себе не подтверждают бенефициара, внутреннее одобрение, мандат брокера или отсутствие спора.

Противоречия нельзя усреднять. Валидный DNSSEC, несовпадающая личность и заблокированный аккаунт регистратора требуют остановки, а не средней оценки доверия.

После сигнала начинается отдельная машина состояний

Наблюдение хранит query, RRset, TTL, DNSSEC, owner и alias. Проверка зоны устанавливает аккаунт, провайдера, credential, делегирование и change log.

Идентификация связывает registrar или RDAP с проверенным юридическим лицом и определяет право: регистрационный контроль, аренда, лицензия, поддомен или пакет активов. Проверка представительства фиксирует объём, предел, срок и отзыв полномочий переговорщика.

Формальная версия условий заменяет DNS-подсказку: цена, валюта, активы, налоги, заверения и акцепт. Платёж и escrow дают своё доказательство. Registrar фиксирует unlock, коды, account push, transfer status и итоговые данные.

Контур непрерывности проверяет nameservers, DNSSEC-ключи и DS, почту, сертификаты, идентификацию, API и продление. Договор, смена записи и работа сервисов — разные завершения.

Running-Code Primacy располагает факты по исполняющим системам: DNS-сервер создаёт наблюдение, validator — безопасность, идентификация и договор — полномочие, registrar — контроль, приложения — результат. Интерфейс не может объявлением исполнить их за всех.

Minimum Initial Specification объясняет ценность малой общей грамматики. Обнаружение становится совместимым без назначения единого рынка, брокера, escrow или права. Локальная политика остаётся экспортируемой и заменимой.

Reality Layers разделяет символ TXT, операционный акт зоны, институциональное право, коммерческое соглашение и опыт непрерывности. Флаг «продажа проверена» сжимает слои и передаёт власть тому, кто рисует флаг.

Data Sovereignty спрашивает о реконструкции. Кто хранит RRset, историю зоны, карту fcod, личности, переговоры, расчёт, transfer и непрерывность, тот контролирует спор. Экспорт одной карточки не даёт клиенту контроля над доказательством.

Источники