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.

Uso de Oracle Cloud Infrastructure DNS para resolver dominios nativos

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 empresa requiere una solución híbrida de sistema de nombres de dominio (DNS) en la nube, y por híbrido aquí significa utilice su propio sistema de DNS Berkeley Internet Name Domain versión 9 (BIND9) además del servicio de DNS de OCI, donde la arquitectura final que buscan crear se muestra 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

En este tutorial, nos centraremos en el manejo de dominios nativos de OCI como oraclevcn.com y oraclecloud.com. En esta sección, dejaremos de resolver dominios personalizados como orastage.com mediante BIND9 y, en su lugar, exploraremos las capacidades de DNS incorporadas de OCI.

Analizaremos los componentes de OCI Private DNS y los elementos clave implicados en el manejo de consultas, que desempeñan un papel crucial en la gestión del tráfico de DNS dentro de las redes privadas de OCI. Usted notará que ya los hemos utilizado en algunas partes de Tutorial 1 y Tutorial 2. Estos componentes son:

Zona DNS privada: contiene datos DNS a los que solo se puede acceder desde una VCN como direcciones IP privadas. Una zona DNS privada tiene capacidades parecidas a una zona de DNS de Internet, pero proporciona respuestas solo a clientes que puedan alcanzarla a través de una VCN. Cada zona pertenece a una única vista.
Vista de DNS privado: una agrupación de zonas privadas, cada vista se puede asociar a un solucionador para controlar cómo se resuelven las consultas DNS. Varias soluciones pueden utilizar una única vista, lo que permite compartir datos de DNS privados en diferentes redes virtuales en la nube. Cada zona solo puede formar parte de una vista.

Por ejemplo, ha creado dos nuevas VCN-A y VCN-B. Por defecto, los recursos de la VCN-A se pueden resolver entre sí sin configuración adicional, porque sus registros se almacenan en la misma zona privada, que está en la VCN-una vista privada. Lo mismo para VCN-B. Sin embargo, si desea que los recursos de VCN-A resuelvan los recursos de VCN-B, debe asociar la vista privada de VCN-B al solucionador de VCN-A. Si desea que los recursos de VCN-B resuelvan los recursos de VCN-A, debe asociar la vista privada de VCN-A al solucionador de VCN-B.
Solucionador de DNS privado: un solucionador de DNS privado dedicado de VCN proporciona respuestas a las consultas de DNS en el siguiente orden: primero comprobará las zonas en las vistas privadas asociadas y, a continuación, en su vista por defecto, comprobando las reglas de reenvío y, por último, mediante DNS de Internet. Básicamente, es el motor que busca respuestas a las consultas de su instancia.

Por ejemplo, en la siguiente captura de pantalla de imagen se muestra una página de resolución de VCN, la secuencia seguida al resolver una consulta desde una instancia de esta VCN será la siguiente:
Reenvío de puntos finales y reglas: los puntos finales de reenvío sirven como conectores entre la VCN de OCI y los solucionadores de DNS externos u otras zonas de DNS. Mediante el uso de reglas de reenvío, puede dirigir consultas DNS específicas a servidores o listeners externos designados en otros solucionadores de VCN, lo que permite arquitecturas DNS de nube híbrida o resolución de varias zonas.
Puntos finales de escucha: estos puntos finales se utilizan para recibir consultas DNS de orígenes externos. Permiten que su infraestructura de DNS de OCI escuche y responda a las solicitudes de DNS entrantes, lo que mejora su capacidad para gestionar consultas de DNS en varias configuraciones de red.

Juntos, estos componentes proporcionan potentes herramientas para gestionar y personalizar DNS en su entorno de OCI.

Al final de este tutorial, comprenderá cómo utilizar estos componentes de OCI DNS para gestionar y resolver consultas de forma eficaz en su entorno en la nube.

Objetivos

El objetivo principal de este tutorial es permitir que el cliente FE-VM (fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com) consulte BE-VM (be-vm.beprivatesubnet.backendvcn.oraclevcn.com) y viceversa, con el listener LSN para responder a todas estas consultas.

Arquitectura final

Nota:

Al crear inicialmente una VCN y una subred, puede especificar etiquetas de DNS para cada instancia informática e iniciarla, puede asignarle un nombre de host. Al final, la instancia Nombre de dominio completo (FQDN) tendrá el siguiente aspecto: <VM-HOSTNAME>.<SUBNET-DNS-Label>.<VCN-DNS-Label>.oraclevcn.com. La especificación de estas etiquetas es opcional, si las deja vacías, se les asignarán nombres aleatorios tomados del nombre del recurso, al igual que FE-VM y BE-VM en este tutorial.

Si solo necesitábamos recursos de OCI para resolvernos unos a otros, aquí no se necesita un listener, ya que esto se puede hacer utilizando solo vistas privadas como se menciona en la sección Visión general. Sin embargo, la razón detrás de la elección de utilizar un listener aquí es también manejar la resolución de DNS desde cualquier otro entorno, como local y otras nubes, y la adición de todas las vistas privadas al solucionador de este listener será suficiente. Esta configuración aborda un caso de uso concreto en el que también puede que necesite otros entornos (locales u otros entornos en la nube) para resolver los recursos de OCI. Sin embargo, esto no está incluido en este tutorial.

Todas las consultas oraclevcn.com y oraclecloud.com se deben reenviar al mismo listener, independientemente de si la consulta proviene de OCI, la red local u otra red de proveedor en la nube, ya que el solucionador para la VCN de LSN manejará todas estas consultas desde vistas privadas.

En este tutorial, no vamos a probar consultas desde entornos locales o de Microsoft Azure, sino solo desde instancias de OCI. Por lo tanto, el siguiente diagrama es solo para fines ilustrativos.

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 de DNS en general.
Asegúrese de completar los dos primeros tutoriales:
1. Configure el sistema de nombres de dominio BIND9 en Oracle Cloud Infrastructure.
2. Implante una alta disponibilidad en el sistema de nombres de dominio BIND9 en Oracle Cloud Infrastructure.
Se necesita una VCN con una subred privada y asociarla al DRG existente. Para obtener más información, consulte Tarea 1.3: Conexión de VCN al DRG.
- LSN-VCN: alojará el listener. Tenga en cuenta que el listener no tiene que estar en una VCN dedicada, pero preferimos hacerlo en este tutorial para separarlo de otros recursos.
En función de los requisitos previos, ya debe haber creado la siguiente arquitectura.

Tarea 1: Configuración de componentes de red como enrutamiento y seguridad

Tarea 1.1: Creación de una red virtual en la nube (LSN-VCN)

Asegúrese de que ya ha creado la VCN de LSN (10.3.0.0/16), que contiene la subred privada de LSN (10.3.0.0/24).

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.
Podemos ver la VCN implantada, actualmente solo tiene una subred privada, así como la tabla de rutas y la lista de seguridad por defecto asociadas.

Tarea 1.2: Configuración del enrutamiento y la seguridad para la VCN de LSN

Esto se debe realizar en el nivel de subred. Navegue a la página VCN y haga clic en LSN-VCN.
Haga clic en la subred privada.
Haga clic en Tabla de rutas, que es una tabla de rutas asignada.
Agregue las siguientes reglas.
- 10.0.0.0/16 - DRG: enrute el tráfico destinado a DNS-VCN al DRG.
- 10.1.0.0/16 - DRG: enrute el tráfico destinado a la VCN de frontend al DRG.
- 10.2.0.0/16 - DRG: enrute el tráfico destinado a la VCN de backend al DRG.
Hagamos la seguridad ahora. Vaya a la página Detalles de subred y haga clic en la lista de seguridad asignada.
Permitir tráfico de entrada: tráfico DNS (TCP/puerto 53 y UDP/puerto 53) desde DNS-VCN, Frontend-VCN y Backend-VCN.
Permita todo el tráfico de salida.

Tarea 1.3: Configuración del enrutamiento y la seguridad para DNS-VCN

Navegue a la página VCN y haga clic en DNS-VCN.
Haga clic en la subred privada.
Haga clic en Tabla de rutas, que es una tabla de rutas asignada.
Agregue las siguientes reglas.
- 10.3.0.0/16 - DRG: enrute el tráfico destinado a LSN-VCN al DRG.
Ya se han agregado las reglas de seguridad necesarias. Para obtener más información, consulte Tutorial 1: Tarea 1.4: Configuración del enrutamiento y la seguridad para DNS-VCN.

Tarea 1.4: Configuración del enrutamiento y la seguridad para la VCN de frontend

Repita los pasos realizados en la tarea 1.3 para la VCN de frontend.

Tarea 1.5: Configuración del enrutamiento y la seguridad para la VCN de backend

Repita los pasos realizados en la tarea 1.3 para la VCN de backend.

Tarea 2: Configuración de componentes de DNS privado de OCI

Tarea 2.1: Adición de vistas privadas al solucionador de VCN de LSN

Vaya a LSN-VCN y haga clic en Solucionador de DNS.
1. Desplácese hacia abajo y haga clic en Vistas privadas asociadas.
2. Haga clic en Gestionar vistas privadas.
3. Seleccione las vistas privadas de DNS-VCN, VCN de frontend y VCN de backend.
4. Haga clic en Guardar cambios.
5. Las vistas privadas se han agregado correctamente.
Actualmente, el solucionador LSN-VCN tiene visibilidad en todos los registros DNS creados en las otras zonas privadas. Por lo tanto, cuando el listener recibe cualquier consulta a los FQDN FE-VM y BE-VM, se resolverá directamente mediante las vistas privadas asociadas.

Tarea 2.2: Configuración del punto final de recepción en el solucionador de VCN de LSN

Vaya a la consola de OCI.
1. En el mismo solucionador, haga clic en Puntos finales.
2. Haga clic en Crear punto final.
3. Nombre: introduzca un nombre para el punto final.
4. Subred: seleccione la subred privada de la VCN de LSN.
5. Tipo de punto final: seleccione Escucha.
6. Dirección IP de recepción: introduzca 10.3.0.6.
7. Haga clic en Crear punto final.
8. El punto final de recepción se ha creado correctamente.

Tarea 2.3: Configuración de la regla de reenvío en el solucionador de VCN de frontend

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. Agregue otra regla con la siguiente información, como se muestra en la captura de pantalla.
4. Haga clic en Guardar cambios.
5. La regla de reenvío se ha creado correctamente.

Tarea 2.4: Configuración de la regla de reenvío en el solucionador 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. Agregue otra regla con la siguiente información, como se muestra en la captura de pantalla.
4. Haga clic en Guardar cambios.
5. La regla de reenvío se ha creado correctamente.
La arquitectura debería verse así.

Tarea 3: Prueba y validación

Supuesto de Prueba 1: FE-VM para consultar el listener para el dominio nativo de BE-VM

La máquina cliente FE-VM debe poder resolver be-vm.beprivatesubnet.backendvcn.oraclevcn.com. La siguiente imagen ilustra el escenario de prueba que pretendemos lograr.
Vaya a la consola de OCI, vaya a la instancia de BE-VM y copie el FQDN interno para utilizarlo en la prueba.
Acceda a FE-VM y realice una prueba de consulta con el servicio OCI Bastion igual que Tutorial 2: Caso de prueba 1: el DNS principal responde a las consultas FE-VM cuando el DNS secundario está caído. Una vez conectado, ejecute las consultas oraclevcn.com de FE-VM a be-vm.beprivatesubnet.backendvcn.oraclevcn.com y valide la configuración. Puede utilizar varios métodos para verificar que la configuración funciona correctamente.
1. Ejecute el comando host.
2. Ejecute el comando ping.
3. Ejecute el comando dig.

Como se muestra en el escenario de prueba, podemos recuperar la dirección IP del dominio nativo BE-VM y el ping funciona con el FQDN, lo que significa que la prueba se realiza correctamente.

Escenario de prueba 2: BE-VM para consultar el listener para el dominio nativo de FE-VM

La máquina cliente BE-VM debe poder resolver fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com. La siguiente imagen ilustra el escenario de prueba que pretendemos lograr.
Vaya a la consola de OCI, vaya a la instancia de FE-VM y copie el FQDN interno para utilizarlo en la prueba.
Acceda a BE-VM y realice una prueba de consulta mediante el servicio OCI Bastion. Una vez conectado, ejecute las consultas oraclevcn.com de BE-VM a fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com y valide la configuración. Puede utilizar varios métodos para verificar que la configuración funciona correctamente.
1. Ejecutar el comando host.
2. Ejecute el comando ping.
3. Ejecute el comando dig.

Como se muestra en el escenario de prueba, podemos recuperar la dirección IP del dominio nativo BE-VM y el ping funciona con el FQDN, lo que significa que la prueba se realiza correctamente.

Pasos Siguientes

En este tutorial, hemos utilizado Vistas privadas de OCI, Reglas y puntos finales de reenvío y Puntos finales de escucha que ofrecen una gestión de DNS flexible y sólida dentro de una red virtual en la nube. Juntos, estos componentes optimizan las operaciones de DNS, garantizando una resolución de nombres eficiente y escalable dentro de los entornos de OCI, especialmente para un escenario de DNS híbrido que incluye entornos integrados multinube y locales.

En el siguiente y último tutorial de esta serie, Agregar seguridad a la arquitectura de DNS mediante el firewall pfSense, mejoraremos la seguridad de nuestra infraestructura de DNS mediante la configuración del firewall de pfSense para inspeccionar y controlar todas las consultas de DNS. Esto incluirá la supervisión y el filtrado de solicitudes tanto para dominios de OCI internos (oraclevcn.com como oraclecloud.com) como para dominios personalizados gestionados en BIND9, como orastage.com.

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

Use Oracle Cloud Infrastructure DNS to Resolve Native Domains

G16582-02