DNS
Last updated
Last updated
Domain Name System( DNS) es parte integral de Internet. Por ejemplo, a través de nombres de dominio como o , podemos acceder a los servidores web a los que el proveedor de alojamiento ha asignado una o más direcciones IP específicas. El DNS es un sistema para convertir nombres de ordenadores en direcciones IP y no cuenta con una base de datos central. En resumen, podemos imaginarlo como una biblioteca con muchas guías telefónicas diferentes. La información se distribuye entre miles de servidores de nombres. Los servidores DNS distribuidos globalmente traducen los nombres de dominio a direcciones IP y, por lo tanto, controlan a qué servidor puede acceder un usuario a través de un dominio en particular. Existen varios tipos de servidores DNS que se utilizan en todo el mundo:
Servidor raíz DNS
Servidor de nombres autorizado
Servidor de nombres no autoritativo
Servidor de almacenamiento en caché
Servidor de reenvío
Resolver
Tipo de servidor
Descripción
DNS Root Server
Authoritative Nameserver
Los servidores de nombres autoritativos tienen autoridad sobre una zona específica. Solo responden consultas de su área de responsabilidad, y su información es vinculante. Si un servidor de nombres autoritativo no puede responder la consulta de un cliente, el servidor de nombres raíz asume el control.
Non-authoritative Nameserver
Los servidores de nombres no autoritativos no son responsables de una zona DNS específica. En cambio, recopilan información sobre zonas DNS específicas mediante consultas DNS recursivas o iterativas.
Caching DNS Server
Los servidores DNS almacenan en caché información de otros servidores de nombres durante un periodo específico. El servidor de nombres autorizado determina la duración de este almacenamiento.
Forwarding Server
Los servidores de reenvío realizan solo una función: reenvían consultas DNS a otro servidor DNS.
Resolver
Los solucionadores no son servidores DNS autorizados, sino que realizan la resolución de nombres localmente en la computadora o el enrutador.
El DNS no está cifrado en su mayoría. Por lo tanto, los dispositivos de la red local WLAN y los proveedores de internet pueden acceder y espiar las consultas DNS. Dado que esto supone un riesgo para la privacidad, existen soluciones para el cifrado DNS. Por defecto, los profesionales de seguridad informática utilizan DNS over TLS( DoT) o DNS over HTTPS( DoH) aquí. Además, el protocolo de red DNSCrypttambién cifra el tráfico entre el ordenador y el servidor de nombres.
Sin embargo, el DNS no solo vincula nombres de ordenadores y direcciones IP. También almacena y genera información adicional sobre los servicios asociados a un dominio. Por lo tanto, una consulta DNS también puede utilizarse, por ejemplo, para determinar qué ordenador sirve como servidor de correo electrónico para el dominio en cuestión o cómo se llaman los servidores de nombres del dominio.
Se utilizan diferentes DNS recordspara las consultas DNS, cada una con tareas distintas. Además, existen entradas separadas para distintas funciones, ya que podemos configurar servidores de correo y otros servidores para un dominio.
Registro DNS
Descripción
A
Devuelve una dirección IPv4 del dominio solicitado como resultado.
AAAA
Devuelve una dirección IPv6 del dominio solicitado.
MX
Devuelve los servidores de correo responsables como resultado.
NS
Devuelve los servidores DNS (servidores de nombres) del dominio.
TXT
Este registro puede contener diversa información. Este versátil registro puede utilizarse, por ejemplo, para validar Google Search Console o certificados SSL. Además, se configuran entradas SPF y DMARC para validar el tráfico de correo y protegerlo del spam.
CNAME
Este registro sirve como alias para otro nombre de dominio. Si desea que el dominio www.hackthebox.eu apunte a la misma IP que hackthebox.eu, deberá crear un registro A para hackthebox.eu y un registro CNAME para www.hackthebox.eu.
PTR
El registro PTR funciona al revés (búsqueda inversa). Convierte las direcciones IP en nombres de dominio válidos.
SOA
Proporciona información sobre la zona DNS correspondiente y la dirección de correo electrónico del contacto administrativo.
El SOAregistro se encuentra en el archivo de zona de un dominio y especifica quién es responsable del funcionamiento del dominio y cómo se administra la información DNS del dominio.
Existen muchos tipos de configuración para DNS. Por lo tanto, solo analizaremos los más importantes para ilustrar mejor el principio de funcionamiento desde una perspectiva administrativa. Todos los servidores DNS funcionan con tres tipos de archivos de configuración:
archivos de configuración de DNS local
archivos de zona
archivos de resolución de nombres inversa
named.conf.local
named.conf.options
named.conf.log
Contiene el RFC asociado, donde podemos personalizar el servidor según nuestras necesidades y la estructura de nuestro dominio, con las zonas individuales para cada dominio. El archivo de configuración named.confse divide en varias opciones que controlan el comportamiento del servidor de nombres. Se distingue entre global optionsy zone options.
Las opciones globales son generales y afectan a todas las zonas. Una opción de zona solo afecta a la zona a la que está asignada. Las opciones que no aparecen en named.conf tienen valores predeterminados. Si una opción es global y específica de la zona, esta tiene prioridad.
Un zone filearchivo de texto describe una zona DNS con el formato BIND. En otras palabras, es un punto de delegación en el árbol DNS. El formato BIND es el preferido por la industria y está consolidado en el software de servidor DNS. Un archivo de zona describe una zona completa. Debe contener exactamente un SOAregistro y al menos uno NS. El registro de recursos SOA suele ubicarse al principio del archivo de zona. El objetivo principal de estas reglas globales es mejorar la legibilidad de los archivos de zona. Un error de sintaxis suele inutilizar todo el archivo de zona. El servidor de nombres se comporta como si esta zona no existiera. Responde a las consultas DNS con un SERVFAILmensaje de error.
En resumen, aquí forward recordsse introducen todos los datos según el formato BIND. Esto permite al servidor DNS identificar a qué dominio, nombre de host y rol pertenecen las direcciones IP. En resumen, esta es la guía telefónica donde el servidor DNS busca las direcciones de los dominios.
Para que la dirección IP se resuelva desde Fully Qualified Domain Name( FQDN), el servidor DNS debe tener un archivo de búsqueda inversa. En este archivo, el nombre del equipo (FQDN) se asigna al último octeto de una dirección IP, que corresponde al host correspondiente, mediante un PTRregistro. Los registros PTR son responsables de la traducción inversa de direcciones IP a nombres, como ya se vio en la tabla anterior.
Algunas de las configuraciones que se muestran a continuación provocan estas vulnerabilidades, entre otras. Esto se debe a que el DNS puede ser muy complejo y es muy fácil que se cuelen errores en este servicio, lo que obliga al administrador a sortear el problema hasta encontrar una solución exacta. Esto suele conllevar la liberación de elementos para que partes de la infraestructura funcionen según lo previsto. En estos casos, la funcionalidad tiene mayor prioridad que la seguridad, lo que genera configuraciones incorrectas y vulnerabilidades.
Opción
Descripción
allow-query
Define qué hosts pueden enviar solicitudes al servidor DNS.
allow-recursion
Define qué hosts pueden enviar solicitudes recursivas al servidor DNS.
allow-transfer
Define qué hosts pueden recibir transferencias de zona del servidor DNS.
zone-statistics
Recopila datos estadísticos de zonas.
El footprinting en los servidores DNS se realiza como resultado de las solicitudes que enviamos. Por lo tanto, en primer lugar, se puede consultar al servidor DNS para saber qué otros servidores de nombres se conocen. Esto se hace mediante el registro NS y la especificación del servidor DNS que queremos consultar mediante el @carácter ". Esto se debe a que, si existen otros servidores DNS, también podemos usarlos y consultar los registros. Sin embargo, otros servidores DNS pueden tener una configuración diferente y, además, pueden ser permanentes para otras zonas.
A veces también es posible consultar la versión de un servidor DNS mediante una consulta de clase CHAOS y tipo TXT. Sin embargo, esta entrada debe existir en el servidor DNS.
Podemos usar la opción ANYpara ver todos los registros disponibles. Esto hará que el servidor nos muestre todas las entradas disponibles que esté dispuesto a revelar. Es importante tener en cuenta que no se mostrarán todas las entradas de las zonas.
Zone transferSe refiere a la transferencia de zonas a otro servidor DNS, que generalmente se realiza a través del puerto TCP 53. Este procedimiento se abrevia como Asynchronous Full Transfer Zone( AXFR). Dado que un fallo de DNS suele tener graves consecuencias para una empresa, el archivo de zona se mantiene casi invariablemente idéntico en varios servidores de nombres. Al realizar cambios, debe asegurarse de que todos los servidores tengan los mismos datos. La sincronización entre los servidores involucrados se realiza mediante la transferencia de zona. Mediante una clave secreta rndc-key, que vimos inicialmente en la configuración predeterminada, los servidores se aseguran de comunicarse con su propio servidor maestro o esclavo. La transferencia de zona implica la simple transferencia de archivos o registros y la detección de discrepancias en los conjuntos de datos de los servidores involucrados.
Los datos originales de una zona se almacenan en un servidor DNS, denominado primaryservidor de nombres de la zona. Sin embargo, para aumentar la fiabilidad, simplificar la distribución de la carga o proteger el servidor principal de ataques, en la práctica se instalan uno o más servidores adicionales, denominados secondaryservidores de nombres de la zona. Para algunos Top-Level Domains( TLDs), es obligatorio que los archivos de zona sean Second Level Domainsaccesibles en al menos dos servidores.
Las entradas DNS generalmente solo se crean, modifican o eliminan en el servidor principal. Esto se puede hacer editando manualmente el archivo de zona correspondiente o automáticamente mediante una actualización dinámica desde una base de datos. Un servidor DNS que sirve como fuente directa para sincronizar un archivo de zona se denomina servidor principal. Un servidor DNS que obtiene datos de zona de un servidor principal se denomina servidor secundario. Un servidor principal siempre es un servidor principal, mientras que un servidor secundario puede ser tanto esclavo como principal.
El esclavo obtiene el SOAregistro de la zona correspondiente del maestro a intervalos determinados (el llamado tiempo de actualización, generalmente de una hora) y compara los números de serie. Si el número de serie del registro SOA del maestro es mayor que el del esclavo, los conjuntos de datos ya no coinciden.
Si el administrador usara una subred para la allow-transferopción con fines de prueba o como solución alternativa, o la configurara como [ nombre de host any], todos consultarían el archivo de zona completo en el servidor DNS. Además, se pueden consultar otras zonas, que incluso podrían mostrar direcciones IP y nombres de host internos.
Una opción sería ejecutar un for-loopen Bash que enumere estas entradas y envíe la consulta correspondiente al servidor DNS deseado.
Los servidores raíz del DNS son responsables de los dominios de nivel superior ( TLD). En última instancia, solo se solicitan si el servidor de nombres no responde. Por lo tanto, un servidor raíz es una interfaz central entre los usuarios y el contenido de Internet, ya que vincula el dominio y la dirección IP. La ( ICANN) coordina el trabajo de los servidores de nombres raíz. Existen 13servidores raíz de este tipo en todo el mundo.
El servidor DNS se usa con frecuencia en distribuciones Linux. Su archivo de configuración local ( named.conf) se divide en dos secciones: la sección de opciones para la configuración general y las entradas de zona para cada dominio. Los archivos de configuración local suelen ser:
En este archivo, podemos definir las diferentes zonas. Estas zonas se dividen en archivos individuales, que en la mayoría de los casos están destinados principalmente a un solo dominio. Las excepciones son los ISP y los servidores DNS públicos. Además, existen diversas opciones que amplían o reducen la funcionalidad. Podemos consultarlas en la de Bind9.
Hay muchas maneras de atacar un servidor DNS. Por ejemplo, puede encontrar una lista de vulnerabilidades dirigidas al servidor BIND9 en . Además, SecurityTrails ofrece una breve de los ataques más comunes a servidores DNS.
Los registros individuales Acon los nombres de host también pueden descubrirse mediante un ataque de fuerza bruta. Para ello, necesitamos una lista de posibles nombres de host, que utilizamos para enviar las solicitudes en orden. Estas listas las proporciona, por ejemplo, .
Se pueden usar muchas herramientas diferentes para esto, y la mayoría funcionan de la misma manera. Una de estas herramientas es, por ejemplo, .