Un servidor DNS (Domain Name System) es un servidor que responde consultas de resolución de nombres: traduce nombres de dominio legibles por humanos como sys4net.com en las direcciones IP numéricas que los ordenadores usan para comunicarse, como 195.234.56.78. El DNS es la infraestructura de traducción de nombres de internet, definida en los RFC 1034 y 1035 de 1987 y ampliada desde entonces. Sin el DNS, para acceder a cualquier sitio web tendríamos que memorizar su dirección IP en lugar de su nombre de dominio. En 2026, el DNS gestiona miles de millones de consultas por segundo en todo el mundo y es tan fundamental para el funcionamiento de internet como el propio protocolo IP.
Por qué existe el DNS: el problema que resuelve
Los ordenadores se comunican usando direcciones IP numéricas. Cuando un navegador quiere cargar sys4net.com, necesita saber la dirección IP del servidor donde está alojado ese sitio. El DNS es el sistema que hace esa traducción.
Antes del DNS, existía un sistema mucho más sencillo: un archivo de texto llamado HOSTS.TXT que contenía todos los nombres de dominio y sus IPs correspondientes. Este archivo era mantenido por el Stanford Research Institute y todos los ordenadores de ARPANET lo descargaban periódicamente para tener la lista actualizada. Cuando ARPANET tenía unos cientos de nodos, esto funcionaba bien. Pero a principios de los 80, con la explosión del crecimiento de la red, el archivo HOSTS.TXT se volvió inmanejable: el tráfico de descarga del archivo saturaba la red, y las actualizaciones tardaban días en propagarse.
En 1983, Paul Mockapetris diseñó el DNS como solución: un sistema distribuido y jerárquico que elimina el punto único de fallo y la necesidad de un archivo centralizado. Publicó las especificaciones en los RFC 882 y 883, revisados en 1987 como RFC 1034 y RFC 1035, que siguen siendo los documentos fundacionales del DNS hoy en día.
La jerarquía del DNS: cómo está organizado
El DNS es un sistema jerárquico distribuido organizado en forma de árbol invertido. Cada nivel de la jerarquía es gestionado por diferentes organizaciones y servidores:
# Árbol del DNS (simplificado):
#
# . (raíz)
# / | \
# com org net ← TLDs (Top Level Domains)
# /
# sys4net
# / \
# www mail ← SubdominiosLos cuatro tipos de servidores DNS
| Tipo de servidor | Función | Quién lo gestiona | Cuántos hay |
|---|---|---|---|
| Servidor raíz (Root) | El nivel más alto de la jerarquía. Conoce los servidores autoritativos de cada TLD (.com, .es, .org, etc.) pero no resuelve dominios directamente. | 12 organizaciones independientes coordinadas por ICANN | 13 servidores raíz (a.root-servers.net a m.root-servers.net), con cientos de instancias físicas via anycast |
| Servidor TLD (Top Level Domain) | Gestiona el TLD correspondiente (.com, .es, .net, etc.). Conoce los servidores de nombres autoritativos de cada dominio bajo ese TLD. | Registries: Verisign gestiona .com y .net; Red.es gestiona .es | Uno por TLD, con múltiples instancias por redundancia |
| Servidor autoritativo | El servidor definitivo para un dominio específico. Contiene los registros DNS reales del dominio (A, AAAA, MX, TXT, etc.) y da respuestas autoritativas. | El propietario del dominio o su proveedor de hosting/DNS | Al menos 2 por dominio (primario y secundario), por redundancia |
| Resolver recursivo | El servidor DNS que usan los dispositivos de los usuarios para resolver nombres. Hace las consultas en nombre del cliente, recorriendo la jerarquía si es necesario. | ISPs, empresas (DNS corporativos), proveedores de DNS público (Cloudflare, Google) | Millones en todo el mundo |
Cómo funciona la resolución DNS: paso a paso
La resolución de un nombre de dominio implica una serie de consultas entre distintos servidores DNS. Este es el proceso completo para resolver sys4net.com desde cero, asumiendo que no hay nada en caché:
Paso 1: El cliente consulta su caché DNS local
Antes de hacer ninguna consulta de red, el sistema operativo comprueba su propia caché DNS: un almacén temporal de respuestas DNS recibidas anteriormente que todavía son válidas según su TTL. Si la respuesta está en caché, la usa directamente y el proceso termina aquí. Si no está en caché, pasa al siguiente paso.
Paso 2: El cliente consulta el resolver recursivo
El sistema operativo envía la consulta al resolver recursivo configurado en su red. En redes domésticas, suele ser el DNS del ISP o uno público como 1.1.1.1 (Cloudflare) o 8.8.8.8 (Google). El resolver comprueba también su propia caché antes de hacer consultas adicionales.
Paso 3: El resolver consulta un servidor raíz
Si el resolver no tiene la respuesta en caché, consulta a uno de los 13 servidores raíz (tiene la lista de todos ellos hardcodeada). El servidor raíz no sabe la IP de sys4net.com, pero sabe qué servidores gestionan el TLD .com y responde con una lista de esos servidores TLD.
Paso 4: El resolver consulta el servidor TLD de .com
El resolver contacta con uno de los servidores TLD de .com (gestionados por Verisign). El servidor TLD tampoco sabe la IP de sys4net.com, pero sabe qué servidores son autoritativos para ese dominio (los que registraste cuando compraste el dominio) y responde con esa información.
Paso 5: El resolver consulta el servidor autoritativo de sys4net.com
El resolver contacta con el servidor DNS autoritativo de sys4net.com (por ejemplo, ns1.sys4net.com). Este servidor SÍ tiene la respuesta definitiva: contiene los registros DNS del dominio y devuelve la IP correspondiente al registro A de sys4net.com.
Paso 6: El resolver devuelve la respuesta y la cachea
El resolver recibe la respuesta autoritativa, la guarda en su caché durante el tiempo indicado por el TTL del registro, y la devuelve al cliente. El cliente también la guarda en su caché local durante ese período.
Paso 7: El navegador establece la conexión
Con la IP ya conocida, el navegador puede establecer la conexión TCP (y el handshake TLS si es HTTPS) con el servidor web y solicitar la página.
# Ver el proceso de resolución DNS paso a paso con dig:
dig +trace sys4net.com A
# La salida mostrará exactamente los pasos descritos arriba:
# 1. Consulta a los servidores raíz
# 2. Referral a los servidores TLD de .com
# 3. Referral a los servidores autoritativos de sys4net.com
# 4. Respuesta final con la IPTipos de consultas DNS: recursivas e iterativas
El proceso descrito arriba involucra dos tipos de consultas DNS que funcionan de forma diferente:
| Tipo de consulta | Quién la hace | Qué espera como respuesta | Cómo funciona |
|---|---|---|---|
| Consulta recursiva | El cliente (tu dispositivo) al resolver | La respuesta final completa o un error | El cliente delega todo el trabajo al resolver: "encuentra la IP de sys4net.com, haz lo que haga falta". El resolver se encarga de todas las consultas intermedias. |
| Consulta iterativa | El resolver a los servidores raíz, TLD y autoritativos | La mejor respuesta que el servidor puede dar, aunque no sea la final | El resolver hace una consulta a cada servidor. Si ese servidor no tiene la respuesta final, devuelve una referencia al siguiente servidor en la jerarquía. El resolver sigue preguntando hasta obtener la respuesta definitiva. |
Los registros DNS: todos los tipos explicados
Los registros DNS son las entradas individuales en la zona DNS de un dominio. Cada tipo de registro tiene un propósito específico:
Registros de dirección: A y AAAA
| Tipo | Función | Ejemplo | Notas |
|---|---|---|---|
| A | Asocia un nombre de host a una dirección IPv4 | sys4net.com → 195.234.56.78 | El registro más fundamental. Un dominio puede tener múltiples registros A para distribución de carga (round-robin DNS). |
| AAAA | Asocia un nombre de host a una dirección IPv6 | sys4net.com → 2001:db8::1 | Necesario para soportar IPv6. El nombre "AAAA" viene de que una dirección IPv6 tiene 4 veces los bits de una IPv4 (128 vs 32). |
Registro CNAME: alias de dominio
Un registro CNAME (Canonical Name) crea un alias de un nombre a otro. El servidor DNS resuelve el alias hasta encontrar un registro A o AAAA.
# Ejemplo de registros CNAME:
# www.sys4net.com → sys4net.com (CNAME)
# sys4net.com → 195.234.56.78 (A)
# El cliente consulta www.sys4net.com:
# 1. El DNS devuelve el CNAME: www.sys4net.com → sys4net.com
# 2. El cliente consulta sys4net.com:
# 3. El DNS devuelve el registro A: sys4net.com → 195.234.56.78
# Restricciones importantes de CNAME:
# - No puede coexistir con otros registros en el mismo nombre (especialmente SOA y NS)
# - No puede usarse en el dominio raíz (@): sys4net.com no puede ser CNAME
# (por eso el dominio raíz necesita un registro A directo)
# - Puede encadenarse, pero no más de 8 saltos (para evitar bucles)
# El registro ALIAS o ANAME (no estándar pero soportado por muchos DNS):
# Es como un CNAME pero funciona en el dominio raíz. Usado por Cloudflare, Route53, etc.
# para apuntar sys4net.com a un CDN sin exponer la IP directa.Registro MX: servidores de correo
Los registros MX (Mail Exchange) definen qué servidores son responsables de recibir el correo electrónico para el dominio. Cada registro MX tiene una prioridad: cuanto menor es el número, mayor es la prioridad.
# Ejemplo de registros MX:
# sys4net.com IN MX 10 mail.sys4net.com
# sys4net.com IN MX 20 mail2.sys4net.com # Backup: se usa si el primario falla
# Verificar los registros MX de un dominio:
dig sys4net.com MX
# o:
nslookup -type=MX sys4net.com
# Los servidores de correo de Google Workspace:
# dominio.com IN MX 1 aspmx.l.google.com
# dominio.com IN MX 5 alt1.aspmx.l.google.com
# dominio.com IN MX 5 alt2.aspmx.l.google.com
# dominio.com IN MX 10 alt3.aspmx.l.google.com
# dominio.com IN MX 10 alt4.aspmx.l.google.comRegistro TXT: texto arbitrario para verificación y autenticación
Los registros TXT permiten asociar texto arbitrario a un dominio. En 2026 se usan principalmente para:
| Uso | Ejemplo de registro TXT |
|---|---|
| SPF (autenticación del correo saliente) | v=spf1 ip4:195.234.56.78 include:_spf.google.com ~all |
| DKIM (firma digital del correo) | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUA... |
| DMARC (política de autenticación del correo) | v=DMARC1; p=reject; rua=mailto:dmarc@sys4net.com |
| Verificación de Google Search Console | google-site-verification=abc123def456... |
| Verificación de dominio de Cloudflare | cloudflare-verify=abc123... |
| BIMI (logo de marca en el correo) | v=BIMI1; l=https://sys4net.com/logo.svg |
Registros NS: servidores de nombres
Los registros NS (Name Server) definen qué servidores DNS son autoritativos para el dominio. Son los más fundamentales después de los registros A: sin NS, nadie sabe a qué servidor preguntar por los registros del dominio.
# Ejemplo de registros NS:
# sys4net.com IN NS ns1.sys4net.com
# sys4net.com IN NS ns2.sys4net.com
# Los registros NS del dominio raíz se configuran en el registrar (GoDaddy, Namecheap, etc.)
# cuando compras el dominio y apuntas a tus servidores DNS.
# Verificar los NS de un dominio:
dig sys4net.com NS +short
# Resultado:
# ns1.sys4net.com.
# ns2.sys4net.com.
# Ver los NS autoritativos directamente desde el servidor raíz (sin caché):
dig @a.root-servers.net sys4net.com NSRegistro SOA: Start of Authority
El registro SOA es el primero en cualquier zona DNS y contiene información administrativa de la zona:
# Ejemplo de registro SOA:
# sys4net.com IN SOA ns1.sys4net.com. hostmaster.sys4net.com. (
# 2026060301 ; Serial (formato YYYYMMDDNN: fecha + número de revisión)
# 3600 ; Refresh: cada cuántos segundos los NS secundarios comprueban cambios
# 900 ; Retry: si el refresh falla, cada cuánto reintentar
# 604800 ; Expire: cuánto tiempo es válida la zona si el primario es inaccesible
# 300 ; Minimum TTL: TTL mínimo para respuestas negativas (NXDOMAIN)
# )
dig sys4net.com SOARegistro PTR: DNS inverso
El registro PTR (Pointer) hace el proceso inverso al registro A: dado una dirección IP, devuelve el nombre de dominio asociado. Se usa en el "DNS inverso" o "rDNS".
# El DNS inverso usa zonas especiales:
# Para IPv4: IP al revés bajo .in-addr.arpa
# Para la IP 195.234.56.78:
# 78.56.234.195.in-addr.arpa IN PTR sys4net.com
# Para IPv6: nibbles al revés bajo .ip6.arpa
# Para 2001:db8::1:
# 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa IN PTR sys4net.com
# Verificar el DNS inverso de una IP:
dig -x 195.234.56.78
# o:
nslookup 195.234.56.78
# Por qué es importante el PTR para el correo:
# Los servidores de correo receptores (Gmail, Outlook, etc.) verifican que la IP
# del servidor que envía el correo tiene un PTR configurado y que coincide con el dominio.
# Sin PTR correcto, el correo puede ir a spam o ser rechazado directamente.Registro CAA: control de emisión de certificados SSL
# CAA (Certification Authority Authorization) define qué CAs pueden emitir
# certificados SSL para el dominio:
# Solo Let's Encrypt puede emitir certificados:
sys4net.com IN CAA 0 issue "letsencrypt.org"
# Permitir también certificados wildcard de Let's Encrypt:
sys4net.com IN CAA 0 issuewild "letsencrypt.org"
# Reportar intentos de emisión no autorizados:
sys4net.com IN CAA 0 iodef "mailto:ssl@sys4net.com"
# Verificar el registro CAA de un dominio:
dig sys4net.com CAARegistro SRV: localización de servicios
# SRV define la ubicación de servicios específicos con formato:
# _servicio._protocolo.dominio TTL IN SRV prioridad peso puerto objetivo
# Ejemplo para Microsoft Teams / Skype for Business:
_sip._tls.sys4net.com IN SRV 100 1 443 sipdir.online.lync.com
_sipfederationtls._tcp.sys4net.com IN SRV 100 1 5061 sipfed.online.lync.com
# Ejemplo para XMPP (Jabber):
_xmpp-client._tcp.sys4net.com IN SRV 5 0 5222 xmpp.sys4net.com
# Verificar registros SRV:
dig _sip._tls.sys4net.com SRVEl TTL: tiempo de vida de los registros DNS
El TTL (Time To Live) es el tiempo en segundos que los resolvers DNS y los clientes pueden mantener en caché una respuesta antes de volver a consultarla. Es uno de los parámetros más importantes para gestionar la propagación de cambios DNS.
| TTL | Tiempo de propagación | Cuándo usarlo | Impacto en la carga DNS |
|---|---|---|---|
| 60 segundos | 1-2 minutos | Antes de una migración planificada: reduce el TTL 24h antes para que el cambio sea rápido | Alto: muchas consultas frecuentes a los servidores DNS |
| 300 segundos (5 min) | 5-10 minutos | Durante pruebas, dominio con cambios frecuentes, entorno de desarrollo | Moderado |
| 3.600 segundos (1 hora) | 1-2 horas | Balance entre velocidad de propagación y carga en los servidores DNS | Normal |
| 86.400 segundos (24 horas) | 24-48 horas | Registros estables que casi nunca cambian (registros MX de producción, registros A de servidores críticos) | Bajo: consultas poco frecuentes |
Estrategia para migraciones sin tiempo de inactividad:
- Al menos 24-48 horas antes de la migración: reduce el TTL de los registros críticos (A, MX) a 300 segundos o menos.
- Durante la migración: cambia los registros. Con TTL de 300 segundos, el cambio se propaga en 5-10 minutos.
- Verifica que todo funciona en el nuevo servidor.
- Aumenta el TTL de vuelta a su valor normal (3600 o 86400 segundos).
Servidores DNS públicos: cuáles son y cuándo usarlos
Los servidores DNS públicos son resolvers gratuitos operados por grandes empresas como alternativa a los DNS del ISP:
| Proveedor | DNS primario | DNS secundario | IPv6 primario | Característica principal |
|---|---|---|---|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 | 2606:4700:4700::1111 | El más rápido en benchmarks globales; fuerte énfasis en privacidad (no registra IPs) |
| 8.8.8.8 | 8.8.4.4 | 2001:4860:4860::8888 | Muy fiable y rápido; caché muy grande gracias al volumen de consultas | |
| Quad9 | 9.9.9.9 | 149.112.112.112 | 2620:fe::fe | Bloquea dominios maliciosos conocidos; privacidad fuerte; sin ánimo de lucro |
| OpenDNS (Cisco) | 208.67.222.222 | 208.67.220.220 | 2620:119:35::35 | Filtrado de contenido configurable; soluciones para empresas y familias |
| Comodo Secure | 8.26.56.26 | 8.20.247.20 | — | Bloqueo de malware y phishing |
# Cambiar el DNS en Linux (NetworkManager):
nmcli connection modify "Nombre de la conexión" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli connection up "Nombre de la conexión"
# Cambiar el DNS temporalmente en Linux (solo hasta el próximo reinicio de red):
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf
echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf
# En servidores con systemd-resolved:
sudo systemd-resolve --set-dns=1.1.1.1 --interface=eth0
# Cambiar el DNS en macOS desde terminal:
networksetup -setdnsservers Wi-Fi 1.1.1.1 8.8.8.8
# Cambiar el DNS en Windows desde PowerShell:
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","8.8.8.8")Herramientas de diagnóstico DNS
dig: la herramienta más completa
# Consulta básica de registro A:
dig sys4net.com A
# Salida corta (solo el valor del registro):
dig +short sys4net.com A
dig +short sys4net.com MX
dig +short sys4net.com TXT
dig +short sys4net.com NS
# Consultar un servidor DNS específico:
dig @1.1.1.1 sys4net.com A # Cloudflare
dig @8.8.8.8 sys4net.com A # Google
dig @ns1.sys4net.com sys4net.com A # El servidor autoritativo del dominio
# Deshabilitar la búsqueda recursiva (consulta directa al servidor):
dig +norecurse @ns1.sys4net.com sys4net.com A
# Ver la trazabilidad completa del proceso de resolución:
dig +trace sys4net.com A
# Consultar múltiples tipos de registro:
dig sys4net.com ANY
# NOTA: muchos servidores ignoran consultas ANY por motivos de seguridad;
# mejor consultar cada tipo específicamente
# Consulta inversa (DNS inverso de una IP):
dig -x 195.234.56.78
# Ver el TTL de un registro:
dig sys4net.com A | grep -v "^;" | grep A
# Muestra: sys4net.com. 3600 IN A 195.234.56.78
# El número 3600 es el TTL en segundos
# Buscar si el registro está en caché (TTL reducido) o es fresco:
# Si el TTL mostrado es menor que el configurado, está respondiendo desde cachénslookup: alternativa disponible en todos los sistemas
# Consulta básica:
nslookup sys4net.com
# Consultar un tipo específico de registro:
nslookup -type=MX sys4net.com
nslookup -type=TXT sys4net.com
nslookup -type=NS sys4net.com
nslookup -type=AAAA sys4net.com
# Usar un servidor DNS específico:
nslookup sys4net.com 1.1.1.1
nslookup sys4net.com 8.8.8.8
# Modo interactivo de nslookup:
nslookup
> server 1.1.1.1 # Cambiar el servidor DNS a usar
> set type=MX # Cambiar el tipo de registro
> sys4net.com # Hacer la consulta
> exithost: la más sencilla de las tres
# Consulta básica:
host sys4net.com
# Consultar tipo específico:
host -t MX sys4net.com
host -t NS sys4net.com
host -t TXT sys4net.com
# Consulta inversa:
host 195.234.56.78
# Usar servidor DNS específico:
host sys4net.com 1.1.1.1Diagnóstico de problemas DNS frecuentes
# Problema 1: El dominio no resuelve (NXDOMAIN)
dig sys4net.com A
# Si devuelve "NXDOMAIN": el dominio no existe en el DNS o los NS están mal configurados
# Verificar:
dig sys4net.com NS # ¿Tiene registros NS?
dig @a.root-servers.net sys4net.com NS # ¿Los raíces conocen el dominio?
# Problema 2: El cambio de DNS no se propaga
# Verificar en distintos resolvers:
dig @1.1.1.1 sys4net.com A +short # Cloudflare (normalmente más rápido)
dig @8.8.8.8 sys4net.com A +short # Google
dig @ns1.sys4net.com sys4net.com A +short # El autoritativo (siempre tiene el valor actual)
# Si el autoritativo tiene el valor correcto pero los resolvers aún no:
# El cambio aún está propagándose según el TTL del registro anterior.
# Herramienta online: whatsmydns.net — verifica la propagación desde distintos países
# Problema 3: El correo va a spam (SPF/DKIM/DMARC mal configurados)
dig sys4net.com TXT +short | grep spf
dig default._domainkey.sys4net.com TXT +short
dig _dmarc.sys4net.com TXT +short
# Problema 4: Verificar que el servidor DNS autoritativo responde:
dig @ns1.sys4net.com sys4net.com SOA
# Si no responde: el servidor DNS primario puede estar caído
# Problema 5: Verificar el PTR (DNS inverso) de una IP:
dig -x 195.234.56.78 +short
# Si no devuelve resultado: la IP no tiene PTR configurado
# El PTR lo configura el proveedor de hosting, no el registrar del dominioDNSSEC: seguridad en el DNS
El DNS original fue diseñado sin ninguna consideración de seguridad: cualquier servidor DNS malicioso puede responder con respuestas falsas, redirigiendo a los usuarios a sitios fraudulentos (DNS spoofing o cache poisoning). DNSSEC (DNS Security Extensions, RFC 4033-4035) añade firmas digitales criptográficas a los registros DNS para verificar su autenticidad.
# Verificar si un dominio tiene DNSSEC habilitado:
dig sys4net.com DNSKEY +short
# Si devuelve registros DNSKEY: DNSSEC está activo
# Verificar la cadena de confianza DNSSEC completa:
dig sys4net.com A +dnssec
# Busca en la respuesta los campos AD (Authenticated Data) y RRSIG
# Herramienta online para verificar DNSSEC:
# dnssec-debugger.verisignlabs.com
# Estado de DNSSEC en España (.es):
# Red.es soporta DNSSEC para el TLD .es
# La mayoría de registrars españoles permiten activarlo desde su panel de gestiónDNS over HTTPS (DoH) y DNS over TLS (DoT)
El DNS tradicional transmite las consultas en texto plano por UDP en el puerto 53. Esto significa que el ISP, el operador de red o cualquier observador en la ruta de red puede ver exactamente qué dominios está consultando un usuario, incluso si las páginas están cifradas con HTTPS. DNS over HTTPS (RFC 8484) y DNS over TLS (RFC 7858) resuelven esto cifrando las consultas DNS:
| Protocolo | Puerto | Cifrado | Soporte en 2026 |
|---|---|---|---|
| DNS clásico | 53 UDP/TCP | Ninguno: texto plano visible para el ISP y observadores de red | Universal pero inseguro |
| DNS over TLS (DoT) | 853 TCP | TLS: cifra las consultas DNS en una conexión TLS dedicada | Soportado por Android 9+, iOS 14+ (como "Private DNS"), Cloudflare, Google, Quad9 |
| DNS over HTTPS (DoH) | 443 TCP | HTTPS: cifra las consultas DNS dentro del tráfico HTTPS normal | Chrome, Firefox, Edge, Safari activable; Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9) |
| DNS over QUIC (DoQ) | 853 UDP | QUIC: el más moderno, combina seguridad y menor latencia | Emergente: soportado por Cloudflare y AdGuard; en desarrollo en navegadores |
# Usar DoH con curl para verificar la IP de un dominio:
curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=sys4net.com&type=A'
# Configurar DoH en Firefox:
# Configuración > General > Configuración de red > Configurar... >
# "Activar DNS mediante HTTPS" > elegir proveedor
# Configurar DoT en Android:
# Ajustes > Red e internet > DNS privado >
# Introduce: one.one.one.one (Cloudflare) o dns.google (Google)Preguntas frecuentes sobre el DNS
¿Cuántos servidores DNS raíz hay y por qué solo 13?
Hay 13 servidores DNS raíz identificados con letras de la A a la M (a.root-servers.net hasta m.root-servers.net), pero físicamente hay cientos de instancias distribuidas por todo el mundo gracias a la tecnología anycast. El número 13 no es arbitrario: viene de una limitación técnica del protocolo DNS original. Las respuestas DNS que contenían todos los registros de los servidores raíz debían caber en un único paquete UDP de 512 bytes (el límite de UDP de 1987), y 13 registros NS con sus IPs era el máximo que cabía en ese espacio. Con EDNS0 (RFC 2671, 1999), el límite de tamaño de paquetes DNS aumentó significativamente, pero los 13 identificadores de servidor raíz permanecen como estándar por compatibilidad y estabilidad del sistema.
¿Por qué el DNS usa UDP en lugar de TCP?
El DNS usa UDP (puerto 53) para la mayoría de sus consultas porque UDP es significativamente más rápido que TCP: no necesita establecer una conexión (no hay handshake de 3 pasos), no hay control de flujo ni retransmisión automática. Una consulta DNS UDP es un solo paquete de ida y uno de vuelta: mínima latencia. TCP se usa en DNS cuando la respuesta es demasiado grande para un paquete UDP (más de 512 bytes en DNS clásico, o el tamaño negociado con EDNS0), para las transferencias de zona entre servidores DNS (AXFR), y siempre en DNS over TLS.
¿Qué significa que un dominio "no se propague" y cuánto tarda realmente?
La "propagación DNS" es el tiempo que tarda un cambio en los registros DNS (cambiar la IP de un registro A, actualizar los NS, etc.) en ser visible para todos los usuarios en todo el mundo. Técnicamente, lo que ocurre es que los resolvers DNS de todo el mundo tienen la respuesta antigua en su caché durante el tiempo indicado por el TTL anterior. Una vez que ese TTL expira, el resolver vuelve a consultar el servidor autoritativo y obtiene el nuevo valor. Por eso el TTL configurado antes del cambio determina directamente cuánto tarda la propagación: con TTL de 300 segundos, 5-10 minutos; con TTL de 86.400 segundos (24 horas), hasta 48 horas. El servidor autoritativo siempre tiene el valor actualizado inmediatamente.
¿Qué diferencia hay entre el DNS del registrar y el DNS del hosting?
Cuando compras un dominio en un registrar (GoDaddy, Namecheap, Gandi, etc.), el registrar gestiona los registros NS del dominio: qué servidores DNS son autoritativos. Esos servidores DNS autoritativos son los que contienen los registros A, MX, TXT, etc. del dominio. Puedes usar el DNS del registrar (el que viene por defecto), el DNS de tu proveedor de hosting (como el de sys4net, que te permite gestionar todos los registros desde Plesk), o un DNS de terceros (Cloudflare es muy popular porque añade CDN y WAF además del DNS). Cambiar los nameservers (NS) en el registrar es lo que redirige la autoridad de los registros DNS de un proveedor a otro.
¿Por qué mi sitio carga pero el correo no llega después de cambiar el hosting?
Cuando cambias el hosting y mueves el dominio a nuevos nameservers, es frecuente olvidar configurar los registros MX en el nuevo DNS. El registro A (para el sitio web) suele configurarse primero y el sitio carga correctamente, pero sin el registro MX, el correo no sabe a qué servidor enviarse y los emails rebotan. Además, si tienes SPF, DKIM y DMARC configurados, también deben recrearse en el nuevo DNS. Antes de migrar, exporta todos los registros DNS del proveedor anterior y recréalos en el nuevo, incluyendo todos los TXT de autenticación de correo.
¿Puedo tener mi DNS en Cloudflare pero el hosting en sys4net?
Sí, y es una combinación muy popular. Para hacerlo: en el registrar del dominio, cambia los nameservers a los de Cloudflare (ns1.cloudflare.com, ns2.cloudflare.com). En el panel de Cloudflare, configura los registros DNS del dominio apuntando a las IPs de los servidores de sys4net. Cloudflare gestionará el DNS (y opcionalmente el CDN y el WAF), y sys4net alojará el sitio web y el correo. El tráfico web pasa por Cloudflare (proxy naranja) y el correo va directamente al servidor de correo de sys4net (sin proxy, ya que el correo no pasa por Cloudflare).
