Resumo

  • Um TXT conforme ao RFC 10023 fica em _for-sale.<domínio>, começa exatamente com v=FORSALE1; e pode acrescentar uma pista fcod, ftxt, furi ou fval. O domínio pode continuar atendendo usuários.
  • A indicação convida à negociação. O valor de fval não vincula o titular, a URI não ganha reputação por estar no DNS e o DNSSEC autentica dados DNS, não a capacidade jurídica de alienar o nome.
  • Uma compra defensável separa a observação do RRset, o controle da zona, a identidade do registrante, o poder do representante, os termos, o escrow, a mudança no registrar e a continuidade de serviços.

A due diligence que começou tarde demais

Uma equipe de aquisições recebe um domínio já classificado pela plataforma: disponível, preço de 75 mil dólares, contato HTTPS, DNSSEC válido. A automação abriu o caso porque o nome combina com um novo produto. Só depois alguém percebe que o domínio ainda responde por e-mail corporativo e login de clientes de outra empresa.

O problema não é o nome continuar ativo. O RFC permite isso. O problema é a ficha ter condensado uma observação técnica em uma conclusão comercial.

O RRset pode ser autêntico, enquanto a pessoa que alterou a zona não tem autorização para dispor do ativo. O contato pode ser um corretor real com mandato revogado. O valor pode ter sido apenas uma referência. “À venda” pode significar locação ou direito contratual de uso, não transferência do registro. E uma transferência registral bem-sucedida pode interromper DNSSEC, e-mail, certificados e autenticação.

RFC 10023, publicado em julho de 2026 como Informational, define uma convenção operacional pequena. O titular coloca a folha reservada _for-sale na zona para indicar que o domínio pai está disponível para compra. O termo é amplo e pode abranger aluguel ou cessão do direito de uso. A indicação liga e desliga sem mudança do protocolo e sem exigir a retirada dos serviços existentes.

Os sistemas de registro informam se o nome está registrado. Isso não resolve se o titular aceita conversar. O novo nó reduz esse custo de descoberta, deixando negociação e execução fora de seu escopo.

A versão identifica a convenção

O início deve ser v=FORSALE1;, sensível a maiúsculas e sem espaços. Em seguida pode haver apenas um par de tag e valor:

  • fcod= carrega um código opaco para processadores que pactuaram seu significado;
  • ftxt= carrega texto conciso para leitura humana;
  • furi= carrega exatamente uma URI ou IRI de informação ou contato;
  • fval= carrega letras maiúsculas de moeda seguidas de um número.

O RRset pode reunir vários TXT. A mesma tag pode aparecer com valores diferentes, desde que cada par completo seja único. O processador pode escolher um ou mais registros.

Essa escolha deve ficar visível. Uma plataforma pode reconhecer só seu fcod; um índice pode capturar apenas fval; uma ferramenta de consulta pode preferir texto e telefone. Nenhuma dessas telas é o RRset. O arquivo probatório precisa da resposta completa e da regra de seleção.

Um detalhe reforça a diferença entre sinal e complemento. Com versão válida e conteúdo ausente ou inválido, o processador normalmente deve presumir disponibilidade, salvo política local contrária, e pode procurar contato por mecanismos convencionais. Sem versão válida, uma frase de venda não pertence à convenção; se nenhum TXT começar corretamente, o nó deve ser ignorado.

O prefixo responde se a publicação é reconhecível como RFC 10023. Não responde se o interlocutor pode obrigar o titular.

Quatro pistas, quatro riscos

O significado de fcod nasce de acordo externo. Um registro ou grupo de registrars pode mapear um prefixo para uma página de venda e alterar o destino no backend sem editar a zona. Isso dá controle operacional sobre links e conteúdo derivados.

Também esconde uma decisão relevante. Um terceiro não decifra o código pelo RFC. Se o mapa muda, o TXT continua igual, mas o usuário chega a outro lugar. Sem versões históricas do mapa, o marketplace passa a ser o único narrador do que o código significava no momento da consulta.

ftxt aceita explicações úteis e conteúdo hostil. Pode conter caracteres de controle, Unicode enganoso ou marcação perigosa. Uma sequência ;ftxt= dentro de um fcod válido não cria outra tag. Um parser ingênuo que separa por pontuação inventa campos.

furi fornece um endereço interpretável por máquina. HTTP, HTTPS, mailto e tel são recomendados, com preferência por HTTPS quando aplicável. Uma URI sintaticamente correta ainda pode apontar para phishing, malware ou scripts. O RFC proíbe redirecionar sem confirmação explícita do usuário.

fval permite extrair o preço. Moedas fiduciárias padronizadas usam três letras maiúsculas; abreviações de criptoativos também cabem na gramática. O valor é expressamente indicativo e não vinculante. Sistemas automatizados não devem comprometer uma compra apenas com esse número.

Essas tags organizam o primeiro contato. Não definem o direito vendido, o agente, os ativos anexos, tributos, garantias, aceitação, pagamento ou transferência.

Um sinal curto exige um parser rigoroso

O RDATA de cada TXT é uma única character-string de até 255 octetos. Informações diferentes ocupam registros diferentes. O RFC 1035 fornece a base do TXT e do TTL; o RFC 10023 define a aplicação.

O parser trabalha sobre RDATA bruto, não sobre o formato escapado apresentado por uma ferramenta. Conteúdo não ASCII deve seguir as recomendações de UTF-8 e Network Unicode. Controles inesperados precisam ser neutralizados na exibição, preservando o valor original para auditoria.

O limite evita que o DNS vire um prospecto. A camada compartilhada transporta uma afirmação pequena. Regras extensas codificadas em texto ou formatos proprietários pertencem ao processador e precisam de sua própria governança.

O pai depende da posição da folha

_for-sale.example se refere a example. xyz._for-sale.example não está conforme porque _for-sale deixou de ser folha. _for-sale.*.example não oferece todos os nomes da zona em uma única publicação. O RFC 4592 dá o contexto de wildcards, e o RFC 10023 rejeita essa forma.

Wildcards já existentes ainda podem sintetizar respostas confusas, principalmente em conjunto com CNAME ou DNAME. O coletor deve reter nome consultado, proprietário da resposta, cadeia de aliases, autoridade e indícios de síntese. O TXT final isolado pode atribuir a oferta ao nome errado.

A folha cabe em vários níveis do DNS. Sob um subdomínio sem registro público de direitos, as partes talvez precisem formalizar separadamente o que se transfere. Registros sob .arpa devem ser ignorados para não parecer que espaço de endereços ou numeração E.164 está à venda. Nomes de uso especial ficam fora do escopo.

O RFC 8552 explica como nomes globais sublinhados evitam colisões entre aplicações. O registro IANA de parâmetros DNS lista TXT / _for-sale / RFC 10023. A inscrição prova a alocação da combinação, não a implantação, a veracidade nem a autoridade do vendedor.

O registro de errata do RFC 10023 tem um item técnico, erratum 9090, no estado Reported. Ele questiona “Root zone” na primeira linha da tabela da Seção 2.6 e propõe TLD ou zone apex. Reported não é Verified; trata-se de um ponto de revisão, não de correção normativa confirmada.

TTL limita cache, não intenção

O titular deve remover o indicador quando a disponibilidade termina. O RFC recomenda TTL de 3.600 segundos ou menos, pois um cache longo pode manter uma oferta retirada ou um preço antigo.

Esse tempo não governa a base de um crawler, uma captura ou o sistema de um corretor. Tampouco é o prazo jurídico da oferta. Cada observação precisa guardar horário, TTL, resolver, resposta completa e estado de validação, com nova consulta autoritativa nos marcos do negócio.

Ausência também não equivale a indisponibilidade. Redemption, pendingDelete ou DNSSEC bogus podem impedir a resolução. Um sistema deve registrar por que não obteve resposta antes de inferir vontade comercial.

DNSSEC não conhece a procuração

O RFC 4033 define autenticação de origem e integridade dos dados DNS dentro da cadeia de confiança. DNSSEC não fornece confidencialidade. Uma validação bem-sucedida fortalece a prova de que o RRset é o dado autenticado sob as chaves pertinentes.

Ela não mostra quem autorizou a alteração.

Um provedor pode editar a zona sem controlar o registro. Uma credencial comprometida pode injetar conteúdo que o signer assina corretamente. Uma automação esquecida pode sobreviver ao funcionário. Controle DNS e poder de alienação não são o mesmo papel.

O RFC 9083 descreve respostas JSON de RDAP para entidades, estados e nameservers. Os dados podem ser redigidos ou expressos por função. Não comprovam sozinhos beneficiário, aprovação interna, mandato do corretor ou ausência de disputa.

Conflitos entre camadas precisam permanecer conflitos. DNSSEC válido, identidade divergente e conta bloqueada não formam confiança média; formam uma pausa.

Oito controles para chegar ao fechamento

Descoberta preserva consulta, RRset, TTL, aliases e DNSSEC. Controle de zona identifica conta, provedor, credencial, delegação e registro de mudança.

Identidade reconcilia registrar ou RDAP com a pessoa jurídica e define o direito oferecido: controle registral, locação, licença, subdomínio ou pacote de ativos. Representação prova escopo, limite, validade e revogação do negociador.

O contrato substitui a pista DNS por termos versionados: preço, moeda, ativos, impostos, garantias e aceite. Pagamento e escrow produzem evidência própria. O registrar produz outra: desbloqueio, código, account push, estado de transferência e dados finais.

Continuidade verifica nameservers, chaves e DS de DNSSEC, e-mail, certificados, identidade, APIs e renovação. Fechar o negócio, transferir o cadastro e manter o serviço são três resultados.

Running-Code Primacy localiza os atos: servidor DNS cria a observação; validator cria o resultado criptográfico; identidade e contrato criam autoridade; registrar altera controle; aplicações criam continuidade. Nenhum badge executa todos eles por declaração.

Minimum Initial Specification justifica a pequena camada comum. A descoberta pode ser precisa sem impor marketplace, corretor, escrow ou regime jurídico. Decisões locais continuam legítimas quando são exportáveis e substituíveis.

Reality Layers separa TXT simbólico, publicação operacional, direito institucional, acordo comercial e experiência de serviço. “Venda verificada” comprime essas realidades e dá poder a quem controla a interface.

Data Sovereignty pergunta quem consegue reconstruir. Quem detém RRset, histórico de zona, mapa fcod, identidades, negociação, pagamento, transferência e continuidade controla a explicação. Exportar apenas a ficha priva o cliente de soberania probatória.

Fontes