Note:

Este tutorial requiere acceso a Oracle Cloud. Para registrarse para obtener una cuenta gratuita, consulte Introducción a la cuenta gratuita de Oracle Cloud Infrastructure.
Utiliza valores de ejemplo para credenciales, arrendamiento y compartimentos de Oracle Cloud Infrastructure. Al finalizar la práctica, sustituya estos valores por otros específicos de su entorno en la nube.

Implantación de alta disponibilidad en el sistema de nombres de dominio BIND9 en Oracle Cloud Infrastructure

Introducción

OraStage es una empresa líder en el sector energético, especializada en soluciones de energía renovable y tecnologías de energía innovadoras, y anunció la decisión estratégica de migrar sus cargas de trabajo a Oracle Cloud Infrastructure (OCI) para mejorar el rendimiento, la escalabilidad y la seguridad.

Teniendo en cuenta las necesidades y condiciones específicas que OraStage ha descrito, la compañía requiere un sistema de nombres de dominio (DNS) híbrido. La solución en la nube, y por híbrido aquí, significa utilizar su propio sistema DNS Berkeley Internet Name Domain versión 9 (BIND9), además del servicio DNS de OCI, donde se muestra la arquitectura final que buscan crear en la siguiente imagen.

OraStage Requisitos de DNS:

La compañía tiene varios dominios y subdominios internos, todos ellos deben resolverse mediante su DNS BIND9 en OCI, donde OraStage gestionará todas las zonas y registros relacionados. Uno de estos dominios es orastage.com que vamos a utilizar en este tutorial. Por lo tanto, cualquier consulta a orastage.com se debe reenviar a su BIND9.
Todavía necesitan resolver dominios nativos de OCI (oraclevcn.com, oraclecloud.com, etc.) en algunos casos, y esto se hará mediante componentes de DNS privados de OCI: vistas privadas, reenvío de puntos finales y reglas, y recepción de puntos finales.
Todas las consultas deben ser inspeccionadas por una instancia de firewall pfSense.
Para evitar un único punto de fallo, OraStage planea utilizar otro servidor DNS y aprovechar OCI Load Balancer para distribuir consultas entre DNS principal y secundario.

Esta serie de tutoriales le guiará paso a paso para lograr los requisitos descritos anteriormente, creando toda la solución desde cero. Puede navegar fácilmente a cada tutorial desde la siguiente lista:

Tutorial 1: Configuración de DNS BIND9 en OCI. Descubra cómo instalar y configurar BIND9 en una instancia informática, convirtiéndolo en el servidor DNS local para dos entornos de prueba en OCI. Estos entornos constarán de servidores "Frontend" y "Backend", cada uno alojado en una red radial independiente. El servidor BIND9 manejará todas las consultas DNS dirigidas a orastage.com.
Tutorial 2: Implantación de alta disponibilidad en el escenario de DNS BIND9 en OCI. Este tutorial se centra en la adición de un servidor BIND9 secundario y la configuración de un equilibrador de carga de red (NLB) para distribuir el tráfico DNS entre ambos servidores. Las consultas DNS a orastage.com se dirigirán a la IP de NLB, que equilibrará la carga entre los servidores BIND9 principal y secundario. Si un servidor deja de estar disponible, la resolución de DNS continuará sin interrupción del servicio.
Tutorial 3: Uso de OCI DNS para resolver dominios nativos. Centrándonos solo en un caso de uso específico, donde utilizamos componentes de DNS nativos en OCI, en caso de que sea necesario resolver dominios nativos como oraclevcn.com y oraclecloud.com. BIND9 DNS no se utiliza en este tutorial.
Tutorial 4: Adición de seguridad a la arquitectura de DNS mediante el firewall pfSense. Centrarse en la instalación de un firewall pfSense en la VCN de hub en OCI y realizar la configuración de red necesaria para enrutar todo el tráfico de este a oeste, incluidas las consultas DNS (hechas en los tutoriales anteriores) a través del firewall que se va a inspeccionar.

Descripción general

Hoy en día, una infraestructura de DNS fiable y eficiente es crucial para garantizar operaciones de red fluidas. En el primer tutorial: Configuración del sistema de nombres de dominio BIND9 en Oracle Cloud Infrastructure, ya explicamos cómo BIND9, uno de los programas de DNS más utilizados, que proporciona funciones sólidas y flexibilidad para gestionar los servicios de DNS, se puede desplegar y utilizar en OCI. Si bien un único servidor BIND9 puede gestionar las solicitudes DNS de forma eficaz, agregar un segundo servidor BIND9 ofrece numerosas ventajas que mejoran el rendimiento general y la fiabilidad de la red.

Este tutorial le guiará a través del proceso de configuración de un servidor BIND9 secundario y un equilibrador de carga en OCI, destacando las ventajas de esta configuración. Al implementar esto, logrará:

Redundancia: garantizar la disponibilidad continua de los servicios DNS, incluso si el servidor principal falla.
Equilibrio de carga: distribución de carga de consulta de DNS entre servidores, mejora los tiempos de respuesta y reduce el riesgo de sobrecarga.
Distribución geográfica: si es necesario, la colocación de servidores DNS en diferentes ubicaciones puede proporcionar tiempos de respuesta más rápidos para los usuarios globales.
Seguridad mejorada: mitigación de riesgos mediante la separación y protección de servicios de DNS en varios servidores.

Equilibrador de carga de red de OCI

Un equilibrador de carga de red flexible (NLB) de OCI es un servicio que ayuda a distribuir el tráfico entrante entre varios recursos de backend. Esto resulta especialmente útil para gestionar grandes volúmenes de tráfico y garantizar que las aplicaciones sigan estando disponibles y tengan capacidad de respuesta incluso si uno o más servidores fallan.

El equilibrador de carga de red de OCI funciona en la capa 3 y la capa 4 del modelo de interconexión de sistemas abiertos (OSI), gestionando protocolos como el protocolo de control de transmisión (TCP), el protocolo de datagramas de usuario (UDP) y el protocolo de mensajes de control de Internet (ICMP). Al equilibrar la carga de forma eficiente, puede mejorar el rendimiento de la aplicación, proporcionar alta disponibilidad y mejorar la escalabilidad general del sistema. El servicio también ofrece funciones como comprobaciones del sistema para controlar el estado de los servidores backend, lo que garantiza que el tráfico solo se dirija a instancias en buen estado y operativas.

En resumen, un equilibrador de carga de red de OCI desempeña un papel clave en el mantenimiento de la fiabilidad y escalabilidad de las aplicaciones mediante la distribución inteligente del tráfico de red entre varios recursos. Gracias a todas las ventajas que hemos mencionado, agregaremos un equilibrador de carga de red a nuestra configuración para optimizar nuestra solución de DNS.

Objetivos

Despliegue OCI Network Load Balancer y un servidor secundario BIND9 en OCI perfectamente integrado en su red, lo que garantiza una infraestructura de DNS sólida y resistente.
El objetivo principal de este tutorial es permitir que el cliente FE-VM (fe.orastage.com) consulte BE-VM (be.orastage.com) y viceversa, con DNS-NLB distribuyendo solicitudes de cliente entre Primary-DNS (primary-dns.orastage.com) y Secondary-DNS (secondary-dns.orastage.com) para responder a todas las consultas.

Arquitectura final

Requisitos

Acceso a un arrendamiento de OCI y permisos para gestionar la red y los servicios informáticos necesarios.
Conocimientos básicos de enrutamiento y seguridad de red de OCI y sus funcionalidades: red virtual en la nube (VCN), tabla de rutas, gateway de direccionamiento dinámico (DRG), lista de seguridad, bastión y equilibrador de carga de red de OCI.
Conocimientos básicos del servicio OCI Logging.
Conocimientos básicos de Ubuntu Linux y DNS en general.
Asegúrese de completar el primer tutorial: Configuración del sistema de nombres de dominio BIND9 en Oracle Cloud Infrastructure, donde ya debería haber creado la siguiente arquitectura.

Tarea 1: Aprovisionamiento de la instancia de DNS secundaria y configuración de BIND9

Consulte el primer tutorial: Configuración del sistema de nombres de dominio BIND9 en Oracle Cloud Infrastructure, donde la tarea 2 y la tarea 3 muestran la creación y configuración de la instancia Primary-DNS, se deben realizar las mismas tareas para configurar el DNS secundario. Tenga en cuenta la siguiente información:

El nombre de la instancia será DNS secundario.
Residirá en la misma subred que Primary-DNS y se le debe asignar una dirección IP de 10.0.0.20.
Mediante el proceso de configuración, cada vez que se menciona Primary-DNS 10.0.0.10, se debe sustituir por Secondary-DNS 10.0.0.20, un ejemplo es el FQDN para esta instancia debe ser secondary-dns.orastage.com.
Utilice la misma clave SSH.
El mismo bastión de OCI utilizado para acceder al DNS principal también se puede utilizar para acceder al DNS secundario, pero mediante una nueva sesión.
En el archivo /var/lib/bind/db.orastage.com para instancias primarias y secundarias, asegúrese de que todos los siguientes registros estén presentes, de modo que ambos servidores DNS puedan resolverse entre sí, además de las instancias FE-VM y BE-VM.
```
primary-dns                 IN  A       10.0.0.10
secondary-dns               IN  A       10.0.0.20
fe                          IN  A       10.1.0.5
be                          IN  A       10.2.0.5
```

Al final de esta tarea, la arquitectura debe tener el siguiente aspecto:

Tarea 2: Configuración de un equilibrador de carga de red de OCI

Tarea 2.1: Agregar detalles

Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
1. Haga clic en Red.
2. Haga clic en Equilibrador de carga de red.
Haga clic en Create network load balancer.
1. Nombre de equilibrador de carga: introduzca un nombre.
2. Seleccionar tipo de visibilidad: seleccione Privado.
3. Seleccionar red: seleccione DNS-VCN y su subred privada, donde colocaremos el equilibrador de carga de red.
4. Haga clic en Siguiente.

Tarea 2.2: Configuración de un Listener

Un listener es un componente esencial en un equilibrador de carga responsable de recibir un tipo específico de tráfico con determinados puertos (por ejemplo, TCP/port 80, UDP/port 21) y dirigirlo a servidores backend. En este tutorial, queremos que el listener escuche en el puerto 53 (TCP) y (UDP), ya que el DNS utiliza ambos.

Introduzca la siguiente información.
1. Nombre del listener: introduzca un nombre.
2. Especificar el tipo de tráfico que gestiona el listener: seleccione UDP/TCP.
3. Especificar el puerto: introduzca el número de puerto 53.
4. Haga clic en Siguiente.

Tarea 2.3: Selección de un juego de backends

Un juego de backends es una agrupación lógica de servidores backend a los que el equilibrador de carga de red enruta el tráfico. Nuestros servidores backend aquí serán Primary-DNS y Secondary-DNS.

Introduzca la siguiente información.
1. Nombre de juego de backends: introduzca un nombre de juego de backends.
2. Haga clic en Agregar backends.
3. Tipo de backend: seleccione Instancias informáticas.
4. Instancias informáticas IPv4 de backend: seleccione ambos servidores DNS: DNS principal y DNS secundario.
5. Haga clic en Agregar backends.
6. Puede ver que los servidores de backend se agregan al juego.
7. Especificar política de comprobación del sistema: se utiliza una política de comprobación del sistema para verificar la disponibilidad de los servidores backend mediante la realización de solicitudes o el intento de conexiones. El equilibrador de carga de red realiza estas comprobaciones del sistema a intervalos regulares especificados, mediante esta política para controlar continuamente el estado de los servidores backend.
8. Haga clic en Siguiente.

Tarea 2.4: Revisar y crear

Revise todos los detalles y haga clic en Crear equilibrador de carga de red.
Se crea DNS-NLB. Tenga en cuenta la dirección IP privada, ya que la usaremos en la tarea 3.

Tarea 2.5: Adición de una regla de seguridad

Para evitar el fallo de la comprobación de estado y garantizar una comunicación fluida sin interrupciones del tráfico.

Agregue las siguientes reglas en la lista de seguridad DNS-Private-Subnet, lo que permite el tráfico DNS enviado desde el equilibrador de carga de red a sus backends.
La arquitectura debe tener el aspecto que se muestra en la siguiente imagen.

Tarea 3: Configuración de reglas de reenvío de DNS de OCI

Tarea 3.1: Configuración de la regla de reenvío de frontend-VCN

Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
1. Haga clic en Red.
2. Haga clic en Redes virtuales en la nube.
Haga clic en VCN de frontend.
Haga clic en Solucionador de DNS de la VCN.
Desplazar hacia abajo
1. Haga clic en Reglas.
2. Haga clic en Gestionar reglas.
3. Cambie la dirección IP de destino de la dirección IP Primary-DNS a la dirección IP DNS-NLB (10.0.0.110) creada en la tarea 2.
4. Haga clic en Guardar cambios.
5. La dirección IP de destino se cambió correctamente. Por lo tanto, ahora todas las consultas de FE-VM se reenviarán a la dirección IP DNS-NLB, que las distribuirá entre los servidores DNS principal y secundario.

Tarea 3.2: Configuración de la regla de reenvío de VCN de backend

Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
1. Haga clic en Red.
2. Haga clic en Redes virtuales en la nube.
Haga clic en VCN de backend.
Haga clic en Solucionador de DNS de la VCN.
Desplazar hacia abajo.
1. Haga clic en Reglas.
2. Haga clic en Gestionar reglas.
3. Cambie la dirección IP de destino de la dirección IP Primary-DNS a la dirección IP DNS-NLB (10.0.0.110) creada en la tarea 2.
4. Haga clic en Guardar cambios.
5. La dirección IP de destino se cambió correctamente. Por lo tanto, ahora todas las consultas de BE-VM se reenviarán a la dirección IP DNS-NLB, que las distribuirá entre los servidores DNS principal y secundario.

Tarea 4: Prueba y validación

Requisito

Activar logs: para verificar el flujo de tráfico, activaremos los logs de flujo de subred, que nos permiten supervisar y realizar un seguimiento del tráfico de red que entra o sale de una subred específica. Estos logs capturan detalles sobre el tráfico de red, como las direcciones IP de origen y destino, los números de puerto y la cantidad de datos que se transmiten. Para activar el log, siga estos pasos:
1. Vaya a la subred privada DNS-VCN, donde residen Primary-DNS, Secondary-DNS y DNS-NLB.
2. Haga clic en Logs.
3. Seleccione Activar Log.
Para obtener más información sobre los logs y cómo utilizarlos en OCI, consulte
- Logs de flujo de VCN.
- Detalles de los logs de flujo de VCN: aprenda a leer el contenido del log.
- Siga los paquetes de un hub y la arquitectura de enrutamiento de VCN de Spoke dentro de OCI: un tutorial útil para saber cómo rastrear paquetes de red en un entorno de OCI mediante varios métodos, como la captura de paquetes de firewall, los logs de subred y TCPdump. Siga las tareas 6 y 13.
  - Tarea 6: Activar el registro (todos los logs) en la subred privada de Spoke A.
  - Tarea 13: Mire todos los puntos de registro y capturas de paquetes y siga la ruta - Punto de registro B.

Ahora se registrará todo el tráfico de entrada y salida de esta subred.

Escenario de prueba 1: el DNS principal responde a las consultas FE-VM cuando el DNS secundario está caído

En caso de fallo en Secondary-DNS, debemos asegurarnos de que Primary-DNS responda a las consultas procedentes de FE-VM, ya que DNS-NLB está dirigiendo el tráfico a él.

La siguiente imagen ilustra el escenario de prueba que pretendemos lograr.
Actualmente, todas las instancias están activas y en ejecución. Empecemos cerrando la instancia de DNS secundario. Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
1. Haga clic en Calcular.
2. Haga clic en Instancias.
1. Seleccione la casilla de control junto a la instancia.
2. Haga clic en Acciones.
3. Haga clic en Parar.
4. Haga clic en Parar.
5. La instancia ahora tiene el estado Parado.
Acceda a FE-VM y realice una prueba mediante la ejecución de una consulta. Para ello, utilizaremos el servicio OCI Bastion. Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
1. Haga clic en Identidad y seguridad.
2. Haga clic en Bastión.
Haga clic en FEBastion.
Haga clic en Crear sesión.
Introduzca la siguiente información.
1. Tipo de sesión: seleccione Sesión SSH gestionada.
2. Nombre de sesión: introduzca un nombre para la sesión.
3. Usuario: Introduzca el nombre de usuario. Para la instancia de Oracle Linux, el nombre de usuario por defecto es opc.
4. Instancia informática: seleccione la instancia de FE-VM.
5. Pegue la misma clave pública generada en el tutorial 1: Tarea 2.1: Generar par de claves SSH.
6. Haga clic en Crear sesión.

Después de crear la sesión, haga clic en los tres puntos y en el comando Copiar SSH.

El comando se debe parecer al siguiente:

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5aiaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5

Abra OCI Cloud Shell.
1. Navegue al directorio .ssh mediante el comando cd .ssh.
2. Pegue el comando SSH. Asegúrese de sustituir <privateKey> por el nombre de archivo de clave privada id_rsa.
3. Introduzca yes.
Conexión correcta. Ahora, realice una consulta de prueba de FE-VM a be.orastage.com mediante el comando host. Verifique que la consulta se ha realizado correctamente y que se ha recibido una respuesta.
Sabemos que solo hay un servidor backend en buen estado para manejar la solicitud, que es Primary-DNS. Por lo tanto, aquí vamos a verificar el flujo de la consulta de DNS y ver qué servidor respondió a esa consulta mediante los logs de subred de OCI.
1. Haga clic en el log.
2. La solicitud pasó del punto final de reenvío (10.1.0.6), que se coloca en la misma subred que FE-VM, a la dirección IP de NLB (10.0.0.110) en la DNS-VCN.
3. A continuación, desde la dirección IP de NLB (10.0.0.110), la solicitud se envía a Primary-DNS (10.0.0.10).
La prueba se ha realizado correctamente. Primary-DNS ha podido manejar consultas DNS en caso de que Secondary-DNS estuviera caído.

Escenario de prueba 2: el DNS secundario responde a las consultas FE-VM cuando el DNS principal está caído

En caso de fallo en Primary-DNS, debemos asegurarnos de que Secondary-DNS responda a las consultas procedentes de FE-VM, ya que DNS-NLB está dirigiendo el tráfico a él.

La siguiente imagen ilustra el escenario de prueba que pretendemos lograr.
Empecemos cerrando la instancia de Primary-DNS. Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
1. Haga clic en Calcular.
2. Haga clic en Instancias.
1. Seleccione la casilla de control junto a la instancia.
2. Haga clic en Acciones.
3. Haga clic en Parar.
4. Haga clic en Parar.
5. La instancia ahora tiene el estado Parado.
Inicie la instancia de DNS secundario.
1. Seleccione la casilla de control junto a la instancia.
2. Haga clic en Acciones.
3. Haga clic en Start.
4. Haga clic en Start.
5. La instancia ahora tiene el estado En ejecución.
A continuación, accederemos a FE-VM y realizaremos una prueba mediante la ejecución de una consulta. Para ello, utilizaremos el servicio OCI Bastion. Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
1. Haga clic en Identidad y seguridad.
2. Haga clic en Bastión.
Haga clic en FEBastion.
Haga clic en Crear sesión.
Introduzca la siguiente información.
1. Tipo de sesión: seleccione Sesión SSH gestionada.
2. Nombre de sesión: introduzca un nombre para la sesión.
3. Usuario: Introduzca el nombre de usuario. Para la instancia de Oracle Linux, el nombre de usuario por defecto es opc.
4. Instancia informática: seleccione la instancia de FE-VM.
5. Pegue la misma clave pública generada en el tutorial 1: Tarea 2.1: Generar par de claves SSH.
6. Haga clic en Crear sesión.

Después de crear la sesión, haga clic en los tres puntos y en el comando Copiar SSH.

El comando se debe parecer al siguiente:

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5

Abra OCI Cloud Shell.
1. Navegue al directorio .ssh mediante el comando cd .ssh.
2. Pegue el comando SSH. Asegúrese de sustituir <privateKey> por el nombre de archivo de clave privada id_rsa.
3. Introduzca yes.
Conexión correcta. Ahora, realice una consulta de prueba de FE-VM a be.orastage.com mediante el comando host. Verifique que la consulta se ha realizado correctamente y que se ha recibido una respuesta.
Sabemos que solo hay un servidor backend en buen estado para manejar la solicitud, que es DNS secundario. Por lo tanto, aquí vamos a verificar el flujo de la consulta de DNS y ver qué servidor respondió a esa consulta mediante los logs de subred de OCI.
1. Haga clic en el log.
2. La solicitud pasó del punto final de reenvío (10.1.0.6), que se coloca en la misma subred que FE-VM, a la dirección IP de NLB (10.0.0.110) en la DNS-VCN.
3. A continuación, desde el NLB (10.0.0.110), la solicitud se envía a Secondary-DNS (10.0.0.20).
La prueba se ha realizado correctamente. DNS secundario puede manejar consultas DNS en caso de que Primary-DNS esté caído.

Escenario de prueba 3: el DNS principal responde a las consultas de BE-VM cuando el DNS secundario está caído

En caso de fallo en el DNS secundario, debemos asegurarnos de que Primary-DNS responda a las consultas procedentes de BE-VM, ya que DNS-NLB está dirigiendo el tráfico a él.

La siguiente imagen ilustra el escenario de prueba que pretendemos lograr.
Actualmente, todas las instancias están activas y en ejecución. Empecemos cerrando la instancia de DNS secundario. Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
1. Haga clic en Calcular.
2. Haga clic en Instancias.
1. Seleccione la casilla de control junto a la instancia.
2. Haga clic en Acciones.
3. Haga clic en Parar.
4. Haga clic en Parar.
5. La instancia ahora tiene el estado Parado.
A continuación, accederemos a BE-VM y realizaremos una prueba mediante la ejecución de una consulta. Para ello, utilizaremos el servicio OCI Bastion. Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
1. Haga clic en Identidad y seguridad.
2. Haga clic en Bastión.
Haga clic en BEBastion.
Haga clic en Crear sesión.
Introduzca la siguiente información.
1. Tipo de sesión: seleccione Sesión SSH gestionada.
2. Nombre de sesión: introduzca un nombre para la sesión.
3. Usuario: Introduzca el nombre de usuario. Para la instancia de Oracle Linux, el nombre de usuario por defecto es opc.
4. Instancia informática: seleccione la instancia de BE-VM.
5. Pegue la misma clave pública generada en el tutorial 1: Tarea 2.1: Generar par de claves SSH.
6. Haga clic en Crear sesión.

Después de crear la sesión, haga clic en los tres puntos y en el comando Copiar SSH.

El comando se debe parecer al siguiente:

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxuk7pafla@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5

Abra OCI Cloud Shell.
1. Navegue al directorio .ssh mediante el comando cd .ssh.
2. Pegue el comando SSH. Asegúrese de sustituir <privateKey> por el nombre de archivo de clave privada id_rsa.
3. Introduzca yes.
Conexión correcta. Ahora, realice una consulta de prueba de BE-VM a fe.orastage.com mediante el comando host. Verifique que la consulta se ha realizado correctamente y que se ha recibido una respuesta.
Sabemos que solo hay un servidor backend en buen estado para manejar la solicitud, que es Primary-DNS. Por lo tanto, aquí vamos a verificar el flujo de la consulta de DNS y ver qué servidor respondió a esa consulta mediante los logs de subred de OCI.
1. Haga clic en el log.
2. La solicitud pasó del punto final de reenvío (10.2.0.6), que se coloca en la misma subred que BE-VM, a la dirección IP de NLB (10.0.0.110) en la DNS-VCN.
3. A continuación, desde el NLB (10.0.0.110), la solicitud se envía a Primary-DNS (10.0.0.10).
La prueba se ha realizado correctamente. Primary-DNS ha podido manejar consultas DNS en caso de que Secondary-DNS estuviera caído.

Escenario de prueba 4: el DNS secundario responde a las consultas de BE-VM cuando el DNS principal está caído

En caso de fallo en Primary-DNS, debemos asegurarnos de que Secondary-DNS responda a las consultas procedentes de BE-VM, ya que DNS-NLB está dirigiendo el tráfico a él.

La siguiente imagen ilustra el escenario de prueba que pretendemos lograr.
Empecemos cerrando la instancia de Primary-DNS. Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
1. Haga clic en Calcular.
2. Haga clic en Instancias.
1. Seleccione la casilla de control junto a la instancia.
2. Haga clic en Acciones.
3. Haga clic en Parar.
4. Haga clic en Parar.
5. La instancia ahora tiene el estado Parado.
Inicie la instancia de DNS secundario.
1. Seleccione la casilla de control junto a la instancia.
2. Haga clic en Acciones.
3. Haga clic en Start.
4. Haga clic en Start.
5. La instancia ahora tiene el estado En ejecución.
A continuación, accederemos a BE-VM y realizaremos una prueba mediante la ejecución de una consulta. Para ello, utilizaremos el servicio OCI Bastion. Haga clic en el menú de hamburguesa (≡) en la esquina superior izquierda.
1. Haga clic en Identidad y seguridad.
2. Haga clic en Bastión.
Haga clic en BEBastion.
Haga clic en Crear sesión.
Introduzca la siguiente información.
1. Tipo de sesión: seleccione Sesión SSH gestionada.
2. Nombre de sesión: introduzca un nombre para la sesión.
3. Usuario: Introduzca el nombre de usuario. Para la instancia de Oracle Linux, el nombre de usuario por defecto es opc.
4. Instancia informática: seleccione la instancia de BE-VM.
5. Pegue la misma clave pública generada en el tutorial 1: Tarea 2.1: Generar par de claves SSH.
6. Haga clic en Crear sesión.

Después de crear la sesión, haga clic en los tres puntos y en el comando Copiar SSH.

El comando se debe parecer al siguiente:

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5aia73xcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5

Abra OCI Cloud Shell.
1. Navegue al directorio .ssh mediante el comando cd .ssh.
2. Pegue el comando SSH. Asegúrese de sustituir <privateKey> por el nombre de archivo de clave privada id_rsa.
3. Introduzca yes.
Conexión correcta. Ahora, realice una consulta de prueba de BE-VM a fe.orastage.com mediante el comando host. Verifique que la consulta se ha realizado correctamente y que se ha recibido una respuesta.
Sabemos que solo hay un servidor backend en buen estado para manejar la solicitud, que es DNS secundario. Por lo tanto, aquí vamos a verificar el flujo de la consulta de DNS y ver qué servidor respondió a esa consulta mediante los logs de subred de OCI.
1. Haga clic en el log.
2. La solicitud pasó del punto final de reenvío (10.2.0.6), que se coloca en la misma subred que BE-VM, a la dirección IP de NLB (10.0.0.110) en la DNS-VCN.
3. A continuación, desde el NLB (10.0.0.110), la solicitud se envía a Secondary-DNS (10.0.0.20).
La prueba se ha realizado correctamente. DNS secundario pudo manejar consultas DNS en caso de que Primary-DNS estuviera caído.

Pasos Siguientes

En este tutorial, hemos mejorado una sencilla configuración de DNS BIND9 cliente-servidor en OCI mediante la integración de un equilibrador de carga de red de OCI y un servidor DNS secundario para garantizar la disponibilidad continua del servicio en caso de fallo del servidor principal.

Hasta ahora, hemos desarrollado una arquitectura de DNS fiable y de alto rendimiento específicamente para el manejo de consultas de dominio orastage.com. Sin embargo, la compañía OraStage tiene el requisito de resolver también los nombres de dominio nativos de OCI, como oraclevcn.com y oraclecloud.com, y para ello, son necesarios pasos adicionales. En el siguiente tutorial, Uso de OCI DNS para resolver dominios nativos, mostraremos cómo lograr esta configuración.

Agradecimientos

Autor: Anas abdallah (especialista en redes en la nube)

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de formación gratuita en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en un explorador de Oracle Learning.

Para obtener documentación sobre el producto, visite Oracle Help Center.

Título e Información de Copyright

Implement High Availability on BIND9 Domain Name System in Oracle Cloud Infrastructure

G14452-02