Agrandar
/
¿Qué tiene que ver este flujo de dígitos binarios con el DNS? Nada, en realidad, ¡pero buena suerte para encontrar una foto bonita en algún lugar que sí lo haga!
Santo Heston
comentarios del lector
121
con la participación de 76 carteles, incluido el autor de la historia
Comparte esta historia
Compartir en Facebook
Compartir en Twitter
Compartir en Reddit
Si desea ser un administrador de sistemas o de red de cualquier tipo, existe una tecnología fundamental que realmente necesita comprender: DNS, el sistema de nombres de dominio. Hubo un tiempo en el que un administrador de sistemas sin aspiraciones de administrar servicios accesibles por Internet podría haber sobrevivido sin comprender el DNS, pero ese tiempo ya pasó.
No puede aprender todo lo que hay que saber sobre DNS en un solo artículo. Pero eso no es lo que buscamos hacer hoy; en cambio, queremos brindarle una guía clara y concisa sobre la estructura y el significado de la parte más importante del Sistema de Nombres de Dominio: un archivo de zona, como se ve en BIND, el Demonio de Nombres de Internet de Berkeley.
Archivo de zona de muestra
Agrandar
/
Este archivo de zona de muestra no contiene todos los tipos de registro posibles, pero es un buen comienzo.
Jim Salter
Origen y TTL
Arriba, tenemos un ejemplo pequeño pero completo de un archivo de zona típico; de hecho, es una versión anónima de un archivo de zona de producción en un dominio que administro. Repasemos esto línea por línea.
$ ORIGEN tld. $ TTL 5 millones
Siempre que vea un
$ ORIGEN
línea en un archivo de zona, este es un atajo que le permite a BIND saber que cualquier referencia de nombre de host no terminada que sigue a esa línea debe suponerse que termina en el argumento siguiente
$ ORIGEN
. En este caso, eso es
.tld
—El dominio ficticio de nivel superior para
ejemplo.tld
.
La siguiente línea
$ TTL 5 millones
, declara que las siguientes líneas tendrán un tiempo de vida de cinco minutos. Este valor relativamente corto significa que los solucionadores de DNS remotos solo deben almacenar en caché los registros recuperados de esta zona durante cinco minutos antes de volver a solicitarlos. Si está relativamente seguro de que su DNS para un dominio determinado no cambiará con mucha frecuencia, podría considerar aumentar ese valor para reducir la cantidad de veces que los hosts remotos deben consultar su servidor de nombres, pero tenga en cuenta que un TTL más largo también significa períodos de inactividad más prolongados, cuando debe realizar un cambio en su DNS (o realizar un cambio que lo rompa accidentalmente).
Ambos
$ ORIGEN
y
$ TTL
se pueden definir varias veces en la misma zona; cada vez que los redefine, cambia su valor para cualquier línea debajo de los nuevos valores en el mismo archivo de zona.
Registro SOA
ejemplo EN SOA ns1.example.tld. hostmaster.example.tld. (90; serial 4h; actualizar 15m; reintentar 8h; expirar 4m); TTL de almacenamiento en caché negativo
El primer registro real en nuestro archivo de zona de muestra, o en cualquier archivo de zona normal, es el registro SOA, que nos indica el inicio de autoridad para el dominio. También es fácilmente el tipo de registro más confuso de todo el sistema DNS.
Para cualquier listado de registros, incluido este registro SOA, el primer argumento es el nombre de host al que se aplica el registro; en este caso,
ejemplo
. Recuerda cómo nos preparamos
$ ORIGEN tld
en la primera línea del archivo de zona? Eso significa que este nombre de host no terminado
ejemplo
se expande a
ejemplo.tld
—Por tanto, estamos definiendo la SOA para el FQDN (nombre de dominio completo)
ejemplo.tld.
Nos referimos a este nombre de host
ejemplo
como "sin terminar" porque no termina en un punto. Si quisiéramos pasar por alto el
$ ORIGEN
establecer y hacer referencia a un FQDN directamente, lo terminaríamos con un punto final, por ejemplo,
ejemplo.tld.
sería el FQDN aquí,
con
el punto final.
El siguiente argumento que vemos es
EN
, abreviatura de "Internet". Esta es la clase de récord. Hay otras clases de registros DNS, pero puede seguir fácilmente toda su carrera sin ver una de ellas (como
CH
, for Chaos) en producción. La clase de registro es opcional; si se omite, BIND asumirá que el registro que se especifica es de clase
EN
. Nosotros recomendamos
no
omitiéndolo, sin embargo, no sea que algo cambie y todos sus archivos de zona se rompan repentinamente después de una actualización de BIND.
Los siguientes dos argumentos son FQDN; al menos, lo parecen. El primer FQDN es realmente un FQDN, y debería ser el FQDN del servidor de nombres principal para el dominio en sí; en este caso,
ns1.example.tld.
Tenga en cuenta que usted
pueden
use nombres de host no terminados aquí; por ejemplo, podríamos haber usado
ns1.example
para este argumento, que se habría expandido a
ns1.example.tld.
gracias a nuestro
$ ORIGEN .tld
línea, pero probablemente sea mejor ser explícito aquí.
El segundo FQDN,
hostmaster.example.tld.
, en realidad no es un FQDN. En cambio, es una forma perversa de reescribir una dirección de correo electrónico.
@
es un carácter reservado en los archivos de zona, y el BIND original usa la primera sección de este "FQDN" como la parte de usuario de una dirección de correo electrónico; por lo tanto, esto se traduciría en la dirección
hostmaster@example.tld
. Es
increíblemente
Es común ver esto arruinado en archivos de zona de la vida real; afortunadamente, no importa mucho. No conocemos literalmente a nadie que realmente use esta función de una zona DNS para contactar a alguien.
Continuando, tenemos
de serie
,
actualizar
,
rever
,
expirar
, y
TTL negativo
para la zona entre paréntesis. Tenga en cuenta que los comentarios que ve aquí etiquetándolos no son obligatorios y, en la vida real, rara vez los verá. Preferimos encarecidamente poner estos comentarios en los archivos de la zona de producción para que sea más fácil leerlos, ¡pero a BIND no le importa!
de serie
: Este es un número de serie simple para el archivo de zona, que debe incrementarse cada vez que se cambia el contenido de la zona. Si no actualiza la serie del archivo de la zona, sus cambios en la zona no serán recogidos por los solucionadores de DNS que hayan almacenado previamente en caché los registros de su zona. Este solía ser un formato AAMMDDnn en el pasado, pero ese formato ya no es necesario o, en algunos casos, incluso es compatible. Simplemente inicie sus zonas con serial
1
, incremento a
2
la próxima vez que realice un cambio en la zona, y así sucesivamente.
actualizar
—Después de este período de tiempo, los servidores de nombres secundarios deben consultar al servidor de nombres primario para este registro SOA, para detectar cambios en el número de serie. Si el número de serie se ha incrementado, todos los registros almacenados en caché deben invalidarse y recuperarse nuevamente del servidor de nombres principal.
rever
—Si el servidor de nombres principal no responde a una solicitud SOA, un servidor de nombres secundario debe esperar tanto tiempo antes de intentar consultar de nuevo el servidor de nombres principal.
expirar
—Si el servidor de nombres primario no ha respondido a la solicitud SOA de un servidor de nombres secundario durante este período de tiempo, el servidor de nombres secundario debe dejar de ofrecer la resolución de DNS para el dominio por completo.
TTL de almacenamiento en caché negativo
—Esto controla cuánto tiempo debe almacenarse en caché una respuesta "negativa", por ejemplo, "No tengo el registro que estás pidiendo".
Anuncio publicitario
Una de las áreas más comunes de confusión en el registro SOA es qué efecto
actualizar
,
rever
, y
expirar
los argumentos tienen. Estos argumentos no afectan en absoluto a los resolutores de DNS, solo a los servidores de nombres autorizados secundarios para el dominio. Si no tiene uno o más servidores de nombres secundarios para su dominio, que usan la replicación BIND para recuperar actualizaciones del primario, estos argumentos no tendrán ningún efecto.
Una nota final: las versiones anteriores de BIND requerían que todos estos tiempos fueran en segundos ... incluso cuando el intervalo de tiempo real estaba en días o semanas. BIND9, lanzado hace casi 20 años, en octubre de 2000, admite sufijos de tiempo legibles por humanos como "m" para minutos, "h" para horas y "d" para días.
Por favor
utilice estos sufijos legibles por humanos al escribir archivos de zona; ¡nadie debería tener que usar una calculadora para darse cuenta de que 86,400 segundos es un día!
Registros NS
IN NS ns1.example.tld.IN NS ns2.example.tld.
En estos dos registros, definimos los nombres de host, que son servidores de nombres autorizados para nuestra zona. Una vez más, hemos utilizado FQDN terminados en puntos para estos registros. Una vez más, nosotros
podría
han utilizado nombres de host no terminados
ns1.example
y
ns2.example
—Y confió en nuestro
$ ORIGEN .tld
para expandirlos. Sin embargo, si lo hiciera, la zona sería más confusa y difícil de leer.
Tenga en cuenta que el registro NS especifica
nombres de host
, no direcciones IP. Esta es una fuente común de confusión para los principiantes en DNS, y es importante hacerlo bien. usted
no poder
especifique una dirección IP simple como servidor de nombres para un dominio; es absolutamente necesario especificar un nombre de host aquí.
Por último, tenga en cuenta que no hemos especificado el nombre de dominio en ninguna línea; esto se debe a que lo hemos heredado del
SOA
grabar arriba. Empezamos esa línea con
ejemplo
, que se expande a
ejemplo.tld
. Como no hemos especificado otro nombre de host, estos nuevos
NS
Los registros también se aplican a ese nombre de host de forma predeterminada.
En el mundo real, también puede ver archivos de zona con
$ ORIGIN ejemplo.tld.
, y comenzando la SOA y posiblemente otras líneas con el carácter reservado especial
@
. Cuando veas
@
como un nombre de host en un archivo de zona, eso solo significa que está usando el
$ ORIGEN
sin más calificativos.
Registro (s) MX
EN MX 10 mail.example.tld.
En este dominio simple, tenemos un solo servidor de correo, y es
mail.example.tld.
El registro MX simplemente le dice a cualquiera que quiera enviar un correo electrónico a cualquier dirección en
ejemplo.tld
para realizar su conexión SMTP al nombre de host especificado en este registro.
El argumento anterior:
10
en este caso, es la prioridad numérica del servidor de correo en este registro específico. Los números más bajos significan una prioridad más alta. Cuando hay varios servidores SMTP disponibles para un dominio, verá varios
MX
registros también, cada uno con una prioridad diferente. En teoría, los servidores de correo de mayor prioridad siempre deben probarse primero, y los servidores de correo de menor prioridad solo deben probarse si falla el servidor de mayor prioridad.
Los servidores SMTP que se comportan bien siguen este protocolo, pero los spammers tienden a apuntar deliberadamente a los servidores de correo de menor prioridad en primer lugar, basándose en la teoría de que los servidores de alta prioridad pueden ser puertas de enlace anti-spam, y los servidores de menor prioridad pueden ser los desnudos. , servidor final sin filtrar. Los spammers apestan.
Un registro (s)
EN 127.0.0.1
Los registros A son la parte de un archivo de zona que realmente hace lo que la mayoría de la gente piensa que hace el DNS: tra
ducen un nombre de host a una dirección IPv4 simple. En este caso, este es solo un archivo de muestra, y nuestroA
grabar para
ejemplo.tld
simplemente se resuelve en localhost, según el mismo principio de que los números de teléfono en las películas siempre comienzan con el intercambio
555
. En la vida real, por supuesto, ingresaría la dirección IP del servidor que esperaba que respondiera cuando
ping example.tld
, apunte un navegador web a
https: //example.tld/
, Etcétera.
En este archivo de zona simple, solo tenemos una
A
grabar para
ejemplo.tld
. En la vida real, puede encontrar varios; podría haber varios servidores de puerta de enlace capaces de responder a las solicitudes web de
https: //example.tld/
; y si es así, cada uno obtendría su propio récord A en su propia línea.
Registro (s) TXT
IN TXT "v = spf1 a mx a: mail.example.tld a: www.example.tld? All"
Esta
TXT
, o registro de texto, todavía se encuentra en la sección principal de nuestro archivo de zona, bajo el nombre de host
ejemplo.tld
. Entonces su alcance es todo
ejemplo.tld
dominio. Puedes poner casi cualquier cosa en un
TXT
registro; este específico es un
SPF
registro, formateado para dar información a los servidores de correo sobre qué máquinas están autorizadas a emitir correo en nombre de
ejemplo.tld
.
En este caso, estamos diciendo que estamos usando la versión de formato SPF1. Luego informamos a cualquiera que consulte este registro que cualquier
A
grabar para
ejemplo.tld
está autorizado a enviar correo en su nombre, al igual que cualquier
MX
para el dominio, y finalmente que las direcciones IP asociadas con el
A
registros para
mail.example.tld
y
www.example.tld
están autorizados a enviar correo. Finalmente,
?todos
dice que si cualquier otra máquina dice que quiere enviar correo desde alguna dirección en
ejemplo.tld
, debería estar permitido ... pero debería examinarse más de cerca que los hosts específicamente autorizados.
Nombres de host, subdominios y CNAME debajo de example.tld
$ ORIGIN example.tld.ns1 IN A 127.0.0.2ns2 IN A 127.0.0.3www IN CNAME example.tld.mail IN AAAA :: 1mail IN A 127.0.0.4
Ahora que hemos definido todo lo que necesitamos para el dominio, podemos comenzar a agregar registros para cualquier nombre de host y subdominio.
bajo
ejemplo.tld
sí mismo. Lo primero que hacemos aquí es cambiar nuestro
$ ORIGEN
para
ejemplo.tld.
Nuevamente, observe el último punto final: si lo olvida, las cosas se pondrán realmente extrañas y se rasgará el cabello preguntándose por qué ninguno de sus registros se resuelve correctamente.
Vemos
A
registros aquí para
ns1
,
ns2
, y
correo
. Estas
A
Los registros funcionan de la misma manera que los
A
record para el dominio mismo, le estamos diciendo a BIND a qué dirección IP resolver las solicitudes para ese nombre de host.
También tenemos un
AAAA
grabar para
mail.example.tld.
-
AAAA
los registros son como
A
registros, pero son para resolver IPv6 en lugar de IPv4. Una vez más, hemos elegido en nuestro ejemplo utilizar una dirección de host local. Necesitarás estar familiarizado con
AAAA
registros si espera configurar su propio servidor de correo: ¡Google dejó de estar dispuesto a hablar con servidores de correo sin que el DNS IPv6 funcionara completamente hace unos años!
Anuncio publicitario
El último tipo de registro que vemos aquí es
CNAME
, abreviatura de Canonical Name. Este es un alias: le permite decirle a BIND que siempre resuelva las solicitudes de
CNAME
d host utilizando el registro A o AAAA especificado en el argumento de destino. En este caso,
www EN CNAME example.tld.
significa que la dirección IP para
ejemplo.tld
sí mismo también debe entregarse si alguien pide
www.example.tld.
CNAME
Los discos son útiles, pero son un poco extravagantes. Vale la pena recordar que cada nivel de
CNAME
necesita otra búsqueda de DNS; en este caso, una máquina remota que solicitó resolver
www.example.tld
se le diría "por favor mira hacia arriba
ejemplo.tld.
para encontrar la respuesta ", y luego tendría que emitir un
separar
Solicitud de DNS para el
A
registro asociado con
ejemplo.tld.
Si usted tiene
CNAME
s apuntando a
CNAME
s apuntando a
CNAME
s, introducirá una latencia innecesaria en las solicitudes de sus recursos y su dominio parecerá "lento" y "retrasado" para sus usuarios.
Hay más limitaciones en
CNAME
registros. Recuerda como te dijimos que
MX
y
NS
los registros deben apuntar a nombres de host, no a direcciones IP sin procesar? Más específicamente, deben apuntar directamente a
A
registros, no a
CNAME
registros. Si intentas configurar
MX mail.example.tld.
seguido por
mail.example.tld. CNAME example.tld.
, su archivo de zona se romperá y
MX
los intentos de búsqueda devolverán errores.
Herramientas del oficio
Si está administrando su propio DNS, deberá dominar el uso de herramientas de línea de comandos para consultar su servidor DNS directamente y ver cómo responde a las solicitudes; es difícil estar seguro de si el problema es el DNS o alguna otra cosa con solo poniendo
https: //example.tld/
en un navegador y ver qué sucede.
cavar
you @ box: ~ $ dig @ 127.0.0.1 NS example.tld; << >> DiG 9.16.1-Ubuntu << >> NS example.tld ;; opciones globales: + cmd ;; Tengo respuesta: ;; - >> ENCABEZADO <
Si tiene acceso al subsistema Linux, Mac o Windows para Linux, la mejor herramienta de línea de comandos es
cavar
. Utilizando
cavar
es tan simple como especificar un servidor para consultar, el tipo de registro que desea buscar y el FQDN al que debe estar asociado.
En el ejemplo anterior, le preguntamos al servidor DNS en
127.0.0.1
para mostrarnos a todos
NS
registros asociados con
ejemplo.tld
. Además de las respuestas que queríamos, obtuvimos un montón de información de diagnóstico: el servidor DNS que consultamos no devolvió un
ERROR
cuando se le pregunta, dice que tiene autoridad para el dominio en cuestión, y así sucesivamente.
También puede suministrar un
+ corto
argumento si quieres
cavar
para simplemente callarme y darle la respuesta que está buscando sin todos los diagnósticos detallados:
you @ box: ~ $ dig + short @ 127.0.0.1 NS example.tldns1.example.tld.ns2.example.tld.
Sin embargo, tenga en cuenta que si no hay respuestas disponibles para un
+ corto
consulta, por ejemplo, si escribe el nombre de dominio, no obtendrá ninguna respuesta, incluso si el servidor DNS consultado arrojó un error.
you @ box: ~ $ dig + short @ 127.0.0.1 NS example.tmdyou@box: ~ $
Si quieres averiguar
por qué
no obtuvo una respuesta, tendrá que perder el
+ corto
argumento para averiguarlo.
nslookup
Si no tiene acceso a
cavar
, generalmente puede arreglárselas con
nslookup
. Por lo general, esta es una solución semi-maldita para los usuarios que se sientan en una caja de Windows sin acceso al Subsistema de Windows para Linux, cygwin o alguna otra forma de obtener acceso a herramientas más avanzadas que las que proporciona la CLI de Windows.
nslookup
normalmente se invoca sin argumentos y se consulta en modo interactivo. Aquí hay una sesión de muestra:
C: \> nslookup> servidor 127.0.0.1 Servidor predeterminado: 127.0.0.1 Dirección: 127.0.0.1 # 53> ejemplo.tld Servidor: 127.0.0.1 Dirección: 127.0.0.1 # 53 Respuesta no autorizada: Nombre: ejemplo.tld Dirección: 127.0. 0,1
Configurando
servidor 127.0.0.1
, especificamos a
nslookup
para utilizar esa máquina como servidor DNS para realizar consultas. No tiene que especificar esto; si no lo haces
nslookup
utilizará lo que sea que utilice el sistema de resolución de DNS predeterminado en su máquina.
Después de configurar opcionalmente el
servidor
, puede escribir un nombre de host desnudo en
nslookup
indicador interactivo, y devolverá cualquier
A
o
AAAA
registros que puede encontrar para ese nombre de host.
Si desea consultar el servidor remoto por un tipo diferente de registro, deberá usar un
tipo de conjunto
mando.
> set type = ns> example.tldServer: 127.0.0.1 Dirección: 127.0.0.1 # 53 Respuesta no autorizada: example.tld nameserver = ns1.example.tld.example.tld nameserver = ns2.example.tld Las respuestas autoritativas pueden ser Encontrado en:> set type = mx> example.tldServer: 127.0.0.1 Dirección: 127.0.0.1 # 53 Respuesta no autorizada: example.tld mail exchangeger = 10 mail.example.tld Las respuestas autoritativas se pueden encontrar en: example.tld nameserver = ns2.example.tld.example.tld nameserver = ns1.example.tld.mail.example.tld dirección de Internet = 127.0.0.4> salir
En los ejemplos anteriores, usamos
tipo de conjunto = ns
y
tipo de conjunto = mx
para consultar el servidor DNS remoto para
NS
y
MX
registros para
ejemplo.tld
. Funciona, y obtienes tus respuestas ... pero la sintaxis es complicada, hay menos información de diagnóstico disponible, es mucho menos programable, y si eres como nosotros, probablemente maldecirás lo anticuado una o dos veces antes que tú. ya terminaste.
La forma correcta de salir de
nslookup
El modo interactivo es el comando
Salida
. Con suerte, nunca necesitará buscar información sobre un dominio de nivel superior también denominado
Salida
—O si lo hace, tendrá una herramienta mejor disponible que
nslookup
Cuando tu lo hagas.
Conclusiones
Con suerte, ha aprendido algo valioso hoy sobre cómo funciona el DNS y cómo se almacena su información. Aunque BIND no es la única plataforma de servidor DNS que existe, en particular, los administradores de Windows deberán trabajar con Active Directory DNS, las lecciones aprendidas aquí se aplican casi por igual a todas las plataformas y aplicaciones.
Aunque el formato de almacenamiento puede cambiar algo de un servidor a otro, como un controlador de dominio de Active Directory que literalmente almacena zonas dentro de Active Directory mismo, en lugar de un archivo de texto sin formato, los tipos de registro son universales y el formato al menos casi universal.
Si es un administrador de sistemas en ciernes o un entusiasta que está interesado en ejecutar su propio servidor DNS, le recomiendo que lo haga y utilice la plataforma original cuando lo haga; BIND en Linux o BSD. La carga del sistema de ejecutar un servidor de nombres es casi inexistente en cualquier escala que no sea verdaderamente masiva; una caja Digital Ocean o Linode de $ 5 puede realizar el trabajo perfectamente.
Además de la gran alegría de aprender a administrar estas cosas, también puede encontrar que valora la capacidad de establecer sus TTL absurdamente cortos: la mayoría de los servidores DNS administrados no permiten un TTL de menos de 30 m, y la mayoría intentará predeterminar a TTL de hasta una semana. Esto está bien y es excelente para una zona DNS, que ya está configurada correctamente y no necesita cambiar ... pero si su dirección IP cambia y su DNS necesita cambiar junto con ella, un TTL de cinco minutos es muy, algo muy bueno para tener.
