Домен теперь может сообщить о продаже прямо через DNS

Что это такое

_for-sale — зарезервированное имя листового узла DNS, определённое в RFC 10023 (информационный статус, июль 2026) и зарегистрированное в IANA. TXT-запись, опубликованная по адресу _for-sale.example.com, сигнализирует, что домен example.com, хотя он зарегистрирован и нормально резолвится, доступен для покупки.

_for-sale IN TXT "v=FORSALE1;furi=https://example.com/for-sale"

Запись содержит обязательный тег версии, за которым следует не более одной пары tag=value:

Первое заблуждение, которое стоит развеять: это не способ парковки домена. Скорее наоборот. Парковка заменяет сайт страницей продажи, и в итоге теряются все посетители, которые ещё заходят на домен. _for-sale существует параллельно с работающим сайтом в DNS и ничего не сообщает браузеру: главная страница продолжает отдаваться, почта продолжает работать, а запись можно добавлять и удалять по желанию. RFC 10023 прямо указывает на это — конвенция спроектирована так, чтобы работать, пока домен ещё активно используется.

Это также не то же самое, что регистрационные данные. WHOIS и RDAP отвечают на вопрос «зарегистрировано ли это имя?»; зарегистрированное имя всё ещё может продаваться, а незарегистрированное может не представлять никакой ценности. Именно этот разрыв и стал причиной появления конвенции — и именно поэтому её целевая аудитория — брокеры и автоматизированные сервисы проверки доступности, а не обычные люди.

Почему это важно

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

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

Как реализовать

Публикуется единственная TXT-запись на листовом узле _for-sale той зоны, которая продаётся, — и только пока продажа действительно актуальна.

; Произвольный текст
_for-sale IN TXT "v=FORSALE1;ftxt=Serious offers only"

; URI для переговоров — рабочие схемы: https, mailto и tel
_for-sale IN TXT "v=FORSALE1;furi=https://example.com/fs?d=eHl6"

; Запрашиваемая цена: код валюты заглавными буквами, затем сумма
_for-sale IN TXT "v=FORSALE1;fval=USD12500"

Правила, которые стоит соблюсти с первого раза:

• Тег версии обязателен и чувствителен к регистру: каждая запись начинается с v=FORSALE1;. Это позволяет обработчику отличить настоящую запись _for-sale от постороннего TXT, случайно совпавшего с этим именем из-за DNS-wildcard.
• Одна пара tag-value на запись. Чтобы опубликовать одновременно цену и контактный URI, публикуются две записи в одном RRset, а обработчик сам выбирает, что понимает. Это не SPF — пары не конкатенируются.
• Одна character-string на запись, максимум 255 октетов, чтобы ничего не приходилось собирать заново при парсинге.
• TTL не выше 3600 секунд. Устаревшая запись, рекламирующая уже отменённую цену или уже проданный домен, хуже, чем отсутствие записи вовсе.
• Размещать на листовом узле. _for-sale.example.com допустим на любом уровне дерева, а вот xyz._for-sale.example.com — нет; записи под .arpa должны игнорироваться — предложение продать адресное пространство выходит за рамки этой конвенции.
• Удалять запись, когда домен больше не продаётся. У конвенции нет значения «не продаётся» — отсутствие записи и есть единственный способ сказать «нет».

Зону желательно подписать с помощью DNSSEC, если это возможно. Неподписанная TXT-запись, утверждающая, что домен продаётся по определённой цене с указанным контактным URI, — удобная цель для подделки.

Сам сайт specification.website записи _for-sale не публикует: он не продаётся.

Типичные ошибки

• Втискивание нескольких пар в одну запись. "v=FORSALE1;fval=EUR2500;furi=https://…" выглядит разумно, но формат такого не предусматривает. Одна пара на запись, несколько записей в одном RRset.
• Публикация «на всякий случай». Индикатор предназначен только для доменов, реально доступных для продажи. Это не рекламный баннер, и запись, существующая ради привлечения запросов, — злоупотребление, которое RFC прямо называет по имени.
• Предположение, что запись к чему-то обязывает. Публикация записи не обязывает владельца продать домен, а указанная цена fval= носит ориентировочный характер — RFC требует от обработчиков показывать дисклеймер и никогда не трактовать цену как обязательство совершить сделку.
• Ожидание, что wildcard покроет всю зону. _for-sale.*.example.com не является допустимым wildcard-шаблоном. Выставить на продажу все домены под доменом верхнего уровня одной записью невозможно.
• Доверие к содержимому. На стороне чтения записи ftxt= — это текст, контролируемый потенциальным злоумышленником, а furi= — потенциально вредоносный URI. Перед выводом на экран содержимое нужно санитизировать — сам RFC в качестве примера содержимого приводит <script>...</script> — и никогда не выполнять автоматический переход по адресу из furi= без явного подтверждения пользователя.

Проверка

dig +short TXT _for-sale.example.com

• Ответ начинается с v=FORSALE1; и содержит не более одной пары tag=value в строке.
• TTL равен 3600 или меньше: dig TXT _for-sale.example.com | grep _for-sale.
• Если зона подписана, dig +dnssec TXT _for-sale.example.com возвращает валидный RRSIG.
• Запись вообще резолвится. В период redemption или pendingDelete, а также при провале DNSSEC-валидации, имя не будет резолвиться, и сигнал молча исчезнет.