--- id: "name-server" kind: "glossary-term" title: "servidor de nombres" language: "es" category: "DNS y fundamentos técnicos" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/es/glosario/servidor-nombres/" translations: en: "https://tldlog.com/glossary/name-server/" de: "https://tldlog.com/de/glossar/nameserver/" fr: "https://tldlog.com/fr/glossaire/serveur-noms/" it: "https://tldlog.com/it/glossario/name-server/" pt-BR: "https://tldlog.com/pt/glossario/servidor-nomes/" ru: "https://tldlog.com/ru/glossariy/dns-server/" zh-Hans: "https://tldlog.com/zh/cihui/yuming-fuwuqi/" --- # servidor de nombres Servidor que guarda registros DNS y responde a las consultas sobre nombres de dominio. Para que un dominio funcione, el registrador comunica al registro qué servidores de nombres tienen sus registros DNS. Al cambiar los servidores de nombres de un dominio, cambia el lugar donde se encuentran su página web y su correo electrónico. Un servidor de nombres es el ordenador que responde cuando alguien pregunta dónde están la web o el correo de un dominio. Todo dominio debe tener al menos dos, y el registrador los comunica al registro. Si faltan, son incorrectos o están apagados, el dominio deja de funcionar aunque siga registrado. ## Qué hace un servidor de nombres por un dominio Las expresiones «servidor de nombres» y «servidor DNS» abarcan dos funciones. Los servidores autoritativos guardan los registros DNS de un dominio y responden por él; los resolutores preguntan en nombre de los usuarios. La RFC 9499 (marzo de 2024), sobre terminología del DNS, señala que a ambos se les suele llamar así. Aquí se trata de los autoritativos. La zona del TLD, que gestiona el registro, contiene registros NS con los servidores del dominio. Esta delegación indica a los resolutores dónde preguntar. El registrador envía esos nombres al registro mediante EPP. Sin servidores de nombres, el dominio queda en estado inactive y no resuelve. La RFC 1034 (noviembre de 1987) exige que cada zona esté en al menos dos servidores, para que resista la caída de uno. El informe SAC125 del SSAC (9 de mayo de 2024) indica que los registros suelen exigir dos como mínimo al registrar y en cada actualización. ## Registrador, proveedor de DNS y alojamiento: quién gestiona los servidores de nombres Intervienen tres funciones, que puede cubrir una sola empresa o tres: - El registrador anota en el registro qué servidores de nombres usa el dominio. - El proveedor de DNS opera esos servidores y la zona con los registros del dominio. Puede ser el registrador, un proveedor de alojamiento web o un especialista. - Los alojamientos web y de correo prestan los servicios a los que apuntan los registros. Cambiar de proveedor de DNS no cambia el registrador: solo se sustituyen los servidores de nombres declarados. ## Cómo cambiar los servidores de nombres, paso a paso 1. Configurar primero la zona en el nuevo proveedor de DNS, con todos los registros del dominio (web y correo incluidos) y registros NS que coincidan con los nuevos servidores. 2. Si el dominio está firmado con DNSSEC, un registro DS que siga apuntando a las claves antiguas puede hacer que falle en los resolutores que comprueban firmas. Si el operador saliente no colabora, la RFC 6781 describe este orden: pedir que se retire el registro DS, cambiar los servidores, esperar a que el cambio se extienda por el DNS y añadir un DS para la zona firmada de nuevo. El dominio queda sin protección DNSSEC hasta entonces. 3. Comprobar que no hay bloqueos: mientras figure clientUpdateProhibited o serverUpdateProhibited, el registro rechaza los cambios. El registrador retira clientUpdateProhibited; serverUpdateProhibited (bloqueo en el registro) solo puede quitarlo el registro, a través del registrador. 4. Introducir los nuevos servidores en el registrador, que los transmite al registro: al menos dos, a ser posible en redes distintas. 5. Mantener el servicio antiguo un tiempo: los resolutores guardan copias de las respuestas, así que algunos visitantes seguirán llegando a él durante horas o más. No conviene borrar la zona antigua el mismo día. Reglas, bloqueos y plazos dependen del registro y del registrador: conviene consultarlos antes de cambiar un dominio importante. ## Registros de pegado y servidores de nombres dentro del propio dominio Por ejemplo, example.com usa ns1.example.com y ns2.example.com. Para encontrar ns1.example.com, un resolutor tendría que preguntar antes a los servidores de example.com, justo los que busca. La salida es el registro de pegado (o «registro glue»): el registro publica sus direcciones IP junto con la delegación. La RFC 9471 (septiembre de 2023) hace obligatorio este pegado en las respuestas de remisión, y señalaba entonces que el único tipo de pegado definido eran las direcciones (registros A y AAAA). En el registro, cada servidor de nombres es un objeto host. Como ns1.example.com está bajo example.com, el dominio debe existir antes; luego el registrador crea el objeto host con sus direcciones IP y lo vincula al dominio. Las direcciones solo son obligatorias cuando hace falta pegado: si example.com usara ns1.example.net, el registro de .com no necesitaría pegado. ## Servidores primario y secundario, y por qué importa la redundancia El servidor primario guarda la copia de la zona donde se hacen los cambios. Los secundarios la copian mediante transferencia de zona: la completa (AXFR) copia toda la zona y la incremental (IXFR), solo lo que ha cambiado. El protocolo DNS UPDATE (RFC 2136), la parte estándar del DNS dinámico, añade o elimina registros sin editar la zona a mano. Dos servidores son el mínimo, no lo aconsejable: la RFC 2182 (julio de 1997) advierte que una zona con solo dos «en realidad funciona con uno solo» cuando uno falla, y recomienda tres para la mayoría de las organizaciones, con al menos uno bien alejado de los demás, y cuatro o cinco si se necesita más fiabilidad. Los requisitos técnicos de la IANA (revisados por última vez el 14 de noviembre de 2024, a octubre de 2026) solo se aplican a la zona raíz, .INT y .ARPA, pero sirven como lista de comprobación: al menos dos registros NS con direcciones IP distintas, servidores en al menos dos redes topológicamente separadas, respuestas autoritativas y ningún servicio recursivo. ## Qué puede fallar: delegaciones defectuosas y servidores olvidados «Delegación defectuosa» («lame delegation») se usa para varios fallos: un servidor declarado que no responde, que no es accesible o que responde con un error o sin autoridad. La RFC 9499 recomienda expresiones más precisas. Las consultas se vuelven lentas o fallan. Una causa frecuente es el servidor olvidado: si el titular deja un proveedor de DNS sin cambiar los registros NS, el dominio queda delegado en servidores que ya no responden por él, lo que puede facilitar su toma de control. Un riesgo menos visible: según SAC125, la mayoría de los registros se niegan a borrar un dominio caducado mientras otros dominios dependan de él, y la RFC 5731 indica que no debería borrarse hasta que sus objetos host se eliminen o renombren. Algunos registradores los han renombrado dentro de otro dominio. SAC125 los llama servidores de nombres de sacrificio («sacrificial nameservers») y los considera inseguros cuando ese otro dominio puede registrarse: quien lo registre controla la resolución de los dominios que aún los usan. Según el informe, en septiembre de 2020 esto había expuesto más de 500.000 dominios de gTLD al riesgo de secuestro, y la resolución de más de 163.000 había quedado bajo control no autorizado; SAC125 señala que se desconoce el alcance en los ccTLD. Recomienda un código de conducta para registros y registradores; a octubre de 2026 no consta ningún código adoptado. Renovar los dominios que alojan los servidores de nombres propios reduce este riesgo. ## Fuentes - [RFC 9499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc9499.txt) - [RFC 2182: Selection and Operation of Secondary DNS Servers](https://www.rfc-editor.org/rfc/rfc2182.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [Technical requirements for authoritative name servers (IANA)](https://www.iana.org/help/nameserver-requirements) - [SAC125: SSAC Report on Registrar Nameserver Management](https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-125-09-05-2024-en.pdf) ## términos relacionados - [servidor autoritativo](https://tldlog.com/es/glosario/servidor-autoritativo/) - [registro NS](https://tldlog.com/es/glosario/registro-ns/) - [registro de pegado](https://tldlog.com/es/glosario/registro-pegado/) - [DNS](https://tldlog.com/es/glosario/dns/)