Solo para visitantes de nuestro blog Obtenga 3 meses adicionales gratis + 10% de descuento en el plan trianual YSBLOG10
Agarra el trato

Linux DNS Configuración del servidor: guía detallada 2026

Última actualización: marzo 7, 2026 10 minutos de lectura Sanjeet Chauhan
Linux DNS Configuración del servidor

Linux DNS La configuración del servidor es el proceso de instalación, aseguramiento y ajuste de un DNS servicio (por ejemplo, BIND o Unbound) en Linux para resolver o responder de forma autorizada a consultas de dominio. Incluye la planificación de zonas, la creación de registros, el establecimiento de controles de acceso y la habilitación. DNSSEC, apertura del puerto 53 (UDP/TCP), adición de servidores secundarios y validación con dig, delv y registros.

Si desea una resolución de nombres confiable para sitios web, correo electrónico y servicios internos, dominar Linux es fundamental. DNS La configuración del servidor es esencial. Esta guía explica, paso a paso, cómo planificar, implementar, proteger y optimizar servidores autoritativos y recursivos. DNS en distribuciones modernas de Linux en 2026, utilizando configuraciones probadas en condiciones reales y experiencia de alojamiento en el mundo real.


Lo que DNS ¿Qué es y por qué importa?

El sistema de nombres de dominio (DNS) asigna nombres fáciles de entender para los humanos (ejemplo.com) a direcciones IP. Cada solicitud web, llamada a la API y entrega de correo electrónico depende de DNS.

Linux DNS Configuración del servidor

Un Linux bien configurado DNS El servidor mejora el rendimiento, la fiabilidad y la seguridad de su red y sus aplicaciones.

Autoritativo vs. Recursivo (Almacenamiento en caché) DNS

Antes de configurar cualquier cosa, decide tu rol:

  • Servidor autorizado: Aloja tus zonas y devuelve respuestas finales para tus dominios (A, AAAA, MX, TXT, etc.).
  • Solucionador recursivo (almacenamiento en caché): Encuentra respuestas en nombre de los clientes consultando Internet y almacena en caché los resultados para acelerar las búsquedas posteriores.

Muchas organizaciones ejecutan ambos: un par autorizado público para sus dominios y solucionadores de almacenamiento en caché internos para usuarios y servidores.


Planifique primero su arquitectura

Una buena planificación previene interrupciones. Define el alcance y la seguridad desde el primer día.

Decisiones clave

  • Rol:Autoritario, recursivo o dividido (utilizando vistas para lo interno/externo).
  • plataformas: Ubuntu 22.04/24.04 LTS, Debian 12, RHEL/Rocky/Alma 9.
  • Topología: Dos o más servidores de nombres autorizados separados geográficamente; uno o más solucionadores internos (anycast si es posible).
  • Zonas y registros: Elija el nombre, los TTL (normalmente entre 300 y 3600) y una política de serie (AAAAMMDDnn).
  • Seguridad: ACL, claves TSIG para transferencias, DNSFirma de la SEC, limitación de la tasa de respuesta (RRL), respuestas mínimas y registro de actividad.

Prerrequisitos y networking

  • Abra el puerto 53 UDP/TCP en los firewalls y cualquier equilibradores de carga.
  • Asegúrese de que haya sincronización horaria (chrony) y nombres de host estables.
  • Sistema operativo reforzado: mínimo privilegio, parches, perfiles AppArmor/SELinux.
  • Utilice direcciones IP estáticas (IPv4 y IPv6) para servidores autoritativos.

Opción A: Configurar un solucionador de almacenamiento en caché con Unbound

Unbound es un resolvedor recursivo seguro y ligero con DNSValidación SEC y minimización de QNAME por defecto: ideal para redes internas.

Instalar Unbound

# Ubuntu/Debian
sudo apt update && sudo apt install -y unbound

# RHEL/Rocky/Alma
sudo dnf install -y unbound

Configuración mínima sin límites

Cree o edite /etc/unbound/unbound.conf (las rutas varían según la distribución). Este ejemplo permite DNSSEC, control de acceso y reenviadores opcionales.

server:
  username: "unbound"
  directory: "/etc/unbound"
  interface: 0.0.0.0
  interface: ::0
  access-control: 10.0.0.0/8 allow
  access-control: 172.16.0.0/12 allow
  access-control: 192.168.0.0/16 allow
  access-control: 127.0.0.0/8 allow
  access-control: ::1 allow
  do-ip4: yes
  do-ip6: yes
  do-udp: yes
  do-tcp: yes

  # Security and privacy
  harden-glue: yes
  harden-dnssec-stripped: yes
  qname-minimisation: yes
  hide-identity: yes
  hide-version: yes
  rrset-roundrobin: yes

  # Performance
  cache-min-ttl: 60
  cache-max-ttl: 86400
  msg-cache-size: 64m
  rrset-cache-size: 128m
  num-threads: 2

  # DNSSEC
  auto-trust-anchor-file: "/var/lib/unbound/root.key"

# Optional: Forward to upstream (e.g., your ISP or public resolvers)
# Set to your preferred forwarders if you don't want full recursion
forward-zone:
  name: "."
  forward-tls-upstream: yes
  forward-addr: 1.1.1.1@853#cloudflare-dns.com
  forward-addr: 9.9.9.9@853#dns.quad9.net

Inicie y habilite el servicio, luego valide:

sudo systemctl enable --now unbound
unbound-checkconf
dig @127.0.0.1 youstable.com +dnssec
delv youstable.com

Cortafuegos y SELinux

# UFW
sudo ufw allow 53
sudo ufw status

# firewalld
sudo firewall-cmd --permanent --add-service=dns
sudo firewall-cmd --reload

# SELinux (RHEL family) - Unbound default policy is usually sufficient
sudo getenforce
# If enforcing breaks DNS unexpectedly, review AVC logs before changing mode

Opción B: Configurar un servidor autorizado con BIND 9

BIND 9 sigue siendo la norma autorizada más común. DNS En Linux. La siguiente configuración está dirigida a BIND 9.18+ LTS, ampliamente disponible en diversas distribuciones en 2026.

Instalar BIND

# Ubuntu/Debian
sudo apt update && sudo apt install -y bind9 bind9-utils

# RHEL/Rocky/Alma
sudo dnf install -y bind bind-utils

Opciones globales (named.conf.options)

En Debian/Ubuntu, edite /etc/bind/named.conf.options. En sistemas similares a RHEL, use /etc/named.conf. Adapte las IP y las ACL a su entorno.

options {
  directory "/var/cache/bind";
  listen-on { any; };
  listen-on-v6 { any; };

  // Authoritative only: no recursion
  recursion no;
  allow-query { any; };
  allow-transfer { none; }; // override per-zone when using secondaries

  // Hardening
  minimal-responses yes;
  rate-limit {
    responses-per-second 25;
  };
  dnssec-enable yes;
  dnssec-validation yes;

  // Logging (basic)
  querylog yes;
};

logging {
  channel default_log {
    file "/var/log/named/named.log" versions 5 size 10m;
    severity info;
    print-time yes;
  };
  category default { default_log; };
  category queries { default_log; };
};

Crear una zona delantera (ejemplo.com)

Añade una cláusula de zona y un archivo de zona. Reemplaza las direcciones IP, los hosts y los registros de correo con tus valores reales.

// named.conf.local (Debian/Ubuntu) or appended to /etc/named.conf on RHEL
zone "example.com" {
  type master;
  file "/etc/bind/zone.example.com"; // RHEL: /var/named/zone.example.com
  allow-transfer { 203.0.113.53; 2001:db8::53; }; // secondaries
  also-notify { 203.0.113.53; 2001:db8::53; };
  inline-signing yes;    // for DNSSEC (optional now; see DNSSEC section)
  auto-dnssec maintain;  // enables automatic signing/rollover
};
$TTL 300
@   IN SOA ns1.example.com. admin.example.com. (
      2026010101 ; serial YYYYMMDDnn
      3600       ; refresh
      600        ; retry
      1209600    ; expire
      300 )      ; minimum

    IN NS   ns1.example.com.
    IN NS   ns2.example.com.

; A/AAAA records
ns1 IN A     198.51.100.10
ns1 IN AAAA  2001:db8:10::10
ns2 IN A     203.0.113.53
ns2 IN AAAA  2001:db8:53::53
@   IN A     198.51.100.20
@   IN AAAA  2001:db8:20::20
www IN CNAME @

; Mail
@   IN MX 10 mail.example.com.
mail IN A    198.51.100.30
mail IN AAAA 2001:db8:30::30

; Verification / policy
@   IN TXT "v=spf1 a mx ~all"
_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
; Add DKIM TXT via your MTA tooling

; SRV example (SIP)
_sip._tcp IN SRV 10 60 5060 sip1.example.com.
sip1 IN A 198.51.100.40

Crear una zona inversa (203.0.113.0/24)

zone "113.0.203.in-addr.arpa" {
  type master;
  file "/etc/bind/zone.203.0.113.rev";
};

; /etc/bind/zone.203.0.113.rev
$TTL 300
@ IN SOA ns1.example.com. admin.example.com. (
     2026010101 3600 600 1209600 300 )
  IN NS ns1.example.com.
  IN NS ns2.example.com.

10  IN PTR ns1.example.com.
20  IN PTR example.com.
30  IN PTR mail.example.com.

Validar e iniciar BIND

sudo named-checkconf
sudo named-checkzone example.com /etc/bind/zone.example.com
sudo named-checkzone 113.0.203.in-addr.arpa /etc/bind/zone.203.0.113.rev

sudo systemctl enable --now named    # RHEL
sudo systemctl enable --now bind9    # Debian/Ubuntu

dig @127.0.0.1 example.com A
dig @127.0.0.1 -x 198.51.100.20

Registrador y pegamento

Crea servidores de nombres (ns1/ns2) con el protocolo Glue A/AAAA en tu registrador y, a continuación, configura tu dominio para que utilice esos servidores. La propagación suele completarse en cuestión de minutos o hasta 48 horas, dependiendo del registro y los TTL.

Horizonte dividido (vistas) para lo interno y lo externo

Las vistas brindan diferentes respuestas a diferentes clientes, lo que resulta ideal para exponer registros públicos y al mismo tiempo mantener privadas las IP internas.

acl "internal_nets" { 10.0.0.0/8; 192.168.0.0/16; };

view "internal" {
  match-clients { "internal_nets"; };
  recursion yes; // if you also want to resolve for internal users
  zone "example.com" {
    type master;
    file "/etc/bind/zone.example.com.internal";
  };
};

view "external" {
  match-clients { any; };
  recursion no;
  zone "example.com" {
    type master;
    file "/etc/bind/zone.example.com";
  };
};

Activar DNSSEC sobre las zonas de autoridad

DNSSEC evita la suplantación de identidad firmando sus registros. Con firma en línea y mantenimiento automático de DNSSEC, BIND manages teclas automáticamente.

# Ensure these are set in zone config:
# inline-signing yes;
# auto-dnssec maintain;

# Generate keys (if not auto-created)
cd /var/cache/bind
sudo rndc loadkeys example.com

# Check status
sudo rndc signing -list example.com
dig +dnssec example.com DS @ns1.example.com

Una vez que los registros DS aparezcan en su zona firmada, publique el DS en su registrador para que los resolvedores puedan validar su dominio.

Transferencias de zona y secundarias

Utilice siempre al menos un servidor de nombres secundario en una red o región independiente. Transferencias seguras con TSIG.

key "xfr-key" {
  algorithm hmac-sha256;
  secret "YOUR_BASE64_SECRET";
};

server 203.0.113.53 {
  keys { "xfr-key"; };
};

zone "example.com" {
  type master;
  file "/etc/bind/zone.example.com";
  allow-transfer { key "xfr-key"; 203.0.113.53; };
  also-notify { 203.0.113.53; };
  notify yes;
};

Endurecimiento y mejores prácticas (2026)

  • Superficie límite: Deshabilitar la recursión en servidores públicos autorizados.
  • RRL y respuestas mínimas: Reducir el riesgo de amplificación.
  • Minimización de QNAME (valor predeterminado sin límite, compatible con BIND): Aumentar la privacidad.
  • Monitorear registros y consultas: Utilice journald, registros BIND y exportadores de métricas.
  • Mantenga los paquetes actualizados: BIND 9.18+ o LTS actual; última versión estable de Unbound.
  • Usar IPv6 junto al IPv4 y asegúrese de usar pegamento para ambos.
  • Establecer TTL razonables: 300–600 s para registros de movimiento rápido; 3600–14400 s para registros estables.
  • Documente los cambios en serie y automatice con CI/CD para evitar zonas obsoletas.

Lista de verificación de solución de problemas

  • SERVFAIL en dominios firmados: Compruebe si hay desajustes de DS o claves caducadas con delv.
  • NXDOMAIN frente a NOERROR: Validar el contenido de la zona con una zona de verificación denominada.
  • Respuestas obsoletas: Reducir TTL y vaciar cachés (rndc flush; control no vinculado flush_zone).
  • Transferencias fallidas: Verifique TSIG, abra TCP/53 y permita ACL de transferencia.
  • Sin accesibilidad externa: Confirme que el firewall público/NAT permita UDP/TCP 53.

Apunte los hosts Linux a su nuevo solucionador

Distribuciones modernas manage Resolví el archivo resolv.conf mediante systemd solved o NetworkManager. Configure con la herramienta adecuada en lugar de editar directamente el archivo resolv.conf.

systemd resuelto (Ubuntu/Debian)

# Netplan example (Ubuntu)
# /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    ens18:
      addresses: [192.0.2.10/24]
      routes:
        - to: default
          via: 192.0.2.1
      nameservers:
        addresses: [10.0.0.53, 2001:db8::53]

sudo netplan apply
resolvectl status

Administrador de red (RHEL/Rocky/Alma)

nmcli con mod eth0 ipv4.dns "10.0.0.53" ipv4.ignore-auto-dns yes
nmcli con mod eth0 ipv6.dns "2001:db8::53" ipv6.ignore-auto-dns yes
nmcli con up eth0
resolvectl status

Consejos prácticos de operaciones de alojamiento

  • Patrón maestro oculto: Mantenga el maestro detrás de un firewall; exponga solo los secundarios públicamente.
  • Anycast para resolutores: Mejora la latencia y la resiliencia para los usuarios internos.
  • Zonas de preparación: Pruebe nuevos registros en un subdominio antes de la producción.
  • Reducir TTL antes de las migraciones: Bajar a 60–120 24 horas antes y luego aumentar después del corte.
  • Agujero negro de consultas: Bloquee a los clientes abusivos en el firewall y mediante ACL BIND.

¿Cuándo elegir la opción gestionada? DNS o servidores gestionados

Correr DNS El control interno ofrece autonomía, pero requiere vigilancia: parches de seguridad, monitoreo 24x7 y cambios cuidadosos. managemento. Si prefieres centrarte en las aplicaciones, considera managed DNS managed VPS/Servidor dedicado.

YouStable Proporciona servidores VPS y dedicados optimizados para el rendimiento con soporte experto, y puede ayudarle a implementar alta disponibilidad segura. DNS En consonancia con las mejores prácticas.


Preguntas Frecuentes

¿Cuál es la diferencia entre BIND y Unbound en Linux?

BIND es un servidor autoritativo y recursivo con todas las funciones, ideal para alojar zonas y DNSFirma SEC. Unbound se centra en la recursión y el almacenamiento en caché seguros y rápidos. Muchas implementaciones utilizan BIND para zonas autoritativas y Unbound para resolutores internos.

Lo necesito DNS¿SEC para mi dominio en 2026?

Sí, es altamente recomendable. DNSSEC evita el envenenamiento de caché y la manipulación de rutas. Habilite la firma en línea con BIND, publique DS en su registrador y valide con delv o dig + dnssec. Su adopción ha madurado y las herramientas son estables.

¿Cuántas DNS ¿Qué servidores debería ejecutar?

Al menos dos servidores autorizados en diferentes ubicaciones o redes. Para los resolutores, implemente dos o más y considere anycast para mayor resiliencia. Evite puntos únicos de fallo y ventanas de mantenimiento compartidas.

Cuánto tiempo dura DNS ¿Propagación?

La propagación depende del procesamiento del registrador y de sus TTL. La mayoría de los cambios empiezan a aparecer en cuestión de minutos, pero pueden tardar hasta 24-48 horas a nivel global. Reduzca los TTL antes de realizar cambios importantes para acelerar las migraciones.

¿Qué puertos deben estar abiertos para? DNS ¿trabajar?

Abra el puerto UDP 53 para consultas y el puerto TCP 53 para respuestas grandes. DNSSEC y transferencias de zona. Para DNS sobre TLS (opcional), abra TCP 853 en los resolvedores. Asegúrese de que ambos IPv4 y IPv6 Se permiten donde se utilicen.


Conclusión

Con una planificación cuidadosa, configuraciones reforzadas y monitoreo continuo, Linux DNS La configuración del servidor ofrece servicios de nombres rápidos, seguros y resilientes. Utilice Unbound para el almacenamiento en caché interno, BIND para zonas autoritativas y habilite DNSSEC, agregue secundarios y automatice los cambios. Si necesita ayuda o prefiere una manageenfoque d, YouStableLos expertos en alojamiento de pueden implementar y mantener un nivel de producción DNS pila para ti.

Deja Tu Comentario

Su dirección de correo electrónico no será publicada. Las areas obligatorias están marcadas como requeridas *

Ir al Inicio