Resumen

  • Un TXT válido de RFC 10023 vive en _for-sale.<dominio>, empieza exactamente por v=FORSALE1; y puede añadir una sola pista fcod, ftxt, furi o fval. Puede publicarse mientras el dominio continúa prestando servicio.
  • La convención declara disponibilidad, no transmite derechos. fval es orientativo, una URI válida puede ser maliciosa y DNSSEC autentica datos DNS sin certificar la capacidad jurídica de vender.
  • El comprador necesita pruebas independientes de control de zona, titularidad registral, identidad, representación, condiciones, custodia del pago, transferencia en el registrar y continuidad de DNS, correo, certificados y aplicaciones.

La adquisición que empezó con una celda verde

Una herramienta de inteligencia de activos añade un dominio a su tabla de oportunidades. La celda de precio dice 75.000 dólares. La de contacto contiene HTTPS. La de seguridad dice “DNSSEC validado”. El nombre aún sostiene correo corporativo, autenticación y una API de clientes, pero el flujo automático ya ha asignado un analista para iniciar la compra.

La tabla ha confundido capas.

Puede haber observado correctamente el RRset y aun así no saber si el administrador de DNS tenía poder para disponer del activo. Puede haber mostrado una cifra auténtica pero retirada. El enlace puede pertenecer a un intermediario sin mandato vigente. La disponibilidad puede referirse a un arrendamiento, no al control registral. El cambio de cuenta puede completarse y dejar rotos DNSSEC, certificados o correo.

RFC 10023 no promete resolver esas cuestiones. Publicado en julio de 2026 como RFC Informational, crea una convención operacional para colocar el nodo reservado _for-sale bajo el nombre que se ofrece. “For sale” abarca en sentido amplio la compra, el arrendamiento o el derecho contractual de uso. La publicación puede activarse sin modificar el protocolo y sin interrumpir el dominio.

El problema que resuelve es anterior a la venta. WHOIS o RDAP pueden ayudar a saber si un nombre está registrado, pero registrado no significa inaccesible. La nueva señal permite que la voluntad de conversar sea detectable. El resto del proceso queda fuera de alcance por diseño.

La versión válida puede existir sin un contacto válido

El prefijo es estricto y sensible a mayúsculas: v=FORSALE1;, sin espacios. Después puede ir una sola pareja etiqueta-valor. Las cuatro etiquetas iniciales son:

  • fcod=: código opaco interpretado por procesadores que han pactado su significado;
  • ftxt=: texto breve para una persona;
  • furi=: exactamente una URI o IRI de contacto o información;
  • fval=: letras mayúsculas de moneda seguidas por un importe numérico.

Un RRset puede contener varias entradas TXT. Se permiten varias instancias de una etiqueta si cada pareja completa es distinta. El procesador puede elegir una o más.

Por eso el resultado de un buscador nunca debe confundirse con la publicación completa. Un mercado reconoce su propio prefijo fcod; otro solo indexa precios; una consola prioriza texto y teléfono. Cada selección puede ser conforme y, a la vez, incompleta. El expediente debe guardar el RRset íntegro y la regla que generó la pantalla.

La lógica de ausencia también importa. Con una versión válida y contenido ausente o inválido, el procesador normalmente debe asumir que el nombre está disponible, salvo que su política local diga lo contrario. Puede recurrir a mecanismos convencionales para buscar contacto. Sin una versión válida, una frase comercial cualquiera no es un indicador de RFC 10023; si ningún registro supera ese umbral, el nodo se ignora.

La versión responde “¿pertenece esta señal a la convención?”. No responde “¿está autenticado el vendedor?”.

Los cuatro campos no comparten la misma semántica

fcod delega la interpretación a un acuerdo externo. Un registro o un conjunto de registrars puede convertir un código con prefijo reconocible en una página concreta. La asociación se modifica en un backend sin tocar el DNS. Así se conserva control sobre los destinos y se evita publicar enlaces arbitrarios en la zona.

También se crea una dependencia que no aparece en el RRset. Un tercero no conoce el código. Si la tabla cambia, el mismo valor DNS produce otro resultado. Sin historial de versiones, nadie puede reconstruir adónde enviaba el procesador a un comprador una semana antes. El dueño de la tabla controla el significado práctico.

ftxt admite una explicación legible, pero es entrada no confiable. Puede incluir caracteres de control, Unicode engañoso o marcado peligroso. Incluso puede aparecer la secuencia ;ftxt= dentro de un fcod válido sin crear otra etiqueta. Un parser que divide por signos familiares inventa estructura.

furi ofrece una ruta interpretable por máquinas. Se recomiendan HTTP, HTTPS, mailto y tel; HTTPS es preferible cuando corresponda. La sintaxis no garantiza reputación. RFC 10023 advierte de phishing, malware y ataques de script, y prohíbe la redirección automática sin confirmación explícita del usuario.

fval hace que un precio sea fácil de extraer. Las monedas fiduciarias estándar deben expresarse con tres letras mayúsculas; la gramática también admite abreviaturas reconocidas de criptoactivos. El importe es expresamente indicativo y no vinculante. Un compromiso requiere información actual obtenida directamente y verificación humana.

No hay en esos campos una oferta completa: faltan el derecho exacto, la identidad, la autoridad, los activos incluidos, impuestos, garantías, aceptación, pago y transferencia.

El límite de 255 octetos protege la humildad del mecanismo

Cada RDATA debe constar de una única character-string y no superar 255 octetos. Las distintas pistas ocupan distintos TXT. RFC 1035 define las bases de TXT y TTL; RFC 10023 añade la gramática del uso concreto.

El código debe analizar el RDATA crudo, no el formato de presentación escapado que muestra una herramienta. Los valores no ASCII necesitan disciplina UTF-8 y Network Unicode. Los caracteres de control inesperados deben neutralizarse al presentar el texto sin destruir la evidencia original.

Un formato breve obliga a reconocer la frontera: DNS distribuye señales compactas con eficiencia, no un dossier contractual. Si una plataforma introduce políticas extensas mediante códigos privados, esas políticas pertenecen a la plataforma y deben auditarse como tal.

El lugar del guion bajo fija el objeto de la señal

_for-sale.example habla de example. xyz._for-sale.example no es conforme porque _for-sale deja de ser la hoja. _for-sale.*.example tampoco pone en venta de una vez todos los nombres. RFC 4592 proporciona el contexto de comodines y RFC 10023 descarta esa construcción.

Un comodín existente sí puede sintetizar respuestas desconcertantes, especialmente con CNAME o DNAME. El recolector debe conservar nombre consultado, propietario de respuesta, cadena de alias, autoridad y contexto de síntesis. El TXT final puede apuntar al nombre equivocado.

La hoja puede usarse a distintos niveles. Bajo un subdominio sin registro público de derechos, las partes necesitarán un acuerdo que defina qué control se transfiere. Los registros bajo .arpa deben ignorarse para no confundir el mecanismo con una venta de espacio IP o numeración E.164. Los nombres de uso especial también quedan fuera de alcance.

RFC 8552 explica el registro de nombres globales con guion bajo para evitar colisiones de significado. El registro IANA de parámetros DNS incluye TXT / _for-sale / RFC 10023. Esa entrada reserva una combinación, no verifica un anuncio, una implantación ni una autoridad comercial.

El registro oficial de erratas contiene el erratum técnico 9090, con estado Reported. Discute que la primera fila de la tabla de la sección 2.6 diga “Root zone” y propone describir un TLD o el ápice de zona. No está Verified: es una observación de revisión, no una corrección normativa consumada.

El caché caduca; la copia del mercado no

Cuando el nombre deja de estar disponible, el titular debe retirar el indicador. RFC 10023 recomienda un TTL de 3.600 segundos o menos para reducir el riesgo de que un comprador vea una disponibilidad o un precio antiguos.

El TTL no borra índices, capturas ni bases comerciales. Tampoco convierte una hora en el plazo legal de una oferta. La observación debe registrar momento, TTL, resolver, respuesta completa y validación, y repetirse contra una fuente autoritativa en cada hito de la operación.

La no aparición tampoco demuestra que no haya voluntad de vender. Un periodo de redemption, un estado pendingDelete o una validación DNSSEC bogus pueden impedir la resolución. La ausencia tiene causas operativas que el formulario comercial no ve.

Una firma DNS no es una firma societaria

RFC 4033 define el beneficio de DNSSEC: autenticación de origen e integridad de datos DNS dentro de una cadena de confianza. No aporta confidencialidad. Validar el RRset permite afirmar con más solidez que esos datos fueron autenticados bajo las claves DNS pertinentes.

No permite afirmar que la persona que causó el cambio podía vender.

Un proveedor DNS puede administrar la zona sin controlar la inscripción. Una credencial comprometida puede publicar un registro que el firmante de zona procesa correctamente. Un empleado antiguo puede dejar una automatización viva. El control de la clave de zona y el poder de representación son hechos distintos.

RFC 9083 describe respuestas JSON de RDAP que permiten revisar entidades, estados y nameservers. La información puede estar redactada o organizada por roles. No prueba automáticamente propiedad beneficiaria, aprobación interna, poder de un broker ni ausencia de cargas o disputa.

No conviene convertir contradicciones en promedios. Señal DNSSEC válida, identidad no conciliada y cuenta bloqueada no producen una compra “moderadamente segura”; producen preguntas con capacidad de detenerla.

Ocho expedientes para una sola adquisición

El expediente de descubrimiento conserva consulta, hora, RRset, TTL, DNSSEC, propietario de respuesta y alias. El de control de zona identifica cuenta, proveedor, credencial, delegación y cambio que publicaron el dato.

El expediente de identidad verifica al sujeto y el derecho ofrecido: control registral, alquiler, licencia, subdominio o un paquete mayor. El de representación documenta mandato, alcance, límite, caducidad y revocación del negociador.

El expediente contractual reemplaza la pista DNS con términos versionados: precio actual, moneda, activos, impuestos, declaraciones, garantías y aceptación. El de liquidación separa fondos, escrow y liberación. El de transferencia conserva desbloqueo, códigos, account push, estados y registro final.

El de continuidad comprueba nameservers, claves y DS de DNSSEC, correo, certificados, identidad, API y renovación. Comprar el nombre y mantener el sistema son resultados diferentes.

Running-Code Primacy ordena esos actos. El servidor DNS produce la señal; el validador produce un estado criptográfico; identidad y contrato establecen personas y poderes; el registrar cambia el control; los servicios producen el resultado. Ningún documento recibe por contagio la autoridad de todos.

Minimum Initial Specification muestra la virtud de una norma común estrecha. Se comparte una sintaxis de descubrimiento sin consagrar un mercado, un broker, un escrow o un régimen jurídico. Las decisiones locales deben seguir siendo exportables y sustituibles.

Reality Layers separa símbolo TXT, acto operacional, derecho institucional, acuerdo comercial y experiencia de continuidad. “Venta verificada” los comprime y concede poder a quien diseña la etiqueta.

Data Sovereignty pregunta quién puede reconstruir el caso. El control práctico pertenece a quien conserva RRset, cambios de zona, mapa fcod, identidades, negociación, pago, transferencia y continuidad. Una tarjeta exportada sin esos materiales deja al cliente sin soberanía probatoria.

Fuentes