Resposta rápida
Se seu cliente consulta ou altera as configurações de DNS da Cloudflare, aceite agora o valor cloudflare.advanced em nameservers.type. Para novas escritas, envie esse campo no lugar de foundation_dns. O booleano antigo continua disponível temporariamente como alias depreciado, mas será removido em uma mudança futura.
A implantação começou em 26 de outubro de 2026 e deve levar sete dias. Antes de ela alcançar uma conta, uma zona com Advanced Nameservers ainda pode responder cloudflare.standard junto de foundation_dns igual a true. Não desative o recurso nem envie um PATCH corretivo só por causa dessa combinação: atualize o parser, teste as duas respostas e só altere uma zona com mudança aprovada.
O que mudou nos endpoints de DNS
A Cloudflare começou a representar Advanced Nameservers como nameservers.type igual a cloudflare.advanced nos endpoints /zones/{zone_id}/dns_settings e /accounts/{account_id}/dns_settings. A alteração é gradual, por conta, e não acontece ao mesmo tempo para todos os consumidores da API.
Durante a transição, a API aceita cloudflare.advanced em requisições PATCH para contas elegíveis. O campo foundation_dns pode continuar aparecendo e sendo aceito, mas existe apenas para compatibilidade. A orientação oficial é usar o novo tipo em escritas novas e remover a dependência do booleano depois que a migração estiver validada.
Quem pode ter o cliente quebrado
O risco principal está em SDKs gerados, tipos TypeScript, schemas JSON, validadores e regras de infraestrutura que tratam nameservers.type como enum fechado. Um valor desconhecido pode causar erro de desserialização, descartar a resposta ou interromper uma reconciliação mesmo quando o DNS da zona continua respondendo normalmente.
Também há risco em automações que traduzem foundation_dns diretamente para cloudflare.standard ou que enviam de volta todo o objeto recebido. Se um PATCH incluir os dois campos, eles precisam representar a mesma configuração. A API rejeita valores conflitantes, portanto não use uma tentativa automática para decidir qual campo deve prevalecer.
- Procure por foundation_dns e pela lista de valores aceitos em nameservers.type no código, nos schemas e nas políticas de infraestrutura.
- Adicione cloudflare.advanced aos tipos antes de remover o caminho de leitura legado.
- Crie fixtures com a resposta antiga e a nova resposta para reproduzir o rollout.
- Impeça que uma leitura incompleta gere automaticamente um PATCH de correção.
- Registre o valor desconhecido e pare a reconciliação de forma segura, sem ocultar o erro nem alterar DNS.
Como ler a resposta durante os sete dias
Depois que a mudança chega à conta, cloudflare.advanced é a indicação direta de Advanced Nameservers. Antes disso, cloudflare.standard com foundation_dns igual a true ainda pode representar uma zona que já usa o recurso. Trate essa combinação como estado legado de transição, não como pedido para voltar aos nameservers padrão.
Se os dois campos aparecerem e discordarem fora da combinação transitória documentada, preserve a resposta e investigue antes de escrever. Não faça inferência apenas pelo nome dos servidores nem dependa de um prazo local exato para o rollout. Um leitor compatível deve tolerar o formato antigo, reconhecer o novo e manter valores desconhecidos visíveis para análise.
- Se nameservers.type for cloudflare.advanced, reconheça Advanced Nameservers.
- Se o tipo for cloudflare.standard e foundation_dns for true durante o rollout, marque o estado como compatibilidade legada e não faça downgrade.
- Se foundation_dns estiver ausente, use nameservers.type como fonte principal.
- Se surgir um valor de tipo desconhecido, interrompa somente a automação afetada e gere um alerta sem segredo.
Como escrever sem enviar campos conflitantes
Para código novo, envie somente nameservers.type com cloudflare.advanced quando a intenção aprovada for ativar ou manter Advanced Nameservers. Evite serializar foundation_dns de volta por padrão. Se uma integração antiga ainda precisar enviar os dois campos durante a transição, calcule ambos a partir de uma única decisão e teste que nunca possam divergir.
Não use PATCH apenas para conferir compatibilidade do parser. Esse método altera a configuração da zona ou dos padrões da conta. Primeiro teste GETs, respostas gravadas e validação local. Quando uma escrita for indispensável, use uma zona de teste elegível, token com escopo mínimo e revisão explícita do payload, sem publicar account ID, zone ID ou credencial.
Teste a migração sem mudar o DNS de produção
Monte uma matriz com a resposta anterior, a resposta nova e um valor futuro desconhecido. Confirme que o cliente lê todas sem converter estado, disparar PATCH ou apagar propriedades. Depois valide um GET real em uma conta autorizada e compare o resultado com o painel, sem registrar o cabeçalho Authorization.
Monitore erros de enum, respostas 4xx e reconciliações suspensas por conta. Um 400 logo após essa mudança pode ser um payload com foundation_dns e nameservers.type incompatíveis, mas o código e o corpo de erro precisam confirmar isso. Consulte o Cloudflare Status para incidentes amplos; ele não valida a sua permissão, elegibilidade ou lógica de cliente.
- Atualize o schema e rode testes unitários com os formatos antigo, novo e desconhecido.
- Faça GET da configuração de uma zona autorizada e guarde apenas os campos necessários, sem tokens.
- Confirme que nenhuma leitura dispara escrita automática durante o período de observação.
- Use PATCH somente em uma zona de teste e revise o JSON final antes do envio.
- Valide resolução DNS e HTTPS depois de qualquer alteração aprovada.
Ativar Advanced Nameservers é outra mudança
Adaptar o cliente ao novo contrato não ativa Advanced Nameservers. O recurso é opt-in para contas Enterprise com Foundation DNS. A própria Cloudflare afirma que a atualização da API não muda a assinatura, não altera se o recurso está habilitado e não exige migração da zona.
Se a intenção for realmente ativar o recurso, siga o procedimento oficial separado. Depois da ativação, a API retorna os nameservers atribuídos e o responsável deve atualizá-los no registrador. A documentação também alerta que Advanced Nameservers e configurações personalizadas têm restrições próprias; isso deve entrar em uma janela operacional, não na simples correção do parser.
Limitações e próxima ação útil
Este guia foi verificado em 26 de outubro de 2026, no primeiro dia de um rollout previsto para sete dias. O formato ainda pode variar entre contas durante esse período. A Cloudflare não informou neste anúncio a data da remoção de foundation_dns, apenas que ela ocorrerá em uma mudança futura. Não invente um prazo interno nem remova a leitura legada antes de observar todos os ambientes necessários.
A próxima ação é pesquisar foundation_dns e o enum de nameservers.type no repositório. Atualize o leitor hoje, adicione fixtures para os dois formatos e bloqueie PATCHs automáticos gerados por estado ambíguo. Só depois planeje a remoção do alias, com telemetria que confirme que nenhuma conta ainda depende da resposta antiga.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- Advanced Nameservers use a nameserver typeCloudflare Changelog
- Set up advanced nameserversCloudflare Docs
- Advanced nameserversCloudflare Docs
- Foundation DNSCloudflare Docs
- Zones APICloudflare API
- Cloudflare StatusCloudflare