Configurar BIND DNS con Debian 12

¿Alguna vez han tenido la necesidad de configurar Bind9 como Servidor DNS Recursivo/Cache y como Servidor DNS Autoritario para su red local? Lo que te demuestro con éste artículo es para que puedas aplicar estas configuraciones.

Servidor DNS Recursivo/Cache

Un DNS Recursivo, tambien conocido como solucionador recursivo, es el que reenvia todas las consultas o solicitudes DNS hacia los Servidores DNS Externos y éstos servidores externos son tres: Servidores DNS RaicesServidores DNS de Primer Nivel (TLD), y Servidores DNS Autoritarios. Un Servidor DNS Recursivo actua como intermediario entre un cliente y un servidor de nombres DNS. Cuando en los Servidores DNS Externos es encontrada la solicitud (Dirección IP) del dominio, el DNS Recursivo envía de regreso al cliente la consulta peticionada.

Un DNS Cache, es un registro en dónde se almacena los sitios web visitados. Cuando un usuario visita un sitio web en el navegador, el cliente (ordenador) realiza la consulta del nombre de dominio que se está solicitando. Si el sitio web (nombre de dominio) consultada ya se encuentra registrada en el Cache del Servidor DNS, éste le regresa inmediatamente la solicitud DNS al cliente; pero si el dominio consultada por el cliente no se encuentra registrada en el Cache, entonces ahí es cuando entra en función del DNS Recursivo hasta que la solicitud DNS es encontrado y enviado de vuelta hacia al Cache del Servidor DNS Local y también hacia al cliente quién realizó la consulta. Todo este proceso sucede en milisegundos. Otro factor importante es que la Cache del DNS también lo mantiene el navegador y el sistema operativo del cliente.

Servidor DNS Autoritario

Un DNS Autoritario, es aquí donde se almacena en múltiples base de datos diferentes tipos de registros DNS (NS, SOA, A, AAAA, MX, TXT, SRV, PTR, etc.). Estas base de datos son zonas directas y reversas de múltiples dominios públicos y/o privados. Este tipo de servidor DNS es el último en ser consultado durante el proceso de un DNS Recursivo cuando el cliente solicita la Dirección IP de un dominio.

Instalación del BIND DNS

Para la instalación del Servidor BIND DNS, debemos ejecutar el siguiente comando:

sudo apt install bind9 bind9-utils

Una vez instalado, podemos verificar su instalación de la siguiente manera:

Habilitar y Activar BIND DNS

Verificamos que el servicio Bind9 esté habilitado y activo.

sysadmin@fwlab:~$ sudo systemctl status bind9.service

[sudo] contraseña para sysadmin:

● named.service - BIND Domain Name Server

    Loaded: loaded (/lib/systemd/system/named.service; enabled; preset: enabled)

    Active: active (running) since Mon 2024-11-18 12:12:31 CST; 1h 19min ago

      Docs: man:named(8)

  Main PID: 1879 (named)

    Status: "running"

     Tasks: 8 (limit: 2303)

    Memory: 42.5M

       CPU: 843ms

    CGroup: /system.slice/named.service

            └─1879 /usr/sbin/named -f -u bind

 

nov 18 12:12:31 fwlab named[1879]: automatic empty zone: B.E.F.IP6.ARPA

nov 18 12:12:31 fwlab named[1879]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA

nov 18 12:12:31 fwlab named[1879]: automatic empty zone: EMPTY.AS112.ARPA

nov 18 12:12:31 fwlab named[1879]: automatic empty zone: HOME.ARPA

nov 18 12:12:31 fwlab named[1879]: automatic empty zone: RESOLVER.ARPA

nov 18 12:12:31 fwlab named[1879]: configuring command channel from '/etc/bind/rndc.key'

nov 18 12:12:31 fwlab named[1879]: command channel listening on 127.0.0.1#953

nov 18 12:12:31 fwlab named[1879]: configuring command channel from '/etc/bind/rndc.key'

nov 18 12:12:31 fwlab named[1879]: command channel listening on ::1#953

nov 18 12:12:31 fwlab systemd[1]: Started named.service - BIND Domain Name Server.

Si el servicio Bind9 no están habilitado ni tampoco activado, se deben ejecutar los siguientes comandos:

sudo systemctl enable bind9.service

sudo systemctl start bind9.service

Configurar BIND como DNS Recursivo/Cache

Para configurar el DNS Recursivo y Cache con BIND DNS, lo primero que deben hacer es conocer la ruta en dónde se almacena todos los archivos de configuración. La ruta es la siguiente: /etc/bind. Dentro de esta ruta, hay que configurar el archivo “named.conf.options” para las opciones de configuración global del servicio dns.

Debido a que en nuestro caso estamos utilizando dos redes: LAN y DMZ, en los parámetros de configuración encontrarán dos ACLs (Listas de Control de Acceso) con sus respectivas redes.

acl lan { 192.168.100.0/24; };

acl dmz { 10.10.10.0/24; };

options {

directory "/var/cache/bind";

dnssec-validation auto;

listen-on { 127.0.0.1; 192.168.100.1; 10.10.10.1; };

listen-on-v6 { none; };

querylog yes;

max-cache-size 512m;

max-cache-ttl 60;

max-ncache-ttl 60;

recursion yes;

allow-recursion { 127.0.0.1; lan; dmz; };

allow-query { 127.0.0.1; lan; dmz; };

forwarders { 1.1.1.1; 1.0.0.1; 8.8.8.8; 8.8.4.4; };

forward first;

pid-file "/run/named/named.pid";

session-keyfile "/run/named/session.key";

managed-keys-directory "/var/cache/bind";

bindkeys-file "/etc/bind/bind.keys";

};

logging {

channel default_log {

 file "/var/log/named/default.log" versions 3 size 20m;

 print-time yes;

 print-category yes;

 print-severity yes;

 severity dynamic;

};

channel queries_log {

 file "/var/log/named/queries.log" versions 3 size 20m;

 print-time yes;

 print-category yes;

 print-severity yes;

 severity dynamic;

};

category default { default_log; };

category queries { queries_log; };

};

Lo que observan arriba, son un montón de parámetros de configuración, incluyendo los canales para los registros, que obviamente ustedes van a tener que cambiarlos en base a sus requerimientos y necesidades. Los parámetros que ustedes van a tener que cambiar son los siguientes:

  • ACL (Lista de Control de Acceso), es decir, el nombre y la red del mismo.
  • Las Direcciones IP por medio de dónde se escucharán todas las peticiones DNS por el puerto 53. (listen-on porte 53 { direcciones ip de su servidor }).
  • Servidores DNS Externos hacia dónde se reenviarán las peticiones DNS recursivamente. (forwarders).
  • Los permisos de recursión y petición DNS en base a su ACL. (allow-recursion y allow-query).
  • El tamaño máximo para el almacenamiento cache. (max-cache-size). Lo sugerible es que sea 512 megabytes o 1024 megabytes (1 gigabyte) pero esto depende mucho de la RAM del servidor.
  • El límite de tiempo para mantener los registros DNS en el Cache. (max-cache-ttl y max-ncache-ttl).

Configurar BIND como DNS Autoritario

Aprovechando la misma ruta del Servidor BIND DNS (/etc/bind), para configurarlo como DNS Autoritario, debemos configurar el archivo “named.conf.local” para crear las zonas y luego más adelante registrar las bases de datos en dichas zonas. Debido a que para éste ejemplo estamos dos redes, es necesario crear dos zonas para cada red (zona directa y zona inversa), en total son cuatros zonas. En dos zonas para la red LAN dispondrán de un dominio llamado “tecniservicios.lan” y en las otras dos zonas para la red DMZ dispondrán de otro dominio llamado “tecniservicios.dmz”.

zone "tecniservicios.lan" {

type master;

file "/var/lib/bind/tecniservicios.lan.db";

allow-update { none; };

allow-transfer { none; };

allow-query { lan; };

};

 

zone "100.168.192.in-addr.arpa" {

type master;

file "/var/lib/bind/192.168.100.db";

allow-update { none; };

allow-transfer { none; };

allow-query { lan; };

};

 

zone "tecniservicios.dmz" {

type master;

file "/var/lib/bind/tecniservicios.dmz.db";

allow-update { none; };

allow-transfer { none; };

allow-query { lan; dmz; };

};

 

zone "10.10.10.in-addr.arpa" {

type master;

file "/var/lib/bind/10.10.10.db";

allow-update { none; };

allow-transfer { none; };

allow-query { lan; dmz; };

};

Si observan detalladamente, las cuatros zonas son de tipo maestro y las bases de datos de las zonas fueron almacenados en el directorio “/var/lib/bind”. Otros detalles que pueden observar es que ninguna de las zonas se permiten actualizar y transferir los registros dns debido a que no tenemos ningún servidor dns secundario de por medio; los servidores dns secundarios son sumamente importantes en caso que se requieran aplicar respaldos de registros dns y esto se le denomina como Cluster DNS. La única política en las zonas que si se permiten son las consultas dns con el parámetro “allow-query”, es decir, se permite las consultas dns para el dominio “tecniservicios.lan” solo para LAN y se permite las consultas dns para el dominio “tecniservicios.dmz” para ambas redes LAN y DMZ.

Registros DNS para el dominio Tecniservicios.lan

Los registros dns para la zona directa del dominio “tecniservicios.lan” almacenados en “/var/lib/bind/tecniservicios.lan.db” son los siguientes:

$ORIGIN tecniservicios.lan.

$TTL 604800

@ IN SOA tecniservicios.lan. root.localhost. (

  2024111801 ; Serial

   604800  ; Refresh

    86400  ; Retry

  2419200  ; Expire

   604800 ) ; Negative Cache TTL

;

@ IN NS ns.tecniservicios.lan.

@ IN A 192.168.100.1

ns IN A 192.168.100.1

fwlab IN A 192.168.100.1

Los registros dns para la zona inversa del dominio “tecniservicios.lan” almacenados en “/var/lib/bind/192.168.100.db” son los siguientes:

$ORIGIN 100.168.192.in-addr.arpa.

$TTL 604800

@ IN SOA tecniservicios.lan. root.localhost. (

  2024111802 ; Serial

   604800  ; Refresh

    86400  ; Retry

  2419200  ; Expire

   604800 ) ; Negative Cache TTL

;

@ IN NS ns.tecniservicios.lan.

1 IN PTR tecniservicios.lan.

1 IN PTR ns.tecniservicios.lan.

1 IN PTR fwlab.tecniservicios.lan.

Registros DNS para el dominio Tecniservicios.dmz

Los registros dns para la zona directa del dominio “tecniservicios.dmz” almacenados en “/var/lib/bind/tecniservicios.dmz.db” son los siguientes:

$ORIGIN tecniservicios.dmz.

$TTL 604800

@ IN SOA tecniservicios.dmz. root.localhost. (

  2024111803 ; Serial

   604800  ; Refresh

    86400  ; Retry

  2419200  ; Expire

   604800 ) ; Negative Cache TTL

;

@ IN NS ns.tecniservicios.dmz.

@ IN A 10.10.10.1

ns IN A 10.10.10.1

fwlab IN A 10.10.10.1

mail IN A 10.10.10.10

@ IN MX 10 mail.tecniservicios.dmz.

@ IN TXT v=spf1 +a +mx +ip4:10.10.10.10 ~all

Los registros dns para la zona inversa del dominio “tecniservicios.dmz” almacenados en “/var/lib/bind/10.10.10.db” son los siguientes:

$ORIGIN 10.10.10.in-addr.arpa.

$TTL 604800

@ IN SOA tecniservicios.dmz. root.localhost. (

  2024111804 ; Serial

   604800  ; Refresh

    86400  ; Retry

  2419200  ; Expire

   604800 ) ; Negative Cache TTL

;

@ IN NS ns.tecniservicios.dmz.

1 IN PTR tecniservicios.dmz.

1 IN PTR ns.tecniservicios.dmz.

1 IN PTR fwlab.tecniservicios.dmz.

10 IN PTR mail.tecniservicios.dmz.

Revisar y Validar las Configuraciones y las Zonas

Después configurar todo y antes de reiniciar el servicio BIND DNS, es importante revisar para validar que las configuraciones y las zonas no tengan ningún tipo de error o un mal configuración de los registros dns. Para ello vamos utilizar y ejecutar los siguientes dos comandos esenciales: 

  1. “named-checkconf” para la revisión de los archivos de configuración “named.conf.options” y “named.conf.local”.
  2. “named-checkzone” para la revisión de los registros dns de cada zona de dominio.

Vamos a proceder con ejecutar el primer comando para la revisión de los archivos de configuración del servidor BIND DNS:

sysadmin@fwlab:~$ sudo named-checkconf /etc/bind/named.conf.options

sysadmin@fwlab:~$ sudo named-checkconf /etc/bind/named.conf.local

Si al ejecutar el comando “named-checkconf” no aparece ninguna salida de mensaje significa que no existe ningún tipo de error y por ende vamos por buen camino. En caso que aparezca alguna una salida de mensaje, pues lo que verá en el mensaje es una indicación detalla del error cometido y que deberá corregir en los archivos de configuración.

Ahora vamos a proceder con ejecutar el segundo comando para la revisión de los registros dns para cada zona de dominio:

sysadmin@fwlab:~$ sudo named-checkzone tecniservicios.lan /var/lib/bind/tecniservicios.lan.db

zone tecniservicios.lan/IN: loaded serial 2024111801

OK

sysadmin@fwlab:~$ sudo named-checkzone 100.168.192.in-addr.arpa /var/lib/bind/192.168.100.db

zone 100.168.192.in-addr.arpa/IN: loaded serial 2024111802

OK

sysadmin@fwlab:~$ sudo named-checkzone tecniservicios.dmz /var/lib/bind/tecniservicios.dmz.db

zone tecniservicios.dmz/IN: loaded serial 2024111803

OK

sysadmin@fwlab:~$ sudo named-checkzone 10.10.10.in-addr.arpa /var/lib/bind/10.10.10.db

zone 10.10.10.in-addr.arpa/IN: loaded serial 2024111804

OK

Como pueden observar, al ejecutar el comando “named-checkzone” nos indica en cada zona que los registros dns fueron cargados correctamente indicándonos el número serial de cada zona y un OK como mensaje que todos están correctamente validados

Diagnósticos DNS

Ahora vamos a proceder con efectuar los diagnósticos para las consultas dns y para ellos podemos hacerlo ya sea con el comando “nslookup” o con el comando “dig”.

A continuación vamos a efectuar los diagnósticos con ambos comandos para consultar los registros NS y A del dominio “tecniservicios.lan”:

sysadmin@fwlab:~$ nslookup

> set q=ns

> tecniservicios.lan

Server:  192.168.100.1

Address: 192.168.100.1#53

 

tecniservicios.lan nameserver = ns.tecniservicios.lan.

> set q=a

> ns.tecniservicios.lan

Server:  192.168.100.1

Address: 192.168.100.1#53

 

Name: ns.tecniservicios.lan

Address: 192.168.100.1

> tecniservicios.lan

Server:  192.168.100.1

Address: 192.168.100.1#53

 

Name: tecniservicios.lan

Address: 192.168.100.1

==========================================================================

sysadmin@fwlab:~$ dig -t ns tecniservicios.lan

 

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> -t ns tecniservicios.lan

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25688

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; COOKIE: b0c062fda248259c01000000673bc2b1b72ffd581d05707d (good)

;; QUESTION SECTION:

;tecniservicios.lan.  IN NS

 

;; ANSWER SECTION:

tecniservicios.lan. 604800 IN NS ns.tecniservicios.lan.

 

;; ADDITIONAL SECTION:

ns.tecniservicios.lan. 604800 IN A 192.168.100.1

 

;; Query time: 0 msec

;; SERVER: 192.168.100.1#53(192.168.100.1) (UDP)

;; WHEN: Mon Nov 18 16:41:53 CST 2024

;; MSG SIZE  rcvd: 108

==========================================================================

sysadmin@fwlab:~$ dig -t a tecniservicios.lan

 

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> -t a tecniservicios.lan

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52834

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; COOKIE: b47916dc11a0adda01000000673bc2b76d9a6c1ccd232268 (good)

;; QUESTION SECTION:

;tecniservicios.lan.  IN A

 

;; ANSWER SECTION:

tecniservicios.lan. 604800 IN A 192.168.100.1

 

;; Query time: 0 msec

;; SERVER: 192.168.100.1#53(192.168.100.1) (UDP)

;; WHEN: Mon Nov 18 16:41:59 CST 2024

;; MSG SIZE  rcvd: 91

A continuación vamos a efectuar los diagnósticos con ambos comandos para consultar el registro PTR del dominio “tecniservicios.lan”:

sysadmin@fwlab:~$ nslookup

> set q=ptr

> 192.168.100.1

Server:  192.168.100.1

Address: 192.168.100.1#53

 

1.100.168.192.in-addr.arpa name = ns.tecniservicios.lan.

1.100.168.192.in-addr.arpa name = fwlab.tecniservicios.lan.

1.100.168.192.in-addr.arpa name = tecniservicios.lan.

==========================================================================

sysadmin@fwlab:~$ dig 1.100.168.192.in-addr.arpa PTR

 

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> 1.100.168.192.in-addr.arpa PTR

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35220

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; COOKIE: 0622a049ca63eaed01000000673bc3f9e2c664cd48c03aa3 (good)

;; QUESTION SECTION:

;1.100.168.192.in-addr.arpa. IN PTR

 

;; ANSWER SECTION:

1.100.168.192.in-addr.arpa. 604800 IN PTR ns.tecniservicios.lan.

1.100.168.192.in-addr.arpa. 604800 IN PTR fwlab.tecniservicios.lan.

1.100.168.192.in-addr.arpa. 604800 IN PTR tecniservicios.lan.

 

;; Query time: 0 msec

;; SERVER: 192.168.100.1#53(192.168.100.1) (UDP)

;; WHEN: Mon Nov 18 16:47:21 CST 2024

;; MSG SIZE  rcvd: 152

A continuación vamos a efectuar los diagnósticos con ambos comandos para consultar los registros NS y A del dominio “tecniservicios.dmz”:

sysadmin@fwlab:~$ nslookup

> set q=ns

> tecniservicios.dmz

Server:  192.168.100.1

Address: 192.168.100.1#53

 

tecniservicios.dmz nameserver = ns.tecniservicios.dmz.

> set q=a

> ns.tecniservicios.dmz

Server:  192.168.100.1

Address: 192.168.100.1#53

 

Name: ns.tecniservicios.dmz

Address: 10.10.10.1

> tecniservicios.dmz

Server:  192.168.100.1

Address: 192.168.100.1#53

 

Name: tecniservicios.dmz

Address: 10.10.10.1

==========================================================================

sysadmin@fwlab:~$ dig -t ns tecniservicios.dmz

 

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> -t ns tecniservicios.dmz

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55105

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; COOKIE: 8539f64860363d4201000000673bc6e2d2a3aff112caef40 (good)

;; QUESTION SECTION:

;tecniservicios.dmz.  IN NS

 

;; ANSWER SECTION:

tecniservicios.dmz. 604800 IN NS ns.tecniservicios.dmz.

 

;; ADDITIONAL SECTION:

ns.tecniservicios.dmz. 604800 IN A 10.10.10.1

 

;; Query time: 0 msec

;; SERVER: 192.168.100.1#53(192.168.100.1) (UDP)

;; WHEN: Mon Nov 18 16:59:46 CST 2024

;; MSG SIZE  rcvd: 108

==========================================================================

sysadmin@fwlab:~$ dig -t a tecniservicios.dmz

 

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> -t a tecniservicios.dmz

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13237

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; COOKIE: f1f2b174c76a731e01000000673bc73d31363c405c2fd8e9 (good)

;; QUESTION SECTION:

;tecniservicios.dmz.  IN A

 

;; ANSWER SECTION:

tecniservicios.dmz. 604800 IN A 10.10.10.1

 

;; Query time: 3 msec

;; SERVER: 192.168.100.1#53(192.168.100.1) (UDP)

;; WHEN: Mon Nov 18 17:01:17 CST 2024

;; MSG SIZE  rcvd: 91

A continuación vamos a efectuar los diagnósticos con ambos comandos para consultar el registro PTR del dominio “tecniservicios.dmz”:

sysadmin@fwlab:~$ nslookup

> set q=ptr

> 10.10.10.1

Server:  192.168.100.1

Address: 192.168.100.1#53

 

1.10.10.10.in-addr.arpa name = tecniservicios.dmz.

1.10.10.10.in-addr.arpa name = ns.tecniservicios.dmz.

1.10.10.10.in-addr.arpa name = fwlab.tecniservicios.dmz.

==========================================================================

sysadmin@fwlab:~$ dig 1.10.10.10.in-addr.arpa PTR

 

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> 1.10.10.10.in-addr.arpa PTR

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20442

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; COOKIE: f435a396848a8a9c01000000673bc81bc4c9205177000763 (good)

;; QUESTION SECTION:

;1.10.10.10.in-addr.arpa. IN PTR

 

;; ANSWER SECTION:

1.10.10.10.in-addr.arpa. 604800 IN PTR ns.tecniservicios.dmz.

1.10.10.10.in-addr.arpa. 604800 IN PTR fwlab.tecniservicios.dmz.

1.10.10.10.in-addr.arpa. 604800 IN PTR tecniservicios.dmz.

 

;; Query time: 3 msec

;; SERVER: 192.168.100.1#53(192.168.100.1) (UDP)

;; WHEN: Mon Nov 18 17:04:59 CST 2024

;; MSG SIZE  rcvd: 149

A continuación vamos a efectuar los diagnósticos con ambos comandos para consultar los registros MX y TXT del dominio “tecniservicios.dmz” y el registro A del sub-dominio “mail.tecniservicios.dmz”:

sysadmin@fwlab:~$ nslookup

> set q=mx

> tecniservicios.dmz

Server:  192.168.100.1

Address: 192.168.100.1#53

 

tecniservicios.dmz mail exchanger = 10 mail.tecniservicios.dmz.

> set q=txt

> tecniservicios.dmz

Server:  192.168.100.1

Address: 192.168.100.1#53

 

tecniservicios.dmz text = "v=spf1" "+a" "+mx" "+ip4:10.10.10.10" "~all"

> set q=a

> mail.tecniservicios.dmz

Server:  192.168.100.1

Address: 192.168.100.1#53

 

Name: mail.tecniservicios.dmz

Address: 10.10.10.10

==========================================================================

sysadmin@fwlab:~$ dig -t mx tecniservicios.dmz

 

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> -t mx tecniservicios.dmz

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60437

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; COOKIE: 1f6694cf96d32ac101000000673bca71953d607b8e357569 (good)

;; QUESTION SECTION:

;tecniservicios.dmz.  IN MX

 

;; ANSWER SECTION:

tecniservicios.dmz. 604800 IN MX 10 mail.tecniservicios.dmz.

 

;; ADDITIONAL SECTION:

mail.tecniservicios.dmz. 604800 IN A 10.10.10.10

 

;; Query time: 0 msec

;; SERVER: 192.168.100.1#53(192.168.100.1) (UDP)

;; WHEN: Mon Nov 18 17:14:57 CST 2024

;; MSG SIZE  rcvd: 112

==========================================================================

sysadmin@fwlab:~$ dig -t txt tecniservicios.dmz

 

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> -t txt tecniservicios.dmz

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41219

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; COOKIE: c287a3f25bf4fefa01000000673bcc65b148f4445d454e8d (good)

;; QUESTION SECTION:

;tecniservicios.dmz.  IN TXT

 

;; ANSWER SECTION:

tecniservicios.dmz. 604800 IN TXT "v=spf1" "+a" "+mx" "+ip4:10.10.10.10" "~all"

 

;; Query time: 0 msec

;; SERVER: 192.168.100.1#53(192.168.100.1) (UDP)

;; WHEN: Mon Nov 18 17:23:17 CST 2024

;; MSG SIZE  rcvd: 123

Ya para finalizar, a continuación vamos a efectuar los diagnósticos con ambos comandos para consultar el registro PTR del sub-dominio “mail.tecniservicios.dmz”:

sysadmin@fwlab:~$ nslookup

> set q=ptr

> 10.10.10.10

Server:  192.168.100.1

Address: 192.168.100.1#53

 

10.10.10.10.in-addr.arpa name = mail.tecniservicios.dmz.

==========================================================================

sysadmin@fwlab:~$ dig 10.10.10.10.in-addr.arpa PTR

 

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> 10.10.10.10.in-addr.arpa PTR

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29220

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; COOKIE: 2b93fbc5a8c35fef01000000673bccaaa957c9c420c9240a (good)

;; QUESTION SECTION:

;10.10.10.10.in-addr.arpa. IN PTR

 

;; ANSWER SECTION:

10.10.10.10.in-addr.arpa. 604800 IN PTR mail.tecniservicios.dmz.

 

;; Query time: 0 msec

;; SERVER: 192.168.100.1#53(192.168.100.1) (UDP)

;; WHEN: Mon Nov 18 17:24:26 CST 2024

;; MSG SIZE  rcvd: 118

Como pueden observar, todos los diagnósticos para las consultas dns de diferentes registros (NS, A, PTR, MX y TXT) para ambos dominios fueron efectuados existosamente y sin problemas.

El siguiente archivo adjunto es una guía similar al post actual que escribí hace un año o dos años atrás cuando efectué la configuración DNS algo similar con Debian 11. Saludos.