DNS privado
Cree y gestione zonas privadas del sistema de nombres de dominio (DNS).
Utilice el DNS privado para crear zonas privadas con nombres de dominio que especifique. Puede gestionar completamente las zonas y los registros para proporcionar resolución de nombre de host para aplicaciones que se ejecutan dentro y entre redes virtuales en la nube (VCN) y redes locales u otras redes privadas.
El DNS privado también proporciona resolución de DNS en las redes (por ejemplo, otra VCN dentro de la misma región, entre regiones o en una red externa). El DNS privado se puede gestionar en la consola y la API de DNS de OCI.
Recursos utilizados en el DNS privado
- Zonas de DNS privado: las zonas de DNS privado contienen datos de DNS a los que solo se puede acceder desde una red virtual en la nube (VCN), como direcciones IP privadas. Una zona de DNS privada tiene capacidades parecidas a una zona de DNS de Internet, pero proporciona respuestas solo a clientes que puedan acceder a ella a través de una VCN. Cada zona pertenece a una única vista.
- Registros de zonas de DNS privado: se soportan diferentes tipos de registro para DNS global y privado. Consulte Registros de recursos soportados.
- Vistas de DNS privadas: una vista de DNS privada es una recopilación de zonas privadas. Se puede utilizar el mismo nombre de zona en muchas vistas, pero los nombres de zona de una vista deben ser únicos.
-
Solucionador DNS privado: un resolución DNS privado dedicado a una VCN contiene la configuración que proporciona respuestas a las consultas DNS en la VCN. Las vistas del solucionador deciden la zona y registran los datos aplicables para la resolución. Los puntos finales de solucionador del resolución proporcionan otra entrada y salida además de la entrada por defecto en 169.254.169.254. Para obtener más información, consulte Solucionadores de DNS privados.
- Punto final de solucionador DNS privado: utilice recursos de punto final de solucionador para configurar la entrada y la salida en la VCN. Los puntos finales de solucionador consumen direcciones IP en la subred en la que ha creado el solucionador. Se crea una VNIC correspondiente para cada punto final de solucionador.
- VCN: al crear una VCN, también se crea automáticamente un solucionador dedicado.
- Subred: al crear puntos finales de solucionador, se utiliza una subred de una VCN. Las direcciones IP de la subred se consumen para recibir y reenviar direcciones.
- Grupo de seguridad de red (NSG): si lo desea, puede configurar una lista de grupos de seguridad de red para puntos finales de solucionador. Los NSG controlan el tráfico de entrada y salida hacia y desde el punto final de solucionador.
Consulte Soluciones DNS privadas en la documentación de Networking para obtener más información sobre los recursos de VCN.
Recursos protegidos
Algunos recursos de DNS privado, como las zonas y las vistas, están protegidos. Oracle gestiona automáticamente los recursos protegidos. Puede ver los recursos protegidos, pero la edición es limitada. Todos los solucionadores para VCN concretas están protegidos. Los recursos protegidos no cuentan para límites de servicio ni cuotas.
Vistas por defecto
Cada solucionador para una VCN concreta tiene una vista por defecto protegida. Puede agregar más zonas a la vista predeterminada, pero se aplican restricciones a los nombres de zona para evitar colisiones con zonas protegidas. Si se suprime un solucionador y su vista por defecto contiene zonas que no están protegidas, la vista por defecto se convierte en una vista que no está protegida en lugar de suprimirse. Puede crear y asociar una vista a un solucionador además de la vista por defecto para que sus zonas se puedan resolver en la VCN.
Configuración y resolución
DNS
Puede crear un árbol de dominio completo o parcial. Una vista puede ser utilizada por cualquier cantidad de solucionadores , y puede compartir datos de DNS privado con las VCN de la misma región. Puede utilizar estas zonas para DNS de horizonte dividido, ya que se puede utilizar el mismo nombre de zona en una zona privada y en una zona de Internet. Se pueden servir diferentes respuestas para las consultas públicas y privadas desde una VCN.
La subred para los puntos finales de DNS privados debe ser solo IPv4. La solicitud para crear un punto final de DNS privado en una subred activada para IPv6 no se realiza correctamente.
Agregue reglas para definir la lógica de respuesta de consultas. El único tipo de regla soportado es FORWARD. Esta regla reenvía de forma condicional una consulta a una IP de destino según la IP de cliente o el QNAME de destino. La dirección IP de destino puede ser para una configuración local, una red privada o un punto final de solucionador de recepción en una VCN diferente.
- Cada vista asociada se evalúa en orden. La vista por defecto se evalúa en último lugar si no se incluye explícitamente en la lista.
- Las reglas de solucionador se evalúan en orden.
- La consulta se resuelve en Internet.
Por ejemplo, si un nombre de consulta está incluido en una zona en una vista privada y el nombre no existe en la zona, esta última devuelve una respuesta NXDOMAIN .
VCN
La entrada y salida entre varias VCN o entre VCN y redes locales requiere que haya conexión. Es posible que el establecimiento de una conexión requiera un gateway de intercambio de tráfico local (LPG ) o un gateway de intercambio de tráfico remota (RPG ) entre las VCN. La conexión entre una VCN y las redes locales requiere FastConnect o un túnel IPSec (VPN IPSec).
Las listas de seguridad de VCN y cualquier NSG al que se haga referencia deben permitir el tráfico necesario. El protocolo DHCP debe estar activado para la entrada y salida en la lista de seguridad e incluir la dirección IP del punto final de solucionador correspondiente. Las reglas de seguridad para los puntos finales de recepción deben permitir la entrada de UDP sin conexión en el puerto de destino 53, la salida de UDP sin conexión en el puerto de origen 53 y la entrada de TCP en el puerto de destino 53. Las reglas de seguridad para puntos finales de reenvío deben permitir la salida de UDP sin conexión en el puerto de destino 53, la entrada de UDP sin conexión en el puerto de origen 53 y la salida de TCP en el puerto de destino 53.
Casos de uso
Zonas de DNS personalizadas en una VCN
Las zonas DNS privadas se agrupan en vistas . Todos los solucionadores para VCN concretas tienen una vista por defecto que se crea automáticamente. Para crear una zona de DNS personalizada que se resuelva desde una VCN, cree la zona privada en la vista por defecto del solucionador dedicado o cree la zona en una nueva vista y agréguela a la lista de vistas asociadas del solucionador dedicado. Consulte Centro de ayuda/Configuración de vistas y solucionadores de zonas de DNS privado para obtener una guía de configuración detallada.
Horizonte dividido
Cree zonas privadas con los mismos nombres que los nombres públicos en Internet. A continuación, agregue las zonas a una de las vistas del solucionador de VCN . En la VCN, los nombres se resuelven según la configuración de DNS privado. Los mismos nombres proporcionan diferentes respuestas en función del origen de la solicitud.
Zonas de DNS privado compartidas dentro de una región
Las VCN de una misma región pueden resolver solicitudes de sus respectivas vistas privadas. Por ejemplo, supongamos que desea implantar esta solución con una VCN A y una VCN B. Agregue la vista por defecto del solucionador dedicado de la VCN A a las vistas asociadas del solucionador dedicado de la VCN B. A continuación, agregue la vista por defecto del solucionador dedicado de la VCN B a las vistas asociadas del solucionador dedicado de la VCN A.
La misma zona privada o recopilación de zonas privadas se puede reutilizar en varias VCN. Esta solución puede reducir la duplicación de la configuración de DNS. Cree una vista y agregue una o más zonas privadas a la vista. Para cada VCN, agregue la nueva vista a la lista de vistas asociadas del solucionador dedicado de la VCN. Consulte Centro de ayuda/Configuración de vistas y solucionadores de zonas de DNS privado para obtener una guía de configuración detallada.
Resolución de DNS entre varias VCN
Envíe solicitudes entre las VCN mediante puntos finales de solucionador. Las VCN pueden existir en diferentes regiones. Esta solución requiere un gateway de intercambio de tráfico local o remoto (LPG /RPG ). Para enviar tráfico de la VCN A a la VCN B, agregue un punto final de recepción al solucionador de la VCN B. A continuación, agregue un punto final de reenvío al solucionador dedicado de la VCN A. Cree una regla en el solucionador dedicado de la VCN A que reenvíe el tráfico a través del punto final de reenvío de la VCN A a la dirección del punto final de recepción de la VCN B. Para enviar tráfico en ambas direcciones entre las VCN, agregue un punto final de solucionador de reenvío y de recepción a cada solucionador dedicado y agregue una regla en cada solucionador dedicado. Consulte Crónicas del equipo A/Implementación de DNS privado para obtener una guía de configuración detallada.
Conectividad entre una VCN y servidores de nombres locales
Se pueden enviar solicitudes entre una VCN y servidores de nombres locales en cualquier dirección. Esta solución requiere conectividad entre la VCN y la red local mediante FastConnect o un túnel IPSec (VPN con IPSec). Para enviar tráfico a una VCN, agregue un punto final de recepción a su solucionador dedicado y envíe tráfico a su dirección. Para enviar tráfico desde una VCN, agregue un punto final de reenvío a su solucionador dedicado y una regla que reenvíe el tráfico a través del punto final a la dirección del servidor de nombres local. Consulte Crónicas del equipo A/Implementación de DNS privado para obtener una guía de configuración detallada.
Casos de uso avanzados
Se pueden configurar VCN para más de un caso de uso. Una única VCN podría intercambiar tráfico con otra VCN y estar configurada para conectarse a un servidor de nombres local. El reenvío también se puede encadenar a través de muchas VCN.
Registros de recursos soportados
El servicio Oracle Cloud Infrastructure DNS soporta muchos tipos de registro de recurso. La siguiente lista proporciona una breve explicación del objetivo de cada tipo de registro soportado para DNS privado. Para obtener información sobre el DNS público, consulte Registros de recursos soportados de DNS público. Evite introducir información confidencial al introducir los datos de registro. Los enlaces RFC le permiten obtener información adicional sobre los tipos de registro y la estructura de datos.
Nota sobre RDATA
OCI normaliza todos los RDATA en el formato más legible por la máquina. La presentación devuelta de RDATA puede diferir de la entrada inicial.
Ejemplo:
El RDATA de los tipos de registro CNAME, DNAME y MX puede contener uno o más nombres de dominio absolutos. Si el RDATA especificado para uno de estos tipos de registro no termina en punto para representar la raíz, se agrega el punto.
www.example.com --> www.example.com.
Puede utilizar varias bibliotecas DNS para normalizar RDATA antes de que se introduzca.
| Lenguaje de programación | Biblioteca |
|---|---|
| Go | Biblioteca DNS en Go |
| Java | dnsjava |
| Python | dnspython |
Tipos de registro de recurso de DNS privado
- A
- Se utiliza un registro de dirección para apuntar a un nombre de host en una dirección IPv4. Para obtener más información sobre los registros A, consulte RFC 1035.
- AAAA
- Se utiliza un registro de dirección para apuntar a un nombre de host en una dirección IPv6. Para obtener más información sobre los registros AAAA, consulte RFC 3596.
- CAA
- Un registro de autorización de autoridad de certificación permite a un titular de nombre de dominio especificar una o más autoridades de certificación autorizadas para emitir certificados para ese dominio. Para obtener más información sobre los registros CAA, consulte RFC 6844.
- CNAME
- Un registro de nombre canónico identifica el nombre canónico de un dominio. Para obtener más información sobre los registros CNAME, consulte RFC 1035.
- DNAME
- Un registro de nombre de delegación tiene un comportamiento similar al de un registro CNAME, pero permite asignar un subárbol completo debajo de una etiqueta a otro dominio. Para obtener más información sobre los registros DNAME, consulte RFC 6672.
- MX
- Un registro de intercambio de correo define el servidor de correo que acepta correo para un dominio. Los registros MX deben apuntar a un nombre de host. Los registros MX no deben apuntar a una dirección IP o CNAME. Para obtener más información sobre los registros MX, consulte RFC 1035.
- PTR
- Un registro de puntero inverso asigna una dirección IP a un nombre de host. Este comportamiento es lo contrario de un registro A, que asigna un nombre de host a una dirección IP. Los registros PTR se encuentran normalmente en zonas de DNS inverso. Para obtener más información sobre los registros PTR, consulte RFC 1035.
- SRV
- Un registro de localizador de servicio permite a los administradores utilizar varios servidores para un único dominio. Para obtener más información sobre los registros SRV, consulte RFC 2782.
- TXT
- Un registro de texto contiene texto descriptivo y legible para el usuario, y también puede incluir contenido no legible para usos específicos. Este tipo de registro se suele utilizar para los registros SPF y los registros DKIM que necesitan elementos de texto no legibles para el usuario. Para obtener más información sobre los registros TXT, consulte RFC 1035.
Políticas de IAM necesarias
Para trabajar con un DNS privado, el usuario necesita tener autoridad suficiente (mediante una política de IAM). Los usuarios del grupo Administradores tienen la autoridad necesaria. Si un usuario no está en el grupo de Administradores, una política como esta permite a un grupo específico gestionar DNS privados:
Allow group <GroupName> to manage dns in tenancy where target.dns.scope = 'private'Si no está familiarizado con las políticas, consulte Introducción a las políticas y Políticas comunes. Para obtener más información sobre las políticas de DNS privado, consulte Referencia de políticas de DNS.
Tareas de DNS privadas
Configuración de DNS privado
Tareas de DNS privadas
Tareas de VCN
Para crear una VCN con un solucionador de DNS dedicado, consulte Visión general de redes virtuales y subredes y DNS en su red virtual en la nube para obtener más información.