Configuración DNS Hetzner para que la página web, los subdominios y el correo funcionen sin rodeos y los cambios surtan efecto rápidamente. En esta guía le muestro los ajustes necesarios en el DNS de Hetzner, una configuración de ejemplo probada y métodos de prueba prácticos para que pueda evitar errores desde el principio y mantener su zona limpia.
Puntos centrales
Los siguientes puntos clave le darán una visión rápida de lo que es importante para una zona DNS fiable.
- Servidor de nombres introducir correctamente con el registrador
- A/AAAA para Web, MX/TXT para el correo
- TTL Seleccionar adecuadamente y esperar la propagación
- SPF/DKIM contra el spam y la suplantación de identidad
- Monitoreo y pruebas tras los cambios
DNS en pocas palabras: lo que realmente necesita
Asigno un dominio a través de Registros destinos específicos para que los navegadores y servidores de correo puedan encontrar mis servicios. A A-Record apunta a una dirección IPv4, un AAAA a IPv6, y un MX define la entrega de correos electrónicos. Un CNAME forma un alias que apunta a un nombre diferente, mientras que TXT contiene información para SPF o verificaciones. Una línea de base limpia consiste en A/AAAA para el dominio principal, CNAME para www, MX para correo y un SPF-TXT. De esta forma mantengo la zona limpia, rápidamente mantenible y abierta para extensiones posteriores.
Añadir dominio a la consola DNS de Hetzner
En la consola DNS, primero creo un nuevo Zona y compruebo que la ortografía del dominio es exactamente la correcta. A continuación activo el mantenimiento manual de Registrospara poder crear y modificar entradas específicas. Consejo: anoto de antemano las direcciones IP y los destinos del correo para poder introducirlo todo sin interrupciones. Así evito errores de escritura y coloco las entradas en un orden tranquilo. En cuanto la zona está lista, planifico el cambio de servidores de nombres y las comprobaciones posteriores.
Introduzca correctamente el servidor de nombres con el registrador
Después de crear la zona, introduzco el Servidor de nombres de Hetzner para que la administración esté centralizada en la consola DNS. Las entradas habituales son ns1.first-ns.de, robotns2.second-ns.de y robotns3.second-ns.com. Para los dominios .de o .at, configuro mis propios servidores de nombres con Pegamento-Registrospara que se almacenen las referencias y las IP. Si nunca has hecho esto antes, puedes encontrar los pasos individuales en la guía para Establecer registros de cola. A continuación, me tomo un tiempo para el cambio, ya que la actualización puede llegar a diferentes velocidades en todo el mundo.
Ejemplo de configuración: hacer ejecutables el sitio web y el correo electrónico
Para una presencia web típica utilizo un A-Record para el dominio raíz, un CNAME para www y registros de correo adecuados. Un SPF-TXT impide que servidores externos envíen correos electrónicos en nombre del dominio. Opcionalmente, añado un registro AAAA si el servidor web IPv6 proporciona. Para servicios de correo externos como ForwardMX, personalizo el MX y almaceno sus especificaciones. La siguiente tabla muestra un punto de partida sólido para muchas configuraciones.
| Nombre | Tipo | Valor | Nota |
|---|---|---|---|
| @ | A | 195.201.210.43 | Servidor web IPv4 |
| @ | AAAA | Opcional: 2a01:4f8:xxxx:xxxx::1 | Servidor web IPv6 |
| www | CNAME | @ | Alias en la raíz |
| @ | MX | mx1.forwardmx.net | Prío 10 |
| @ | TXT | "v=spf1 include:_spf.forwardmx.net -all" | SPF contra la suplantación de identidad |
Activar DNSSEC y establecer registro DS
Si la seguridad de la manipulación es importante para mí, activo DNSSEC para la zona. En la consola de Hetzner, genero claves de firma para ello y luego recibo los Datos DSque deposito en el registrador. Compruebo que el algoritmo y el resumen se han transferido correctamente. Luego espero a que la cadena del registrador a la zona se valide correctamente. Antes de las grandes rotaciones de claves, reduzco el TTL y planifico una ventana de tiempo para que los resolvers vean las nuevas firmas a tiempo. Importante: si se produce un error durante el cambio, las validaciones fallan para los destinatarios. Por ello, tengo preparada una reversión (no elimine las claves antiguas demasiado pronto) y hago pruebas con los resolvers de validación.
Establecer TTL correctamente y comprender la propagación
El TTL determina el tiempo que los resolvers almacenan en caché una entrada. Para las conversiones, elijo un TTL (por ejemplo, 300 segundos) para que los cambios sean visibles rápidamente. Tras la configuración final, vuelvo a aumentar los valores para ahorrar peticiones y lograr una resolución coherente. A los que despliegan con frecuencia les gusta quedarse con 600-1200 segundos, mientras que los que rara vez hacen cambios utilizan 3600-14400. Una visión práctica de la decisión me la proporciona mi mirada a los Selección TTL óptima.
Dominio Apex, CAA y certificados bajo control
Para objetivos SaaS en Zona Apex Recuerdo que CNAME no está permitido en @. Por lo tanto, utilizo el A/AAAA del proveedor o establezco una redirección a www a nivel del servidor web. Para la asignación del certificado controlo con Récords de la CAAqué CAs están autorizadas a emitir certificados. Por ejemplo, yo sólo mantengo la CA que realmente utilizo y opcionalmente añado una dirección de correo para los informes. Si cambio la CA, aumento brevemente el TTL y actualizo CAA antes de emitir. Para los comodines a través de ACME DNS-01, me aseguro de que los registros TXT bajo Desafío Acme pueden establecerse rápidamente y limpiarse automáticamente para que no queden retos antiguos.
Crear subdominios y servicios de forma limpia
Para cada subdominio creo un A- o CNAME-dependiendo de si el subdominio apunta directamente a una IP o a un nombre. Ejemplo: blog.ejemplo.de como A-record al blog VM, cdn.ejemplo.de como CNAME a un nombre CDN. Para las API, hago una distinción estricta entre nombres internos y públicos para evitar riesgos. Los nombres estandarizados como api, app, img ayudan al mantenimiento y la supervisión. De este modo, mantengo la zona estructurada y puedo asignar claramente los cambios.
Comodines, SRV y tipos de registro especiales
Utilizo Registros Wildcard (*.ejemplo.de), por ejemplo para configuraciones con capacidad multicliente. Me aseguro de que las entradas exactas siempre tengan prioridad sobre los comodines. Para servicios como SIP, Matrix o Autodiscover, creo Registros SRV y comprueba el formato y las prioridades. Registros TXT con contenido largo (por ejemplo, DKIM de 2048 bits) se dividen en varios segmentos de comillas para que los analizadores sintácticos puedan combinarlos correctamente. Evito los registros SPF múltiples y combino las entradas en un SPF válido para no romper el límite de búsqueda.
Entrega fiable del correo electrónico: SPF, DKIM y DMARC
Para el correo electrónico de confianza, utilizo MX un SPF-TXT limpio que cubra mis sistemas de envío. También activo DKIM en el servicio de correo utilizado y publicar el selector DKIM como TXT en selector._domainkey. Utilizo DMARC para definir cómo manejan los destinatarios los correos que no pasan SPF/DKIM. A menudo empiezo con "p=none", evalúo los informes y más tarde cambio a "quarantine" o "reject". Esta secuencia reduce los riesgos y aumenta gradualmente la calidad de la entrega.
Profundizar en SPF/DKIM/DMARC en la práctica
Mantengo el SPF lo más reducido posible: sólo lo necesario incluir-y nunca más de un SPF por nombre de host. Para respetar el límite de 10 consultas DNS, reduzco las cadenas o utilizo mecanismos IP4/IP6 si son estables. Para Rotación DKIM Opero con dos selectores activos (antiguo/nuevo), publico la nueva clave, cambio el servicio de correo y sólo borro el antiguo al cabo de unos días. Con DMARC Inicialmente establezco direcciones de informes (rua/ruf) y compruebo la alineación (aspf/adkim). Para los subdominios puedo utilizar sp= definir una política separada si envían por separado. De esta forma reacciono a datos de tráfico reales en lugar de a suposiciones.
DNS inverso (PTR) para una entrega de correo limpia
Además de MX, SPF y DKIM, configuré DNS inverso (PTR) para servidores de correo saliente. El PTR de la IP apunta a un nombre de host, que a su vez resuelve correctamente a la misma IP mediante A/AAAA (Combinación de avance/retroceso). Configuro PTR por IP directamente con el propietario de la IP (por ejemplo, en la interfaz del servidor) - no en la gestión de zona del dominio. Utilizo el formato nibble para IPv6. Un PTR adecuado reduce las clasificaciones de spam y ayuda con la reputación. Si el correo se ejecuta a través de un servicio externo, dejo su PTR como está y evito fuentes de remitente mixtas sin personalización SPF.
Errores típicos y soluciones rápidas
Si un dominio no se resuelve, compruebo primero TTLlas entradas del servidor de nombres y la ortografía correcta de los registros. La segunda mirada se dirige al PropagaciónAlgunos resolvers almacenan en caché durante más tiempo, especialmente después de aumentar el TTL. Comparo la resolución utilizando diferentes comprobadores DNS para reconocer las diferencias regionales. En caso de problemas locales, cambio temporalmente a resolvers públicos como 1.1.1.1 u 8.8.8.8. Si el error solo se produce en redes internas, compruebo los resolvers internos y las reglas en las configuraciones de contenedores, Kubernetes o CoreDNS.
Métodos de prueba: dig, nslookup y end-to-end
No sólo compruebo los registros, sino toda la ruta:
- dig A/AAAA/CNAME/MX/TXT: Comprobar respuestas, TTL y autoridad
- dig +traceVéase la cadena de delegación y el comportamiento del servidor de nombres
- Pruebas SMTPComprobar HELO/EHLO, TLS y banner
- HTTPS realCadena de certificados, nombre de host, redireccionamientos
De este modo, también reconozco errores que no son visibles en las respuestas DNS puras, como asignaciones incorrectas de VirtualHost o certificados caducados. Después de hacer cambios, espero al menos un TTL antes de sacar conclusiones definitivas.
Trabaje eficazmente con la consola Hetzner
Agrupo las relacionadas Entradas tiempo, establezco un TTL corto antes de hacer cambios importantes y luego lo publico todo de una vez. Antes de guardar, compruebo de nuevo MX-prioridades, sintaxis SPF y la IP de destino del registro A. Para la administración del servidor y los procesos, las instrucciones compactas en Consejos para robots Hetzner. Después de los despliegues, pruebo http, https y correo con peticiones reales, no sólo a través de ping. Esto me permite reconocer errores que las consultas DNS puras no muestran.
Automatización: API, plantillas y ACME
Ahorro tiempo mediante la automatización. Para los despliegues regulares, utilizo el API de la consola DNS para crear, modificar o eliminar registros. Trabajo con plantillas para patrones recurrentes (por ejemplo, Web + Correo + DMARC) y sólo inserto valores específicos del proyecto. Para Let's Encrypt DNS-01, incluyo un escritor de registros TXT automatizado y lo integro en el flujo de trabajo de renovación. Importante: trato los tokens API como contraseñas, los asigno a proyectos específicos y revoco el acceso cuando ya no son necesarios.
Configuraciones avanzadas: Split-Horizon, CDN y ACME
Separo a los usuarios internos de los externos si es necesario DNS-vistas para que la aplicación interna apunte a IPs privadas y los visitantes a destinos públicos. ¿Debo utilizar un CDNRemito los subdominios al nombre de la CDN a través de CNAME y activo TLS allí. Para los certificados automáticos a través de ACME/Let's Encrypt, establezco opcionalmente desafíos DNS-01 a través de TXT si HTTP-01 no coincide. La automatización es importante aquí para que las renovaciones se lleven a cabo a tiempo. Los registros y las notificaciones ayudan a reconocer los fallos a tiempo.
Patrones de rendimiento y disponibilidad
Aumento la disponibilidad con medios sencillos: Varios Registros A/AAAA (round robin) comparten carga sin servicios adicionales, siempre que los backends sean stateless o compartan sesiones. Durante el mantenimiento, elimino temporalmente IPs individuales y luego vuelvo a subir la entrada. Un TTL demasiado corto puede sobrecargar los resolvers; busco un equilibrio entre la velocidad de respuesta y la tasa de aciertos de la caché. Establezco procesos claros para las conmutaciones por error sin comprobaciones de estado: En caso de fallo, intercambio las entradas, las controlo activamente y las restablezco de nuevo tras la recuperación.
Seguridad e higiene de la zona
Desactivo lo innecesario Transferencias de zona (AXFR) y publicar sólo el NSque tengan verdadera autoridad. Borro regularmente los subdominios antiguos o huérfanos para que no se creen superficies de sombra. En el caso de los IDN, compruebo el Punycode- ortografía para evitar errores tipográficos y de caracteres especiales. El acceso basado en roles en la consola garantiza que sólo las personas adecuadas cambien las zonas. Y de forma bastante pragmática: documento brevemente los cambios en la herramienta de equipo, lo que reduce significativamente las consultas durante la operación.
Estrategia de migración y desmantelamiento
Antes de una mudanza, reduzco el TTL (24-48 horas antes), reflejo todos los Registros en la nueva zona y pruebo la resolución directamente a través de los nuevos servidores de nombres. Sólo cuando todo esté correcto, configuro el Servidor de nombres en el registrador. Tras la delegación, controlo el tráfico y los errores. Si algo va mal, retrocedo de forma controlada o corrijo entradas individuales. Planifico las migraciones de DNSSEC de forma especialmente conservadora y dejo la antigua cadena de firmas en su sitio hasta que la nueva esté colocada de forma segura. Por último, restablezco el TTL a valores compatibles con la producción.
Breve comparación de proveedores en cuanto a rendimiento y flexibilidad
Rendimiento, funciones y Libertad de DNS decidir con qué flexibilidad despliego los proyectos. En la práctica, los grandes hosters ofrecen Tiempos de respuestapero difieren en cuanto a funcionamiento, funciones y asistencia. Evalúo la selección en función del rendimiento, la gama de funciones, la calidad de la ayuda y las opciones de DNS. El siguiente resumen muestra una imagen condensada que me sirve para tomar decisiones. Al final, lo que cuenta es lo que realmente necesita mi proyecto, no la mayor lista de características.
| Proveedor | Actuación | Alcance de las funciones | Apoyo | Flexibilidad DNS | Clasificación |
|---|---|---|---|---|---|
| webhoster.de | Alta | Muy extensa | Top | Máximo | 1 |
| Hetzner | Alta | Amplia | Bien | Alta | 2 |
| Contabo | Medio | Estándar | O. K. | Medio | 3 |
Brevemente resumido
Establecí un Hetzner DNS-zona de forma estructurada: Crear zona, introducir servidor de nombres con registrador, establecer registros principales para web y correo, y luego probar. Con un TTL Acorto los tiempos de cambio y los vuelvo a aumentar tras la finalización para reducir la carga. SPF, DKIM y DMARC refuerzan la entrega y protegen el dominio contra usos indebidos. Mantengo la coherencia de los subdominios y separo los destinos internos de los públicos. Con esta configuración de ejemplo y las comprobaciones diarias, su configuración dns de hetzner sigue siendo fiable, rápida y fácil de mantener.
