Ferramentas populares

Tema

Consulta NS — Verificar Nameservers de Domínio

Faça a consulta NS de qualquer domínio: os registros NS que o registro dele entrega, com glue e TTL, ao lado do que cada servidor de nomes diz de si mesmo. Para consultar NS e achar o problema, apontamos servidores lame, divergências e glue desatualizado, com a correção.

Fontes: os servidores do registro, alcançados a partir de um servidor raiz · os endereços IPv4 de cada servidor de nomes, consultados diretamente · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · RDAP

Pergunta primeiro ao registro e depois a cada servidor de nomes que ele indica. Uma URL, um e-mail ou um subdomínio também servem.

Experimente

O que é um registro NS?

Um registro NS nomeia um servidor que guarda uma zona: o lugar onde ficam os registros de um domínio. Uma zona lista um registro NS por servidor, então google.com tem quatro, ns1 a ns4.google.com (RFC 1035 §3.3.11).

Os mesmos registros NS existem em dois lugares. A zona pai, aqui o .com, guarda uma cópia no ponto de corte para poder encaminhar os resolvedores; essa cópia não é autoritativa. A zona guarda a própria cópia no topo dela, e essa é (RFC 1034 §4.2.1, RFC 2181 §6.1). As duas devem ser exatamente iguais.

O valor é sempre um nome de host, nunca um endereço e nunca um apelido: o nome precisa ter registros A ou AAAA próprios (RFC 2181 §10.3).

Um registro NS, parte por partegoogle.com · gravado em 2026-10-23
google.com.Dono345600TTLINClasseNSTipons1.google.com.Valor
DonoA zona a que o registro pertence.
TTL · 4 diasPor quanto tempo um resolvedor pode guardá-lo. A cópia do .com diz 2 dias.
NSTipo de registro 2: um servidor de nomes desta zona.
ValorUm nome de host com registros A ou AAAA próprios.
A cópia da zona pai · .comgoogle.com. 172800 NS ns1.google.com.ns1.google.com. 172800 A 216.239.32.10Não autoritativa: uma referência, com glue
A cópia da própria zonagoogle.com. 345600 NS ns1.google.com.;; flags: qr aaAutoritativa: o que os resolvedores guardam
ns1.google.com.Um nome de host com endereços próprios
216.239.32.10Um endereço não é um valor válido
ns.example.com. → CNAMENunca um apelido (RFC 2181 §10.3)
As duas cópias gravadas ao vivo: a referência do registro do .com vinda de l.gtld-servers.net e a resposta do próprio ns1.google.com.

Como verificar os nameservers de um domínio

Digite o domínio acima e clique em Verificar nameservers: perguntamos ao registro e depois a cada servidor que ele indica e que nosso servidor consegue alcançar. No terminal: dig NS example.com no macOS e no Linux, nslookup -type=ns example.com no Windows, Resolve-DnsName -Name example.com -Type NS no PowerShell.

Esses três perguntam ao seu próprio resolvedor, então mostram uma cópia em cache. Para ver a lista do registro, pergunte ao servidor dele com a recursão desligada: dig @a.gtld-servers.net example.com NS +norec. Para testar um nameserver, peça o SOA a ele com +norec e procure aa nas flags. O whois também mostra a lista do registro, não a da zona.

dig NS example.com +short

A cópia do seu resolvedor, um nameserver por linha. Acrescente @a.gtld-servers.net e +norec para a lista do próprio registro do .com.

Como ler as duas respostas do diggoogle.com · gravado em 2026-10-23
dig · macOS, Linux
$ dig @l.gtld-servers.net google.com NS +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 91
;; AUTHORITY SECTION:
google.com.       172800  IN  NS  ns2.google.com.2
google.com.       172800  IN  NS  ns1.google.com.
…
;; ADDITIONAL SECTION:
ns1.google.com.   172800  IN  A   216.239.32.103
…

$ dig @216.239.32.10 google.com NS +norec
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 04
google.com.       345600  IN  NS  ns1.google.com.5
…
  1. Sem aa: uma referência. O registro não atende google.com; ele diz para onde ir.
  2. A lista da zona pai e o TTL dela: 2 dias, definido pelo registro do .com.
  3. Glue: ns1.google.com está dentro de google.com, então o .com entrega o endereço dele.
  4. aa: a própria zona. Uma resposta autoritativa do servidor.
  5. O TTL da própria zona: 4 dias, definido por Google, não pelo registro.
nslookup · perguntando ao 8.8.8.8
$ nslookup -type=ns google.com 8.8.8.8
Server:   8.8.8.8
Address:  8.8.8.8#53

Non-authoritative answer:
google.com  nameserver = ns3.google.com.
google.com  nameserver = ns1.google.com.
…
PowerShell
# a cópia do seu resolvedor
PS> Resolve-DnsName -Name google.com -Type NS

# um servidor, recursão desligada
PS> Resolve-DnsName -Name google.com -Type SOA -Server ns1.google.com -NoRecursion
whois
$ whois google.com
Registrar: MarkMonitor Inc.
Name Server: NS1.GOOGLE.COM
…
DNSSEC: unsigned
Gravado em 2026-10-23. "Non-authoritative answer" significa a cópia em cache de um resolvedor, aqui o Google Public DNS, que guarda registros NS por no máximo 6 horas. O whois mostra a lista do registro. Nenhum dos dois mostra o que cada servidor diz.

Como ler o resultado

O veredito nomeia o provedor de DNS e o registrador; a visualização Delegação põe a lista do registro ao lado da lista da zona, servidor por servidor, com a resposta de cada um e o tempo por TCP (a abertura da conexão incluída, ou seja, cerca de duas idas e vindas).

A coluna azul-marinho é o caminho que um resolvedor percorre: a raiz, o registro com o TTL e o DS, e depois cada servidor de nomes. Um servidor que não atende a zona aparece interrompido.

Consulta NS de github.com: oito nameservers na NS1 e na Route 53, a resposta de cada servidor e a delegação a partir do .comConsulta NS de github.com: oito nameservers na NS1 e na Route 53, a resposta de cada servidor e a delegação a partir do .comO vereditoQuem atende a zona, quem a registrou e se o registro e a zona concordam.O registro ao lado da zonaCada nome da lista do registro e da lista da própria zona, com glue e a resposta.A resposta de cada servidorAA e o tempo por TCP, o código que um servidor recusando enviou, ou via 1.1.1.1 onde nosso servidor não consegue se conectar.A delegaçãoRaiz, registro e depois a resposta de cada servidor, como um resolvedor percorre.
Uma consulta NS de github.com: o veredito, os oito nameservers do registro ao lado da lista da própria zona, a resposta de cada servidor e a delegação a partir do registro do .com. Selecione um número para ver o que cada parte mostra.

Nameservers da zona pai e da zona filha: por que diferem

Duas partes diferentes mantêm as duas listas. O registro publica a lista da zona pai quando o seu registrador manda; o seu provedor de DNS atende a lista da própria zona. Mude uma sem a outra e elas se afastam.

Os resolvedores confiam mais na resposta da própria zona do que na referência (RFC 2181 §5.4.1), então, depois de perguntar à zona, guardam a lista e o TTL dela. Em 2026-10-23, o resolvedor da Cloudflare guardava o conjunto NS de google.com com 340.859 s restantes: mais que os 172.800 do .com, então a cópia veio do TTL de 4 dias da zona.

Um nome só na lista do registro ainda recebe tráfego dos resolvedores que começam do zero. Um nome só na zona é invisível para eles. Os dois casos merecem correção; nenhum é uma queda por si só.

A lista do registro ao lado da lista da zonagravado em 2026-10-23
xserver.ne.jp5 vs 3

Registro .jp1 dia

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp
  • ns4.xserver.jpsó no registro
  • ns5.xserver.jpsó no registro

Zona1 h

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp

ns4.xserver.jp e ns5.xserver.jp estão só no registro. Os dois respondem com autoridade, então nada quebra; as listas ainda diferem.

github.comos mesmos 8

Registro .com2 dias

  • dns1.p08.nsone.net
  • dns2.p08.nsone.net
  • dns3.p08.nsone.net
  • dns4.p08.nsone.net
  • ns-1283.awsdns-32.org
  • ns-1707.awsdns-21.co.uk
  • ns-421.awsdns-52.com
  • ns-520.awsdns-01.net

Zona15 min · 1 h

  • dns1.p08.nsone.net
  • dns2.p08.nsone.net
  • dns3.p08.nsone.net
  • dns4.p08.nsone.net
  • ns-1283.awsdns-32.org
  • ns-1707.awsdns-21.co.uk
  • ns-421.awsdns-52.com
  • ns-520.awsdns-01.net

Mesmos nomes, relógios diferentes: a cópia do registro dura 2 dias, a da Route 53 15 minutos, a da NS1 1 hora.

Um domínio .net(nome omitido)nenhum nome em comum

Registro .net2 dias

  • ns1.domaindirect.comsó no registro
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.comsó no registro

Zona15 min

  • ns1.hover.comsó na zona
  • ns2.hover.comsó na zona

O registro ainda lista os nomes antigos. Dois deles compartilham endereços com os servidores da Hover e respondem; o terceiro recusa.

As linhas ligam os nomes que as duas listas compartilham; uma linha tracejada liga dois nomes num mesmo endereço. O terceiro caso é um registro real achado numa varredura aleatória; o nome dele foi omitido.

O que são registros glue?

Glue é um endereço que a zona pai entrega junto com a referência, para que um resolvedor alcance um servidor de nomes cujo nome está dentro da zona que ele atende. Sem ele, achar ns1.google.com exigiria perguntar aos servidores de google.com, que é justamente a pergunta de que você partiu (RFC 1034 §4.2.1).

A RFC 9471 torna isso uma regra: uma referência DEVE trazer o glue de todo servidor dentro do domínio (ns1.google.com para google.com) e DEVERIA trazê-lo para servidores irmãos sob a mesma zona pai (ns-421.awsdns-52.com para github.com). Um nome sem relação, como ns-520.awsdns-01.net, é consultado por conta própria.

O glue é definido no registrador, como registros de host, nameservers filhos ou servidores DNS pessoais. Quando um servidor muda, o glue precisa mudar junto: um glue desatualizado manda os resolvedores para um endereço que não responde mais.

Glue, e quando ele é necessáriogravado no .com, 2026-10-23

Dentro do domínio · google.com

  1. .com: pergunte a ns1.google.com
  2. O endereço dele fica no próprio google.com
  3. sem glue, a consulta entra em loop
  4. Então o .com acrescenta ns1.google.com A 216.239.32.10 · DEVE: obrigatório

Irmão e sem relação · github.com

  1. .com: pergunte a ns-421.awsdns-52.com, ns-520.awsdns-01.net, …
  2. awsdns-52.com também está sob .com: glue 205.251.193.165 · DEVERIA: incluído
  3. awsdns-01.net está em outro lugar: o resolvedor o consulta no .net · sem glue
Glue desatualizado · ao vivo64.69.208.141glue do .com para ns1.register.com · sem resposta, perguntado duas vezes162.214.41.25o registro A dele hoje · responde com autoridade
O objeto de host de ns1.register.com no .com, lido por rdap.verisign.com em 2026-10-23: o registro ainda guarda um endereço que o servidor deixou e o entrega como glue.

O que é uma delegação lame e como corrigir

Uma delegação é lame quando a zona pai manda os resolvedores para um servidor que não atende a zona: ele recusa, não diz nada ou responde sem autoridade. Se todos os servidores listados forem lame, o domínio deixa de resolver; se for só um de vários, as consultas ficam mais lentas enquanto os resolvedores tentam de novo.

A RFC 9499 observa que "delegação lame" passou a cobrir várias falhas, então a ferramenta nomeia cada uma: recusa a zona (REFUSED), sem resposta (perguntado duas vezes), responde sem autoridade (sem aa), erro do servidor (SERVFAIL). Silêncio só por TCP não é chamado de lame enquanto o Google e a Cloudflare ainda resolvem o domínio: ele recebe o nome sem resposta TCP, pois esse servidor pode responder por UDP.

A correção está sempre em um de dois lados: adicionar a zona no provedor de DNS para o qual o registro aponta, ou apontar o registro para o provedor que tem a zona. Os resolvedores podem lembrar da falha por até 5 minutos depois da correção (RFC 9520).

Três servidores lame, gravados2026-10-23 · domínios omitidos

Recusa a zona

ns63 · ns64.domaincontrol.com

Os dois servidores da GoDaddy indicados pelo .com respondem REFUSED: a zona não está configurada lá.

bash
$ dig @ns63.domaincontrol.com \
    example.com SOA +norec
;; … status: REFUSED
;; flags: qr; … ANSWER: 0

Um timeout e depois REFUSED

ns1 · ns2.eftydns.com

Um servidor deu timeout uma vez e depois respondeu REFUSED quando perguntamos de novo. Um timeout não é um veredito: a ferramenta pergunta de novo antes de dar um nome ao estado.

bash
$ dig @ns1.eftydns.com \
    example.com SOA +norec
;; connection timed out
# perguntado de novo
;; … status: REFUSED

Um de três

ns1 · ns2 · ns3.domaindirect.com

Dois servidores respondem com autoridade; o terceiro recusa. O domínio funciona, mais devagar.

bash
$ dig @ns2.domaindirect.com \
    example.net SOA +norec
;; … status: REFUSED
# ns1, ns3: NOERROR, flags qr aa
  1. Veja para onde o registro apontaA visualização Delegação lista os servidores do registro e a resposta de cada um.
  2. Corrija um dos ladosAdicione a zona nesse provedor ou troque os nameservers no registrador.
  3. Verifique de novoAs respostas voltam na hora; uma falha em cache dura até 5 minutos.

O que os visitantes recebem quando todos os servidores são lame:Google SERVFAILCloudflare SERVFAIL

Gravado a partir de registros achados numa varredura aleatória; os nomes foram omitidos e aparecem como example.com e example.net.

Quantos nameservers você precisa?

Pelo menos dois: "A especificação do DNS e as regras de registro de nomes de domínio exigem pelo menos dois servidores para cada zona" (RFC 2182 §5, BCP 16). A mesma seção recomenda três para a maioria das organizações, com um bem afastado dos outros, e quatro ou cinco onde a confiabilidade pesa mais.

Conte redes, não nomes. Os servidores devem ficar onde uma falha não os alcance todos (RFC 2182 §3.1): seis servidores num único /22 compartilham o mesmo destino de roteamento. O anycast espalha um endereço por muitos locais e é a resposta usual, mas ainda é um único operador; um segundo provedor sobrevive à queda desse operador (RFC 8901).

Mais é permitido. O limite antigo de sete da RFC 1912 vinha das respostas UDP de 512 bytes; zonas grandes usam oito hoje (github.com, bbc.co.uk).

Servidores, agrupados por redegravado em 2026-10-23
DomínioServidores por redeNSRedesLeitura
google.comGoogle · AS15169 · anycast41Anycast, um operador
github.comNS1 · AS62597Route 53 · AS16509 · anycast82Dois provedores
bbc.co.ukNetActuate · AS63911NS1 · AS6259782Duas redes
xserver.ne.jpXserver · AS131965Amazon · AS1650952Duas redes
craigslist.orgcraigslist · AS2241461Um /22

"Recomenda-se que sejam fornecidos três servidores para a maioria das zonas em nível de organização, com pelo menos um que deve estar bem afastado dos outros."

RFC 2182 §5 · BCP 16, julho de 1997 · dois obrigatórios, três recomendados
Uma caixa é uma rede (AS); uma caixa colorida é um provedor anycast: muitos locais, um operador. A segunda rede de xserver.ne.jp é ns2.xserver.jp, na rede da Amazon; os seis servidores de craigslist.org compartilham um /22.

Como trocar os nameservers e quanto tempo leva

Troque-os onde o domínio está registrado, não no provedor de DNS: o registrador envia a nova lista ao registro, e o registro a publica. Adicione antes a zona no novo provedor, com todos os registros, para que os novos servidores respondam assim que forem nomeados.

Depois correm dois relógios. Os resolvedores que guardaram a referência do registro mantêm a lista antiga por até o TTL da zona pai: 2 dias no .com, 1 dia no .de e no .jp, 1 hora no .org. Os resolvedores que já perguntaram à zona mantêm o conjunto NS da zona antiga pelo TTL dela, que pode ser maior: o de google.com é de 4 dias. O Google Public DNS guarda NS por no máximo 6 horas.

Então nunca são "24–48 horas" fixas. Mantenha o provedor de DNS antigo respondendo os mesmos registros até o relógio mais longo acabar e, num domínio assinado, remova o DS antes da mudança (RFC 6781).

Onde trocar e os relógiosTTLs medidos em 2026-10-23

No registrador: o guia de cada um

Quanto tempo dura a cópia do registro (TTL do NS da zona pai)

  • .ru4 dias345.600 s
  • .com2 dias172.800 s
  • .uk2 dias172.800 s
  • .de1 dia86.400 s
  • .jp1 dia86.400 s
  • .tr12 horas43.200 s
  • .dev3 horas10.800 s
  • .org1 hora3.600 s
  • .io1 hora3.600 s
  • .br1 hora3.600 s
  • .in15 minutos900 s

Os relógios depois de uma troca

  • Referência antiga nas cacheso TTL da zona pai.com: até 2 dias
  • Conjunto NS antigo da zona nas cacheso TTL da zona antigagoogle.com: até 4 dias
  • Google Public DNSo limite dele para NSno máximo 6 horas
TTLs da zona pai tirados dos servidores de cada registro (dig +norec); o .io respondeu 3.600 s, não os 300 s muitas vezes citados. Os registradores ainda citam tempos fixos: a GoDaddy "up to 48 hours", a Namecheap "up to 24 hours".

Registros NS, SOA e glue: qual a diferença?

Três registros se encontram numa delegação. O NS nomeia os servidores: a cópia da zona pai indica o caminho, a cópia da zona é a autoridade. O glue é um registro A ou AAAA que a zona pai guarda só para servidores nomeados dentro da zona. O SOA existe uma vez por zona, no topo dela: o servidor primário, um endereço de contato, o serial e os temporizadores.

Um servidor que responde o SOA com a flag aa tem a zona, e é por isso que a ferramenta o pede a todos os servidores. O serial diz se os servidores têm a mesma versão; a Route 53 começa em 1 e nunca o muda sozinha, e uma zona em dois provedores tem dois seriais, ambos normais.

Duas zonas, um ponto de cortegoogle.com · gravado em 2026-10-23

A zona .comoperada por Verisign

  • NSgoogle.com. 172800 NS ns1.google.com.Delegação: para onde ir em seguida · não autoritativa
  • Ans1.google.com. 172800 A 216.239.32.10Glue: o endereço do servidor, para que ele possa ser alcançado
  • DSsem DS: google.com não é assinadoDS: aponta para a chave de assinatura da zona filha; só em zonas assinadas (cloudflare.com DS 2371 13 2)

ponto de corte · google.com

A zona google.comoperada por Google

  • NSgoogle.com. 345600 NS ns1.google.com.A lista da própria zona · autoritativa
  • SOAns1.google.com. dns-admin.google.com. 1003797344 900 900 1800 60Um por zona: primário, contato, serial, temporizadores
  • Ans1.google.com. 345600 A 216.239.32.10O endereço do próprio servidor: o glue deve coincidir com ele
O glue e o registro A do próprio servidor são duas cópias de um mesmo fato; quando discordam, o glue está desatualizado.

Consulta NS vs o comando nslookup

As pessoas pesquisam "ns lookup" por duas coisas: os nameservers de um domínio e o comando nslookup que vem no Windows, no macOS e no Linux. O nslookup pergunta ao seu resolvedor e mostra o que ele tem em cache; com -type=ns, lista o conjunto NS da zona como o seu resolvedor o guarda.

Essa cópia pode ter horas, e nunca mostra a lista do registro, o glue nem se cada servidor tem a zona. Esta página pergunta diretamente a cada um que consegue alcançar.

Três formas de consultar nameservers
Esta consulta NSdnsrobot.netnslookup-type=nsdigNS · +norec
Pergunta ao registro e depois todos os servidoreso seu resolvedorqualquer servidor que você indicar
Registro vs zonaos dois, nome a nomea cópia em cacheuma lista por comando
O aa de cada servidorcada endereço IPv4 (A e glue)Nãoum servidor por comando
Glue e TTLsos dois TTLscom -debugna saída
Diagnósticonomeado, com a correçãoNãoNão
Roda emqualquer navegadorWindowsmacOSLinuxmacOSLinux

Consulta NS: perguntas frequentes

O que é uma consulta NS e como consultar NS de um domínio?

Uma consulta NS pergunta ao DNS quais nameservers guardam a zona de um domínio. Esta ferramenta pergunta primeiro ao registro, pela lista da zona pai com glue e TTL, e depois diretamente, por TCP, aos endereços IPv4 de cada nameserver, pelo SOA da zona e pelo conjunto NS dela, e compara as duas. Você vê quem hospeda o DNS, quais servidores respondem com autoridade e o que faria os resolvedores falharem ou ficarem lentos.

Como descobrir qual é o meu provedor de DNS?

Olhe os nomes dos nameservers: ns1.google.com é o Google, *.ns.cloudflare.com é a Cloudflare, ns-*.awsdns-* é a Amazon Route 53, 01.dnsv.jp é o Onamae.com. Esta consulta nomeia o provedor de DNS pelo padrão de nome documentado de cada um e mostra à parte a rede por trás de cada endereço, porque alguns provedores rodam na rede de outra empresa: Porkbun e Hostinger na da Cloudflare, Vercel na da NS1.

Por que o registro e a zona listam nameservers diferentes?

A lista do registro, definida no seu registrador, e os registros NS da própria zona, definidos no seu provedor de DNS, são duas cópias separadas, e a RFC 1034 diz que devem ser exatamente iguais. Elas se afastam quando alguém muda uma e não a outra, muitas vezes depois de uma migração entre provedores de DNS. Os resolvedores que começam pelo registro usam a lista dele, enquanto os que perguntaram à zona guardam a dela.

O que é uma delegação lame?

Uma delegação lame é um nameserver que o registro lista, mas que não atende a zona: ele responde REFUSED ou SERVFAIL, responde sem autoridade ou não responde. Se todos os servidores listados forem lame, o domínio deixa de resolver e o Google e a Cloudflare respondem SERVFAIL. Corrija adicionando a zona nesse provedor de DNS ou trocando os nameservers no registrador pelos do provedor que tem a zona.

Quanto tempo a troca de nameservers leva para propagar?

Até o maior de dois relógios: o TTL do NS no registro (2 dias para .com e .net, 4 dias para .ru, 1 dia para .de e .jp, 1 hora para .org e .io, 15 minutos para .in) e o TTL do NS da própria zona antiga, que os resolvedores que já perguntaram ao provedor antigo guardam. O Google Public DNS limita isso a cerca de 6 horas. Um "24–48 horas" fixo está errado nos dois sentidos.

Quantos nameservers um domínio deve ter?

Pelo menos dois: a RFC 2182 exige dois, recomenda três para a maioria das organizações, com ao menos um bem afastado dos outros, e quatro ou cinco para mais confiabilidade. Mais importante que o número é que uma falha não alcance todos: redes ou provedores diferentes. Servidores anycast de um único operador, como Cloudflare ou Route 53, são muitos locais, mas ainda um só operador.

O que são registros glue e quando preciso deles?

Glue é o endereço que o registro entrega junto com a referência para um nameserver nomeado dentro da zona, como ns1.example.com para example.com: sem ele, um resolvedor precisaria do endereço do servidor para achar o servidor. A RFC 9471 torna o glue obrigatório para esses nomes dentro do domínio. Defina-o no seu registrador, onde se chama registros de host, nameservers filhos ou servidores DNS pessoais.

Por que ferramentas diferentes mostram nameservers diferentes?

A maioria dos verificadores de nameservers pergunta a um resolvedor, que mostra uma cópia em cache que pode ter dias depois de uma troca, enquanto o registro e a zona respondem por si. Algumas ferramentas mostram só a lista da própria zona. Esta consulta mostra a lista do registro, a resposta de cada servidor e as cópias em cache do Google e da Cloudflare lado a lado, com o tempo que cada cópia ainda tem.

O que significa "não consultado diretamente"?

Nosso servidor roda na rede da Cloudflare, e um Cloudflare Worker não consegue abrir conexão com um endereço dessa rede. Os nameservers lá, os da própria Cloudflare e os de provedores que rodam nela, como Porkbun, Hostinger e DigitalOcean, são lidos pelo resolvedor 1.1.1.1 da Cloudflare: o conjunto NS e o TTL dele, mas não o bit AA, o serial nem o tempo de cada servidor.

Consulta NS é a mesma coisa que nslookup?

Não. O nslookup é uma ferramenta de linha de comando do Windows, do macOS e do Linux que pergunta a um resolvedor qualquer tipo de registro, NS inclusive (nslookup -type=ns example.com). Uma consulta NS é a própria pergunta: quais nameservers atendem um domínio. Como o dig NS, o nslookup mostra a cópia em cache do seu resolvedor; perguntar ao registro e a cada servidor diretamente, como esta ferramenta faz, mostra se eles concordam.

Por que a troca dos meus nameservers ainda não aparece?

Confira três lugares: se o registro lista os novos servidores (se não, a troca ainda não saiu do seu registrador), se a nova zona responde com autoridade e quanto tempo as cópias antigas duram nos resolvedores. O modo "Troquei os nameservers" recebe os seus novos servidores, compara cada cópia com eles e faz a contagem regressiva até todos os resolvedores os terem.

Devo remover o DNSSEC antes de trocar os nameservers?

Sim, a menos que os provedores de DNS antigo e novo cooperem. Se o registro mantiver um DS com o qual as chaves do novo provedor não coincidem, resolvedores que validam, como o Google e a Cloudflare, respondem SERVFAIL e o domínio fica fora do ar para os usuários deles. Remova o DS no registrador, espere o TTL dele passar, troque os nameservers e publique o DS do novo provedor.

Sentiu falta de algo?Sugira um recurso ou uma nova ferramenta

Ferramentas de DNS relacionadas