Herramientas populares

Tema

Consulta NS — Buscar Servidores de Nombres

Consulta NS de cualquier dominio: los registros NS que entrega su registro, con glue y TTL, junto a lo que dice cada servidor de nombres por sí mismo. Para consultar NS y detectar servidores defectuosos, diferencias y glue obsoleto, se indica la solución.

Fuentes: los servidores del registro, alcanzados desde un servidor raíz · las direcciones IPv4 de cada servidor de nombres, consultadas directamente · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · RDAP

Consulta primero el registro de dominios y luego cada servidor de nombres que este indica. Sirve una URL, una dirección de correo o un subdominio.

Pruebe

¿Qué es un registro NS?

Un registro NS nombra un servidor que contiene una zona: el lugar donde viven los registros de un dominio. Una zona lista un registro NS por servidor, así que google.com tiene cuatro, de ns1 a ns4.google.com (RFC 1035 §3.3.11).

Los mismos registros NS existen dos veces. La zona superior, aquí .com, guarda una copia en el punto de corte para poder remitir a los resolutores; esa copia no es autoritativa. La zona guarda su propia copia en su nivel más alto, y esa sí lo es (RFC 1034 §4.2.1, RFC 2181 §6.1). Las dos deberían ser exactamente iguales.

El valor siempre es un nombre de host, nunca una dirección ni un alias: el nombre debe tener sus propios registros A o AAAA (RFC 2181 §10.3).

Un registro NS, parte por partegoogle.com · registrado el 2026-10-23
google.com.Propietario345600TTLINClaseNSTipons1.google.com.Valor
PropietarioLa zona a la que pertenece el registro.
TTL · 4 díasCuánto tiempo puede conservarlo un resolutor. La copia de .com dice 2 días.
NSTipo de registro 2: un servidor de nombres de esta zona.
ValorUn nombre de host con sus propios registros A o AAAA.
La copia de la zona superior · .comgoogle.com. 172800 NS ns1.google.com.ns1.google.com. 172800 A 216.239.32.10No autoritativa: una referencia, con glue
La copia propia de la zonagoogle.com. 345600 NS ns1.google.com.;; flags: qr aaAutoritativa: la que conservan los resolutores
ns1.google.com.Un nombre de host con sus propias direcciones
216.239.32.10Una dirección no es un valor válido
ns.example.com. → CNAMENunca un alias (RFC 2181 §10.3)
Ambas copias registradas en vivo: la referencia del registro .com desde l.gtld-servers.net y la respuesta propia de ns1.google.com.

Cómo hacer una consulta NS de un dominio

Para consultar NS, escriba el dominio arriba y pulse Consultar NS: preguntamos al registro y luego a cada servidor que este indica y que nuestro servidor puede alcanzar. Desde una terminal: dig NS example.com en macOS y Linux, nslookup -type=ns example.com en Windows, Resolve-DnsName -Name example.com -Type NS en PowerShell.

Esos tres consultan a su propio resolutor, así que muestran una copia en caché. Para ver la lista del registro, pregunte a su servidor con la recursión desactivada: dig @a.gtld-servers.net example.com NS +norec. Para probar un servidor de nombres, pídale el SOA con +norec y busque aa en las banderas. whois también muestra la lista del registro, no la de la zona.

dig NS example.com +short

La copia de su resolutor, un servidor de nombres por línea. Agregue @a.gtld-servers.net y +norec para ver la lista propia del registro .com.

Cómo leer las dos respuestas de diggoogle.com · registrado el 2026-10-23
dig · macOS y 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. Sin aa: una referencia. El registro no sirve google.com; indica adónde ir.
  2. La lista de la zona superior y su TTL: 2 días, fijado por el registro .com.
  3. Glue: ns1.google.com está dentro de google.com, así que .com entrega su dirección.
  4. aa: la zona misma. Una respuesta autoritativa del servidor.
  5. El TTL propio de la zona: 4 días, fijado por Google, no por el registro.
nslookup · consultando 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
# la copia de su resolutor
PS> Resolve-DnsName -Name google.com -Type NS

# un servidor, sin recursión
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
Registrado el 2026-10-23. "Non-authoritative answer" significa una copia en caché de un resolutor, aquí la de Google Public DNS, que guarda los registros NS como máximo 6 horas. whois imprime la lista del registro. Ninguno muestra lo que dice cada servidor.

Cómo leer el resultado

El veredicto nombra al proveedor de DNS y al registrador; la vista Delegación pone la lista del registro junto a la de la zona, servidor por servidor, con la respuesta de cada uno y su tiempo por TCP (con la conexión incluida, es decir, unas dos idas y vueltas).

La columna azul marino es el camino que sigue un resolutor: la raíz, el registro con su TTL y su DS, y luego cada servidor de nombres. Un servidor que no sirve la zona aparece interrumpido.

Consulta NS de github.com: ocho servidores de nombres en NS1 y Route 53, la respuesta de cada uno y la delegación de .comConsulta NS de github.com: ocho servidores de nombres en NS1 y Route 53, la respuesta de cada uno y la delegación de .comEl veredictoQuién sirve la zona, quién la registró y si el registro y la zona coinciden.El registro junto a la zonaCada nombre de la lista del registro y de la propia de la zona, con glue y la respuesta.La respuesta de cada servidorAA y su tiempo por TCP, el código que envió un servidor que rechaza, o mediante 1.1.1.1 donde nuestro servidor no puede conectarse.La delegaciónRaíz, registro y luego la respuesta propia de cada servidor, tal como la recorre un resolutor.
Una consulta NS de github.com: el veredicto, los ocho servidores de nombres del registro junto a la lista propia de la zona, la respuesta de cada servidor y la delegación desde el registro .com. Seleccione un número para ver qué muestra cada parte.

Servidores de nombres de la zona superior y de la zona: por qué difieren

Dos partes distintas guardan las dos listas. El registro publica la de la zona superior cuando su registrador se lo indica; su proveedor de DNS sirve la lista propia de la zona. Si cambia una sin la otra, se separan.

Los resolutores confían más en la respuesta propia de la zona que en la referencia (RFC 2181 §5.4.1), así que una vez que consultan la zona conservan su lista y su TTL. El 2026-10-23 el resolutor de Cloudflare tenía el conjunto NS de google.com con 340.859 s restantes: más que los 172.800 de .com, así que la copia venía del TTL de 4 días de la zona.

Un nombre que está solo en la lista del registro sigue recibiendo tráfico de los resolutores que empiezan desde cero. Un nombre que está solo en la zona les resulta invisible. Conviene corregir ambos casos; ninguno es una caída por sí solo.

La lista del registro junto a la de la zonaregistrado el 2026-10-23
xserver.ne.jp5 frente a 3

Registro .jp1 d

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp
  • ns4.xserver.jpsolo en el registro
  • ns5.xserver.jpsolo en el registro

Zona1 h

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

ns4.xserver.jp y ns5.xserver.jp están solo en el registro. Ambos responden con autoridad, así que nada falla; aun así las listas difieren.

github.comlos mismos 8

Registro .com2 d

  • 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

Los mismos nombres, relojes distintos: la copia del registro dura 2 días, la de Route 53 15 minutos, la de NS1 1 hora.

Un dominio .net(nombre omitido)ningún nombre en común

Registro .net2 d

  • ns1.domaindirect.comsolo en el registro
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.comsolo en el registro

Zona15 min

  • ns1.hover.comsolo en la zona
  • ns2.hover.comsolo en la zona

El registro aún lista los nombres anteriores. Dos de ellos comparten direcciones con los servidores de Hover y responden; el tercero rechaza.

Las líneas unen los nombres que ambas listas comparten; una línea discontinua une dos nombres con una misma dirección. El tercer caso es un registro real hallado en un escaneo aleatorio; su nombre se omite.

¿Qué son los registros glue?

El glue es una dirección que la zona superior entrega con su referencia, para que un resolutor pueda llegar a un servidor de nombres cuyo nombre está dentro de la zona que sirve. Sin él, encontrar ns1.google.com exigiría preguntar a los servidores de google.com, que es justo la pregunta con la que empezó (RFC 1034 §4.2.1).

La RFC 9471 lo convierte en regla: una referencia DEBE incluir el glue de todo servidor dentro del dominio (ns1.google.com para google.com) y DEBERÍA incluirlo para los servidores hermanos bajo la misma zona superior (ns-421.awsdns-52.com para github.com). Un nombre sin relación, como ns-520.awsdns-01.net, se busca por separado.

El glue se configura en el registrador, como registros de host, servidores de nombres hijos o servidores DNS personales. Cuando un servidor cambia de lugar, el glue debe cambiar con él: el glue obsoleto envía a los resolutores a una dirección que ya no responde.

El glue y cuándo hace faltaregistrado en .com, 2026-10-23

Dentro del dominio · google.com

  1. .com: consulte ns1.google.com
  2. Su dirección vive en google.com mismo
  3. sin glue, la consulta entra en un bucle
  4. Por eso .com agrega ns1.google.com A 216.239.32.10 · DEBE: obligatorio

Hermano y sin relación · github.com

  1. .com: consulte ns-421.awsdns-52.com, ns-520.awsdns-01.net, …
  2. awsdns-52.com también está bajo .com: glue 205.251.193.165 · DEBERÍA: incluido
  3. awsdns-01.net está en otra parte: el resolutor lo busca en .net · sin glue
Glue obsoleto · en vivo64.69.208.141El glue de .com para ns1.register.com · sin respuesta, consultado dos veces162.214.41.25su registro A hoy · responde con autoridad
El objeto de host de ns1.register.com en .com, leído mediante rdap.verisign.com el 2026-10-23: el registro aún conserva una dirección que el servidor abandonó y la entrega como glue.

Qué es una delegación defectuosa (lame) y cómo corregirla

Una delegación es defectuosa cuando la zona superior envía a los resolutores a un servidor que no sirve la zona: rechaza la consulta, no dice nada o responde sin autoridad. Si todos los servidores listados son defectuosos, el dominio deja de resolverse; si lo es uno de varios, las consultas se vuelven más lentas mientras los resolutores reintentan.

La RFC 9499 señala que "lame delegation" pasó a abarcar varios fallos, así que la herramienta nombra cada uno: rechaza la zona (REFUSED), sin respuesta (consultado dos veces), responde sin autoridad (sin aa), error del servidor (SERVFAIL). El silencio solo por TCP no se llama defectuoso mientras Google y Cloudflare sigan resolviendo el dominio: se nombra sin respuesta TCP, porque ese servidor puede responder por UDP.

La solución siempre está de uno de los dos lados: agregar la zona en el proveedor de DNS al que apunta el registro, o apuntar el registro al proveedor que tiene la zona. Los resolutores pueden recordar el fallo hasta 5 minutos después de la corrección (RFC 9520).

Tres servidores defectuosos, registrados2026-10-23 · dominios omitidos

Rechaza la zona

ns63 · ns64.domaincontrol.com

Los dos servidores de GoDaddy que nombra .com responden REFUSED: la zona no está configurada allí.

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

Un tiempo agotado y luego REFUSED

ns1 · ns2.eftydns.com

Un servidor agotó el tiempo una vez y luego respondió REFUSED al consultarlo de nuevo. Un solo tiempo agotado no es un veredicto: la herramienta vuelve a preguntar antes de nombrar un estado.

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

Uno de tres

ns1 · ns2 · ns3.domaindirect.com

Dos servidores responden con autoridad; el tercero rechaza. El dominio funciona, más lentamente.

bash
$ dig @ns2.domaindirect.com \
    example.net SOA +norec
;; … status: REFUSED
# ns1, ns3: NOERROR, flags qr aa
  1. Vea adónde apunta el registroLa vista Delegación lista los servidores del registro y la respuesta de cada uno.
  2. Corrija uno de los ladosAgregue la zona en ese proveedor, o cambie los servidores de nombres en el registrador.
  3. Vuelva a comprobarLas respuestas regresan al instante; un fallo en caché dura hasta 5 minutos.

Lo que obtienen los visitantes cuando todos los servidores son defectuosos:Google SERVFAILCloudflare SERVFAIL

Registrado a partir de dominios hallados en un escaneo aleatorio; sus nombres se omiten y se muestran como example.com y example.net.

¿Cuántos nameservers (servidores de nombres) se necesitan?

Al menos dos: "The DNS specification and domain name registration rules require at least two servers for every zone" (RFC 2182 §5, BCP 16). La misma sección recomienda tres para la mayoría de las organizaciones, con uno bien alejado de los demás, y cuatro o cinco donde la fiabilidad importe más.

Cuente redes, no nombres. Los servidores deben estar donde un solo fallo no pueda alcanzarlos a todos (RFC 2182 §3.1): seis servidores en un mismo /22 comparten un mismo destino de enrutamiento. Anycast reparte una dirección entre muchos sitios y es la respuesta habitual, pero sigue siendo un solo operador; un segundo proveedor sobrevive a la caída de ese operador (RFC 8901).

Tener más está bien. El antiguo límite de siete de la RFC 1912 venía de las respuestas UDP de 512 bytes; las zonas grandes hoy usan ocho (github.com, bbc.co.uk).

Servidores agrupados por redregistrado el 2026-10-23
DominioServidores por redNSRedesLectura
google.comGoogle · AS15169 · Anycast41Anycast, un operador
github.comNS1 · AS62597Route 53 · AS16509 · Anycast82Dos proveedores
bbc.co.ukNetActuate · AS63911NS1 · AS6259782Dos redes
xserver.ne.jpXserver · AS131965Amazon · AS1650952Dos redes
craigslist.orgcraigslist · AS2241461Un /22

"Se recomienda proporcionar tres servidores para la mayoría de las zonas de nivel organizacional, con al menos uno que debe estar bien alejado de los demás."

RFC 2182 §5 · BCP 16, julio de 1997 · dos obligatorios, tres recomendados
Una caja es una red (AS); una caja con tinte es un proveedor anycast: muchos sitios, un solo operador. La segunda red de xserver.ne.jp es ns2.xserver.jp en la de Amazon; los seis servidores de craigslist.org comparten un /22.

Cómo cambiar los nameservers y cuánto tarda

Cámbielos donde está registrado el dominio, no en el proveedor de DNS: el registrador envía la nueva lista al registro y el registro la publica. Agregue primero la zona en el nuevo proveedor, con todos los registros, para que los nuevos servidores respondan en cuanto se los nombre.

Luego corren dos relojes. Los resolutores que guardaron la referencia del registro conservan la lista anterior hasta el TTL de la zona superior: 2 días en .com, 1 día en .de y .jp, 1 hora en .org. Los resolutores que ya consultaron la zona conservan el conjunto NS de la zona anterior durante su TTL, que puede ser mayor: el de google.com es de 4 días. Google Public DNS guarda NS 6 horas como máximo.

Por eso nunca son unas "24 a 48 horas" fijas. Mantenga el proveedor de DNS anterior respondiendo los mismos registros hasta que termine el reloj más largo, y en un dominio firmado quite el DS antes del traslado (RFC 6781).

Dónde cambiarlos, y los relojesTTL medidos el 2026-10-23

En el registrador: la guía propia de cada uno

Cuánto dura la copia del registro (TTL de NS de la zona superior)

  • .ru4 días345.600 s
  • .com2 días172.800 s
  • .uk2 días172.800 s
  • .de1 día86.400 s
  • .jp1 día86.400 s
  • .es1 día86.400 s
  • .tr12 horas43.200 s
  • .dev3 horas10.800 s
  • .org1 hora3600 s
  • .io1 hora3600 s
  • .in15 minutos900 s

Los relojes tras un cambio

  • Referencia anterior en cachésel TTL de la zona superior.com: hasta 2 días
  • Conjunto NS anterior de la zona en cachésel TTL de la zona anteriorgoogle.com: hasta 4 días
  • Google Public DNSsu límite para NS6 horas como máximo
TTL de la zona superior tomados de los servidores propios de cada registro (dig +norec); .io respondió 3.600 s, no los 300 s que suelen citarse. Los registradores aún citan tiempos fijos: GoDaddy "up to 48 hours", Namecheap "up to 24 hours".

Registros NS, SOA y glue

Tres registros se encuentran en una delegación. NS nombra los servidores: la copia de la zona superior indica el camino, la copia de la zona es la autoridad. Glue es un registro A o AAAA que la zona superior guarda solo para los servidores nombrados dentro de la zona. SOA existe una vez por zona, en su nivel más alto: el servidor primario, una dirección de contacto, el número de serie y los temporizadores.

Un servidor que responde el SOA con la bandera aa contiene la zona, por eso la herramienta se lo pide a cada servidor. El número de serie indica si los servidores tienen la misma versión; Route 53 empieza en 1 y nunca lo cambia por sí solo, y una zona en dos proveedores lleva dos números de serie, ambos normales.

Dos zonas, un punto de cortegoogle.com · registrado el 2026-10-23

La zona .comoperada por Verisign

  • NSgoogle.com. 172800 NS ns1.google.com.Delegación: adónde ir después · no autoritativa
  • Ans1.google.com. 172800 A 216.239.32.10Glue: la dirección del servidor, para poder llegar a él
  • DSsin DS: google.com no está firmadoDS: apunta a la clave de firma de la zona hija; solo zonas firmadas (cloudflare.com DS 2371 13 2)

punto de corte · google.com

La zona google.comoperada por Google

  • NSgoogle.com. 345600 NS ns1.google.com.La lista propia de la zona · autoritativa
  • SOAns1.google.com. dns-admin.google.com. 1003797344 900 900 1800 60Uno por zona: primario, contacto, número de serie, temporizadores
  • Ans1.google.com. 345600 A 216.239.32.10La dirección propia del servidor: el glue debería coincidir con ella
El glue y el registro A propio del servidor son dos copias de un mismo dato; cuando discrepan, el glue está obsoleto.

Consulta NS frente al comando nslookup

La gente busca "consulta ns" por dos motivos: los servidores de nombres de un dominio, y el comando nslookup que viene con Windows, macOS y Linux. nslookup consulta a su resolutor e imprime lo que este tiene en caché; con -type=ns lista el conjunto NS de la zona tal como lo guarda su resolutor.

Esa copia puede tener horas, y nunca muestra la lista del registro, el glue ni si cada servidor contiene la zona. Esta página pregunta directamente a cada uno de ellos al que puede llegar.

Tres formas de consultar servidores de nombres
Esta consulta NSdnsrobot.netnslookup-type=nsdigNS · +norec
Consulta ael registro y luego cada servidorsu resolutorcualquier servidor que usted nombre
Registro frente a zonaambos, nombre por nombrela copia en cachéuna lista por comando
El aa de cada servidorcada dirección IPv4 (A y glue)Noun servidor por comando
Glue y TTLambos TTLcon -debugen la salida
Diagnósticonombrado, con la soluciónNoNo
Funciona encualquier navegadorWindowsmacOSLinuxmacOSLinux

Consulta NS: preguntas frecuentes

¿Qué es una consulta NS?

Una consulta NS pregunta al DNS qué servidores de nombres contienen la zona de un dominio. Esta herramienta consulta primero al registro, para obtener la lista de la zona superior con su glue y TTL, y luego a las direcciones IPv4 de cada servidor de nombres directamente por TCP, para el SOA de la zona y su propio conjunto NS, y compara ambos. Así ve quién aloja el DNS, qué servidores responden con autoridad y qué haría fallar o ralentizar a los resolutores.

¿Cómo averiguo quién es mi proveedor de DNS?

Mire los nombres de los servidores de nombres: ns1.google.com es Google, *.ns.cloudflare.com es Cloudflare, ns-*.awsdns-* es Amazon Route 53, 01.dnsv.jp es Onamae.com. Esta consulta identifica al proveedor de DNS por el patrón de nombre documentado de cada uno y muestra aparte la red detrás de cada dirección, porque algunos proveedores funcionan en la red de otra empresa: Porkbun y Hostinger en la de Cloudflare, Vercel en la de NS1.

¿Por qué el registro y la zona listan registros NS distintos?

La lista del registro, configurada en su registrador, y los registros NS propios de la zona, configurados en su proveedor de DNS, son dos copias separadas, y la RFC 1034 dice que deberían ser exactamente iguales. Se separan cuando alguien cambia una y no la otra, a menudo tras un traslado entre proveedores de DNS. Los resolutores que parten del registro usan su lista; los que consultaron la zona conservan la de la zona.

¿Qué es una delegación defectuosa?

Una delegación defectuosa es un servidor de nombres que el registro lista pero que no sirve la zona: responde REFUSED o SERVFAIL, responde sin autoridad o no responde en absoluto. Si todos los servidores listados son defectuosos, el dominio deja de resolverse y Google y Cloudflare responden SERVFAIL. Se corrige agregando la zona en ese proveedor de DNS, o cambiando los servidores de nombres en el registrador por el proveedor que tiene la zona.

¿Cuánto tardan en propagarse los cambios de servidores de nombres?

Hasta el mayor de dos relojes: el TTL de NS del registro (2 días para .com y .net, 4 días para .ru, 1 día para .de y .jp, 1 hora para .org e .io, 15 minutos para .in) y el TTL de NS propio de la zona anterior, que conservan los resolutores que ya consultaron al proveedor anterior. Google Public DNS lo limita a unas 6 horas. Unas "24 a 48 horas" fijas es incorrecto en ambos sentidos.

¿Cuántos servidores de nombres debería tener un dominio?

Al menos dos: la RFC 2182 exige dos, recomienda tres para la mayoría de las organizaciones con al menos uno bien alejado de los demás, y cuatro o cinco para mayor fiabilidad. Más importante que el número es que un solo fallo no pueda alcanzarlos a todos: redes o proveedores distintos. Los servidores anycast de un solo operador, como Cloudflare o Route 53, son muchos sitios, pero siguen siendo un solo operador.

¿Qué son los registros glue y cuándo los necesito?

El glue es la dirección que el registro entrega con su referencia para un servidor de nombres nombrado dentro de la zona, como ns1.example.com para example.com: sin él, un resolutor necesitaría la dirección del servidor para encontrar al servidor. La RFC 9471 hace obligatorio el glue para esos nombres dentro del dominio. Se configura en su registrador, donde se llama registros de host, servidores de nombres hijos o servidores DNS personales.

¿Por qué al consultar NS distintas herramientas muestran servidores diferentes?

La mayoría de los verificadores de servidores de nombres preguntan a un resolutor, que muestra una copia en caché que puede tener días tras un cambio, mientras que el registro y la zona responden por sí mismos. Algunas herramientas muestran solo la lista propia de la zona. Esta consulta muestra la lista del registro, la respuesta propia de cada servidor y las copias en caché de Google y Cloudflare lado a lado, con el tiempo que le queda a cada copia.

¿Qué significa "no se probó directamente"?

Nuestro servidor funciona en la red de Cloudflare, y un Cloudflare Worker no puede abrir una conexión a una dirección de esa red. Los servidores de nombres que están allí, los de Cloudflare y los de proveedores que funcionan sobre ella, como Porkbun, Hostinger y DigitalOcean, se leen en cambio mediante el resolutor 1.1.1.1 de Cloudflare: el conjunto NS y su TTL, pero no el bit AA, el número de serie ni el tiempo de respuesta de cada servidor.

¿Una consulta NS es lo mismo que nslookup?

No. nslookup es una herramienta de línea de comandos de Windows, macOS y Linux que pregunta a un resolutor por cualquier tipo de registro, NS incluido (nslookup -type=ns example.com). Una consulta NS es la pregunta misma: qué servidores de nombres sirven un dominio. Igual que dig NS, nslookup muestra la copia en caché de su resolutor; preguntar al registro y a cada servidor directamente, como hace esta herramienta, muestra si coinciden.

¿Por qué todavía no se ve mi cambio de servidores de nombres?

Revise tres lugares: si el registro lista los nuevos servidores (si no, el cambio aún no salió de su registrador), si la nueva zona responde con autoridad y cuánto duran las copias antiguas en los resolutores. El modo "Cambié mis servidores de nombres" toma sus nuevos servidores, compara cada copia con ellos y cuenta regresivamente hasta que todos los resolutores los tengan.

¿Debo quitar DNSSEC antes de cambiar los servidores de nombres?

Sí, a menos que el proveedor de DNS anterior y el nuevo cooperen. Si el registro conserva un DS que no coincide con las claves del nuevo proveedor, los resolutores que validan, como Google y Cloudflare, responden SERVFAIL y el dominio queda inaccesible para sus usuarios. Quite el DS en el registrador, espere a que venza su TTL, cambie los servidores de nombres y publique después el DS del nuevo proveedor.

¿Le falta algo?Sugiera una función o una herramienta nueva

Herramientas de DNS relacionadas