⏱️ Lectura: 11 min
Desde julio de 2026 existe un registro DNS for-sale estandarizado para decir, sin ambigüedad, que un dominio activo está a la venta: sin tocar el sitio que ya sirve ni el correo que ya funciona. Se llama _for-sale, es un registro TXT reservado, y quedó definido en RFC 10023, publicado como Informational y registrado ante IANA.
📑 En este artículo
El problema que resuelve es puntual: hoy, si el dueño de un dominio activo quiere venderlo, no tiene un canal confiable para avisarlo. Un correo frío al contacto de WHOIS, que la privacidad probablemente ya ocultó, es la única vía disponible. _for-sale mueve esa señal a donde los brokers y los servicios de disponibilidad automatizados ya buscan: el propio DNS.
TL;DR
- RFC 10023 (Informational, julio de 2026) estandariza el registro DNS
_for-saley lo registra ante IANA. - El TXT se publica en
_for-sale.dominio.comsin afectar el sitio, el correo ni ningún otro servicio del dominio. - Formato obligatorio: empieza con
v=FORSALE1;seguido de un único partag=value(ftxt, furi, fval o fcod). - Solo se permite un par por registro: para precio y contacto a la vez hacen falta dos registros TXT en el mismo RRset.
- El límite es 255 octetos por character-string y se recomienda un TTL de 3600 segundos o menos.
- No sustituye a WHOIS ni a RDAP: un dominio registrado puede seguir en venta, y ese vacío es justo lo que resuelve.
- La RFC recomienda firmar la zona con DNSSEC, porque un TXT sin firmar con precio y contacto es fácil de falsificar.
- specification.website, la fuente de este artículo, aclara que su propio dominio no publica el registro: no está en venta.
Qué pasó
RFC 10023 reserva formalmente el nombre de nodo hoja _for-sale dentro del árbol DNS y lo registra en IANA como espacio de nombres bajo guion bajo (underscore name), la misma familia técnica que ya usan _dmarc para las políticas de correo o _acme-challenge para validar certificados. La especificación completa, con la tabla de tags y los errores comunes de implementación, está publicada en specification.website.
Un registro mínimo se ve así:
_for-sale IN TXT "v=FORSALE1;furi=https://miempresa.com/en-venta"La regla central es que ese TXT no cambia nada de lo que el dominio ya hace. El homepage sigue respondiendo, el correo sigue entregándose, y el registro se puede agregar o quitar sin ningún efecto colateral en el tráfico. Un navegador nunca lo ve: solo lo consultan quienes ya saben buscarlo.
Contexto e historia
La confusión más común es pensar que _for-sale es una forma de parking. Es casi lo contrario. Parquear un dominio reemplaza el sitio con una página de ventas, lo que cuesta cada visita que el dominio todavía recibe. _for-sale convive con un sitio activo sin decirle nada al navegador.
Tampoco es lo mismo que los datos de registro. WHOIS y RDAP responden una pregunta distinta: ¿este nombre está registrado? Un nombre registrado puede seguir estando a la venta, y uno sin registrar puede no valer nada. Esa diferencia es la razón por la que la convención existe, y explica por qué el público objetivo son brokers y servicios automatizados de disponibilidad, no personas navegando a mano.
Detalles técnicos y rendimiento del registro DNS for-sale
El registro admite cuatro tags, y cada TXT lleva como máximo uno:
| Tag | Significado | Ejemplo | Cuándo usarlo |
|---|---|---|---|
ftxt= |
Texto libre legible por humanos | ftxt=Solo ofertas serias |
Aclarar condiciones sin dar contacto directo |
furi= |
URI de contacto o información | furi=mailto:[email protected] |
Canalizar ofertas a un único punto |
fval= |
Precio pedido: moneda + monto | fval=USD12500 |
Cuando el precio es fijo y público |
fcod= |
Código propietario, por acuerdo previo | fcod=XX-aHR0cHM... |
Integraciones broker-plataforma con formato propio |
Las reglas de formato son estrictas a propósito, para que un procesador automatizado no tenga que adivinar nada:
- El tag de versión es obligatorio y sensible a mayúsculas: todo registro arranca con
v=FORSALE1;. Existe para que un procesador distinga un_for-salereal de un TXT sin relación que un wildcard de DNS expandió por accidente hacia ese nombre. - Un solo par tag-value por registro. Para publicar precio y URI de contacto a la vez, se publican dos registros en el mismo RRset y el procesador elige el que entiende. No es como SPF: los pares no se concatenan.
- Un character-string por registro, con un máximo de 255 octetos, para que nada tenga que reensamblarse durante el parseo.
- El TTL recomendado es 3600 segundos o menos. Un registro desactualizado que anuncia un precio ya retirado, o un dominio ya vendido, es peor que no tener registro.
- El registro va en un nodo hoja.
_for-sale.miempresa.comes válido en cualquier nivel del árbol, peroalgo._for-sale.miempresa.comno lo es, y los registros bajo.arpadeben ignorarse: una oferta de venta de espacio de direcciones queda fuera del alcance.
Así se ve el flujo cuando un broker consulta un dominio candidato:
sequenceDiagram
participant B as Broker
participant D as Resolver DNS
participant Z as Zona del dominio
B->>D: consulta TXT _for-sale.midominio.com
D->>Z: resuelve el registro
Z-->>D: v=FORSALE1;fval=USD12500
D-->>B: responde con el TXT
Note over B,Z: el sitio web nunca participa en la consulta⚠️ Ojo: un TXT sin firmar que anuncia precio y contacto es un objetivo cómodo para falsificar. La RFC recomienda firmar la zona con DNSSEC antes de publicar el registro.
Cómo empezar a implementarlo
Publicar el registro DNS for-sale es una sola línea en el archivo de zona, en el nodo hoja _for-sale de la zona que se vende, y solo mientras la oferta siga en pie:
; Zona: midominio.com
_for-sale IN TXT "v=FORSALE1;fval=USD12500"
_for-sale IN TXT "v=FORSALE1;furi=https://midominio.com/en-venta"Con eso, cualquier broker o servicio de disponibilidad que ya resuelve el dominio obtiene, con una consulta extra, algo que una página renderizada no puede decir: que lo que hay debajo es negociable.
Para confirmar que el registro está publicado y bien formado, la consulta cambia según el sistema operativo:
Linux (Debian/Ubuntu):
sudo apt install -y dnsutils
dig +short TXT _for-sale.midominio.commacOS:
brew install bind
dig +short TXT _for-sale.midominio.comWindows:
nslookup -type=TXT _for-sale.midominio.com
REM alternativa con dig, via Chocolatey
choco install bind-toolsonly -y
dig +short TXT _for-sale.midominio.comLa respuesta debe empezar con v=FORSALE1; y contener como máximo un par tag=value por string. Para revisar el TTL específicamente:
dig TXT _for-sale.midominio.com | grep _for-sale💡 Tip: si el dominio ya no está a la venta, borrar el registro es la única forma de decir que no: la convención no define un valor de «no en venta».
Del lado de quien lee el registro, el contenido de ftxt= y furi= está controlado por quien lo publicó, no por vos. La RFC lo dice explícito con un ejemplo de <script>...</script> como contenido posible. Cualquier procesador tiene que sanear antes de mostrar, y nunca navegar automáticamente a un furi= sin una confirmación explícita del usuario:
// saneaSenalForSale.js
const dns = require('node:dns').promises;
async function leerForSale(dominio) {
const registros = await dns.resolveTxt(`_for-sale.${dominio}`);
const valor = registros.map(partes => partes.join('')).join('');
if (!valor.startsWith('v=FORSALE1;')) return null;
const par = valor.slice('v=FORSALE1;'.length);
const [tag, ...resto] = par.split('=');
const contenido = resto.join('=');
const escapado = contenido.replace(/[<>&\"]/g, c => ({
'<': '<', '>': '>', '&': '&', '\"': '"'
}[c]));
return { tag, valor: escapado };
}
leerForSale('midominio.com').then(console.log);El script resuelve el TXT, valida el prefijo de versión, separa el tag del valor y escapa caracteres antes de devolverlo. Con un dominio que publique fval=USD12500, la salida esperada es { tag: 'fval', valor: 'USD12500' }.
Impacto y análisis
El punto de diseño más relevante es que el registro no le pide permiso a nadie ni obliga a nadie. Publicarlo no compromete al dueño del dominio a vender, y un fval= publicado es indicativo: la RFC instruye a los procesadores a mostrar una aclaración y a no tratarlo nunca como un compromiso de compra.
Para brokers y marketplaces de dominios, el ahorro es de una consulta: si ya resuelven el nombre para verificar disponibilidad, sumar una consulta TXT a _for-sale les da una señal que antes no existía en ningún protocolo estándar. No hay forma de decir «todo un dominio bajo esta TLD está en venta» con un solo registro, porque _for-sale.*.miempresa.com no es un wildcard válido: cada dominio necesita su propio TXT.
💭 Clave: publicar el registro de forma aspiracional, para atraer consultas que no son reales, es exactamente el abuso que la RFC nombra explícitamente como mal uso de la convención.
La limitación honesta es que RFC 10023 es Informational, no Standards Track. Eso significa que ningún registrador ni panel de DNS está obligado a facilitar la edición de nombres con guion bajo, y que la adopción depende de que brokers, registradores y paneles decidan soportarlo. Publicar el TXT a mano en un proveedor que no expone edición de subdominios con underscore puede requerir soporte técnico o un proveedor de DNS distinto.
Qué sigue
Lo siguiente depende de la adopción, no de la especificación: si algún registrador grande agrega un campo de «publicar _for-sale» en su panel, o si algún marketplace de dominios empieza a consultar el TXT como parte de su flujo de tasación, la convención pasa de ser un truco de DNS a una señal de mercado real. Hasta entonces, cualquiera puede probarla hoy mismo con acceso de escritura a su zona.
📖 Resumen en Telegram: Ver resumen
Probalo vos: publicá un TXT de prueba en _for-sale.tudominio.com y corré dig +short TXT _for-sale.tudominio.com para confirmar en minutos si tu proveedor de DNS lo soporta.
Preguntas frecuentes
¿_for-sale reemplaza a parquear un dominio?
No. Parquear reemplaza el sitio con una página de ventas y pierde el tráfico que el dominio todavía recibe. _for-sale convive con un sitio activo sin tocarlo.
¿Puedo publicar precio y contacto en el mismo registro?
No en el mismo string. Cada registro TXT lleva un único par tag-value; para precio y contacto hacen falta dos registros TXT en el mismo RRset.
¿_for-sale reemplaza a WHOIS o RDAP?
No, responde una pregunta distinta. WHOIS y RDAP confirman si un nombre está registrado; _for-sale confirma si, estando registrado, su dueño lo vende.
¿Es obligatorio DNSSEC para usar _for-sale?
No es obligatorio, pero la RFC lo recomienda: sin firma, cualquiera puede forjar un TXT con un precio y un contacto falsos.
¿Qué pasa si quiero retirar la oferta?
Se borra el registro. La convención no define un valor de «no en venta»: la ausencia del TXT es la única forma de decir que no.
¿Puedo poner en venta todos los dominios bajo una TLD con un solo registro?
No. _for-sale.*.miempresa.com no es un wildcard válido; cada dominio necesita su propio registro TXT.
Referencias
- specification.website: _for-sale DNS records: la especificación completa con la tabla de tags, reglas de implementación y errores comunes.
- IANA: autoridad que registra espacios de nombres reservados como _for-sale dentro del DNS.
- RFC Editor: repositorio oficial de RFCs del IETF, donde se publican documentos como RFC 10023.
- Wikipedia: TXT record: contexto general sobre el tipo de registro DNS que usa esta convención.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Lightsaber Collection en Unsplash
0 Comentarios