Cómo realizar una configuración DNS avanzada en Linux

Como pueden atestiguar los lectores de mis artículos anteriores sobre DNS de Desktop Linux, la gestión de DNS de systemd es muy compleja. Sin embargo, si nos tomamos el tiempo para comprender sus complejidades, podemos crear un comportamiento de resolución de DNS detallado para casos de uso especializados.

En resumen, esta entrega comenzará explicando cómo Systemd resuelve las consultas de ruta. A continuación, describiré cómo configurar DNS por enlace. Finalmente, reflexionaré sobre por qué es tan difícil obtener información simple, consistente y procesable sobre este tema.

Todo está en su propio campo.

La última vez mencioné brevemente que en la configuración de systemd-resolve, «~». Es un dominio especial de solo enrutamiento que especifica el enlace «predeterminado» (o dominio global) utilizado para la resolución de DNS. Analicémoslo en detalle.

En el DNS dividido de systemd-resolved, hay dos modos para especificar qué consultas van a qué enlaces/mundos: dominios de búsqueda y dominios de solo ruta. Tanto el dominio de búsqueda como el dominio de solo ruta se configuran con una cadena de dominio como valor (por ejemplo, «linuxinsider.com»). Solo se puede configurar un dominio por enlace/dominio amplio, ya sea solo dominio de enrutamiento o solo dominio de búsqueda (no ambos al mismo tiempo).

Cuando un dominio se envía para consulta, se compara con todos los dominios de búsqueda y dominios de solo ruta con valores configurados (es decir, no nulos).

si (sólo) uno Cuando uno de los valores de dominio de búsqueda/solo ruta configurados se encuentra en el dominio que se está consultando, esto se considera una «coincidencia» y la consulta se enviará a enlaces con dominios de búsqueda/solo ruta coincidentes.

Si hay varios Si el dominio de búsqueda/solo ruta coincide, la consulta se enviará al enlace/global con el dominio de búsqueda/solo ruta más largo.

si no hay Buscar/Solo coincidencias de dominio de enrutamiento, todo Las consultas DNS se envían para enlace y recuperación global.Dado que el objetivo del DNS es que es un sistema descentralizado pero continuo sistema, ellos debería Todos estos le darán la misma respuesta, pero aún así consumirán tiempo y recursos informáticos innecesarios en la consulta.

Los dominios de búsqueda y los dominios de solo ruta funcionan casi de manera idéntica. En mi investigación, no obtuve una respuesta tan clara sobre la diferencia como esperaba.como Artículo de la revista Fedora y Publicación del blog de la Fundación Gnome mostrar, y Páginas man analizadas por systemd Resulta que la principal diferencia está en el manejo de los campos de «etiqueta única».

Para dominios de búsqueda, si está consultando dominios de «etiqueta única» sin el «.» caracteres en, el valor del campo de búsqueda se agregará al ejecutar la consulta. Por ejemplo, si configuramos un dominio de búsqueda para «ejemplo.com» en un enlace y consultamos «correo», la consulta enviada irá a ese enlace y se buscará «correo.ejemplo.com». Por implicación, podemos decir que una consulta de etiqueta única siempre se prueba en todos los dominios de rastreo configurados y, por definición, una consulta de etiqueta única en sí misma no coincidirá con ningún dominio de rastreo o de solo ruta, ya que tienen al menos un » «. entre ellos.

Otra diferencia significativa es cómo se configuran los dominios de búsqueda y los dominios de solo ruta. De forma predeterminada, cada dominio de enlace configurado es un dominio de búsqueda. Agregue un «~» delante del dominio para convertirlo en un dominio de solo enrutamiento.

Esto nos lleva a nuestro amigo «~». Como se mencionó anteriormente, «~». Coincide con cualquier consulta que no coincida con ningún otro dominio de solo ruta o dominio de búsqueda. Tiene sentido cuando lo piensas. Está funcionalmente predeterminado en el sentido de que todos los dominios (excepto las etiquetas individuales) siempre coincidirán, ya que todos tienen «.» entre ellos. Pero esta coincidencia de dominio es siempre más corta que cualquier otra posible ruta/dominio exclusivo de búsqueda. Por tanto, es el valor predeterminado.

La secuencia de consulta y las condiciones de devolución son más complicadas que esto. Si está ansioso por aprenderlo todo, abra la página de manual «resuelta por systemd» vinculada arriba. Pero eso es realmente todo lo que necesitamos para entender systemd-resolved.

Vuelva a montar todas las piezas desmontadas

Ahora estamos listos para aprender sobre el comportamiento de DNS dividido de systemd-resolved.

Para adaptar el ejemplo del artículo de la Fundación Gnome, tomemos el escenario común de conectarnos a una VPN del trabajo. En Linux, las VPN (y otras configuraciones de red) pueden crear interfaces de red virtuales. Su computadora lo ve como cualquier otra interfaz de red (como una tarjeta inalámbrica), pero es virtual (es decir, software en lugar de hardware).Además, el sistema analiza también Trate esta interfaz de red virtual como un enlace. Por tanto, puede tener su propia configuración DNS.

En una VPN de trabajo, es posible que deba consultar los servidores DNS de su red en busca de dominios relacionados con el trabajo a través del túnel VPN. El software VPN de Linux bien implementado se diseñará para realizar las llamadas API resueltas por systemd correctas para configurar sus conexiones en systemd-resolved para cualquier dominio de enrutamiento o de solo búsqueda y cualquier servidor DNS requerido.

Entonces, digamos que el enlace VPN tiene «ecorp.com» como dominio de búsqueda, y digamos que esto es además de una tarjeta inalámbrica con un «~». Solo dominio de enrutamiento. Como resultado, cualquier dominio que consulte «ecorp.com» será dirigido a los servidores DNS configurados en el enlace VPN. Todas las demás consultas de DNS se enviarán al servidor conectado de forma inalámbrica.

Entonces, ¿qué pasa si dejamos «~» atrás? ¿Más allá de nuestra conexión inalámbrica? Las consultas de dominio que contienen «ecorp.com» o consultas de etiqueta única funcionan igual que antes.Sin embargo, se consultará cualquier dominio que no coincida con el dominio de búsqueda para la conexión VPN. todo nexo/global. Esto no es recomendable si no desea que su VPN corporativa vea dónde está navegando.

Archivo de enlace faltante

Aunque establecimos en el artículo anterior de esta serie que si solo deseas anular los servidores DNS proporcionados por el punto de acceso (AP), lo mejor es cambiar la configuración global de systemd-resolved. Sin embargo, puede encontrar situaciones en las que necesite ajustar el comportamiento de DNS en enlaces específicos.

Para ello, recurrimos a systemd-networkd, otro demonio que controla el comportamiento de la red. systemd-networkd maneja todos los dispositivos de red de acuerdo con su propia configuración predeterminada, pero puede proporcionarle instrucciones personalizadas. Si systemd-networkd encuentra un archivo con la convención de nombre de archivo correcta y el contenido del archivo en el directorio /etc/systemd/network, seguirá sus instrucciones.

Además del servidor DNS que desea, todo lo que necesita saber es el nombre de su interfaz de red.Para ver su interfaz, ejecute enlace IP. En la mayoría de las instalaciones de Linux de escritorio, las únicas interfaces que probablemente encontrará son «lo» («loopback», autorreferencial), la interfaz inalámbrica y tal vez la interfaz ethernet.

Nombre de la interfaz existente, cree un archivo para su interfaz (como superusuario) /etc/systemd/red El nombre del archivo termina en «.network». Establezca el contenido como sigue, con algunos ajustes menores.

[Match]
Nombre=interfaz

[Network]
DHCP=sí
Resolución de dominio =Servidor 1
Resolución de dominio =Servidor 2
dominio=~.

[DHCPv4]
Usar DNS=No

[DHCPv6]
Usar DNS=No

Reemplace «interfaz» con el nombre que le dio enlace IP, «servidor1» y «servidor2» y cualquier dirección IP del servidor DNS que desee. Debes declarar un servidor, pero puedes tener hasta tres.

Quiero arrojar algo de luz sobre algunos puntos.

1. Es muy importante habilitar «DHCP». DHCP está habilitado de forma predeterminada si No Hay un archivo «.network» para la interfaz. Sin embargo, una vez que cree este archivo, se desactivará a menos que lo habilite. Esto es importante porque el AP utiliza DHCP para proporcionarle a su computadora una dirección IP en su red. Sin él, su computadora es funcionalmente invisible.

En segundo lugar, es igualmente importante desactivar «UseDNS». Este interruptor determina si su computadora acepta el servidor DNS proporcionado por el AP («Sí») o no («No»). Dado que nuestro objetivo es personalizar el DNS, debemos decirle a AP: «No, gracias, traje mi propio servidor».

Los proyectos «DNS» y «Dominios» funcionan igual que en systemd-resolved.

Después de guardar el archivo, vuelva a cargar systemd-networkd y systemd-resolved para reconfigurarlos. En mi sistema Linux Mint, noté que systemd-networkd no está habilitado de forma predeterminada.Puedes comprobar si está habilitado ejecutando estado systemctl systemd-networkd. Si encuentra que está deshabilitado, ejecute estos comandos con privilegios de superusuario.

systemctl habilita systemd-networkd
systemctl inicia systemd-networkd
systemctl reiniciar systemd-resuelto

De lo contrario, ejecútelos (también como superusuario).

systemctl reiniciar systemd-networkd
systemctl reiniciar systemd-resuelto

El proceso de verificar la configuración es el mismo que cambiar la configuración global de systemd-resolved, así que siga los pasos de mi artículo anterior.

Buscando respuestas en el lugar equivocado

Mi mayor motivación para escribir estos artículos no es sólo enseñar la configuración de DNS, sino también ilustrar la importancia de revisar la información y hacer las cosas de la manera correcta. Hay muchos malos consejos sobre los temas personalizados de DNS de Linux. Aquí hay algunos ejemplos que he encontrado.

cubrir /etc/resolv.conf Luego use los permisos de archivos de Linux para que el archivo sea inmutable. Los métodos de fuerza bruta como este nunca son prudentes. Dado que systemd-resolved todavía se está ejecutando, su sistema está desperdiciando recursos escribiendo archivos inmutables en vano. Es posible que esto tampoco funcione porque muchas distribuciones de Linux pasan consultas a systemd-resolved a través de D-Bus en lugar de consultar al escucha de código auxiliar original a través de /etc/resolv.conf.

Deshabilite systemd-resolved para habilitar /etc/resolv.conf Cree un archivo estático nuevamente y escriba los cambios en él. Por mucho que me gustaría volver a las viejas costumbres, systemd está demasiado arraigado para volver atrás. Además, elementos importantes del sistema dependen de systemd-resolve, por lo que pueden fallar si lo desactivas.

Instale dnsmasq para el almacenamiento en caché de DNS. Esto es innecesario ya que systemd-resolved ya almacena en caché las respuestas DNS. ¿Por qué ocupar espacio en disco y duplicar recursos? Puedo entender que el usuario promedio de Linux no sepa esto, pero ¿puede alguien distribuir este consejo sin saber que es redundante?

Discurso de cierre

A través de este ejercicio, aprendí dos lecciones que vale la pena enfatizar.

Primero, si está buscando una respuesta en línea, compruébela con el manual.Incluso al investigar las fuentes que cité y que fueron evaluadas como creíbles, aún Los comparé con el manual. Las páginas de manual son reales y están preinstaladas, así que ¿por qué no consultarlas?

En segundo lugar, la única forma de verificar verdaderamente su trabajo es leer los registros. Tengo algunas quejas sobre systemd, pero una cosa que hace muy bien es iniciar sesión.Dado que diferentes componentes de systemd se ejecutan como diferentes usuarios del sistema, puede ejecutar Control de registro y especifique los usuarios cuyos registros desea.

Ojalá haya hecho mi trabajo y no sea el único que aprende de esto.

Sugerir un tema