DNS Privado
Crie e gerencie zonas DNS (sistema de nomes de domínio privado).
Use zonas de serviço de nome de domínio privado (DNS) para criar zonas privadas com nomes de domínio especificados. Você pode gerenciar totalmente as zonas e os registros para fornecer a resolução hostname para aplicativos em execução dentro e entre redes virtuais na nuvem (VCNs ) e redes locais ou outras redes privadas. O Gerenciamento de Tráfego só está disponível para DNS público e não é suportado em DNS privado.
O DNS privado também fornece resolução de DNS entre redes (por exemplo, outra VCN dentro da mesma região, região cruzada ou rede externa). O DNS privado pode ser gerenciado na API e na Console do OCI DNS.
Recursos usados no DNS privado
- Zonas DNS Privadas: As zonas DNS Privadas contêm dados de DNS acessíveis apenas em uma VCN (Rede Virtual na Nuvem), como endereços IP privados. Uma zona privada de DNS tem recursos semelhantes aos de uma zona de DNS da Internet, mas só fornece respostas para clientes que podem acessá-la por meio de uma VCN. Cada zona pertence a uma única view.
- Registros de Zona DNS Privada: Há suporte para diferentes tipos de registro para DNS global e privado. Consulte Registros de Recursos Suportados.
- Views Privadas de DNS: Uma view privada de DNS é uma coleção de zonas privadas. O mesmo nome de zona pode ser usado em muitas views, mas nomes de zona dentro de uma view devem ser exclusivos.
-
Resolvedor de DNS Privado: Um resolvedor de DNS privado dedicado à VCN contém a configuração que atende às consultas DNS dentro da VCN. As views no resolvedor decidem a zona e os dados de registro aplicáveis para resolução. Os pontos finais no resolvedor fornecem outra entrada e saída além da entrada padrão em 169.254.169.254. Para obter mais informações, consulte Resolvedores de DNS Privado.
- Ponto Final do Resolvedor de DNS Privado: Use recursos de ponto final do resolvedor para configurar a entrada e a saída na VCN. Os pontos finais do resolvedor consomem endereços IP na sub-rede na qual você os cria. Uma VNIC correspondente é criada para cada ponto final do resolvedor.
- VCN: Quando você cria uma VCN, um resolvedor dedicado também é criado automaticamente.
- Sub-rede: Uma sub-rede dentro de uma VCN é usada ao criar pontos finais do resolvedor. Os endereços IP da sub-rede são consumidos para ouvir e encaminhar endereços.
- NSG (Grupo de Segurança de Rede): Opcionalmente, você pode configurar uma lista de grupos de segurança de rede para pontos finais do resolvedor. Os NSGs controlam o tráfego de entrada e saída de/para o ponto final do resolvedor.
Consulte Resolvedores de DNS privado na documentação de Rede para obter mais informações sobre os recursos de VCN.
Recursos Protegidos
- Todos os resolvedores dedicados à VCN
- Views Padrão: cada resolvedor dedicado à VCN tem uma view padrão protegida. Você pode adicionar mais zonas à view padrão, mas as restrições se aplicam aos nomes de zonas para evitar colisões com zonas protegidas. Se um resolvedor for excluído e sua view padrão contiver zonas que não são protegidas, a view padrão será convertida em uma view que não é protegida em vez de ser excluída. Você pode criar e anexar uma view a um resolvedor, além da view padrão, para que suas zonas possam ser resolvidas na VCN.
Configuração e Resolução
DNS
Você pode criar uma árvore de domínio completa ou parcial. Uma view pode ser usada por qualquer número de resolvedores e compartilhar dados de DNS privado entre VCNs dentro da mesma região. Você pode usar essas zonas para o DNS split-horizon porque o mesmo nome de zona pode ser usado em uma zona privada e uma zona de internet. Respostas diferentes podem ser fornecidas para consultas públicas e consultas privadas de uma VCN.
A sub-rede para pontos finais de DNS privados deve ser somente IPv4. Uma solicitação para criar um ponto final DNS privado em uma sub-rede ativada para IPv6 não é bem-sucedida.
Adicione regras para definir a lógica de resposta às consultas. O único tipo de regra suportado é FORWARD. Essa regra encaminha condicionalmente uma consulta para um IP de destino com base no IP do cliente ou no QNAME de destino. O endereço IP de destino pode ser para uma configuração on-premises, uma rede privada ou um ponto final do resolvedor de listening em outra VCN. A regra do resolvedor qnameCoverConditions abrange correspondências exatas e também subdomínios.
- Cada exibição anexada é avaliada de modo ordenado. A exibição padrão é avaliada por último, se não for explicitamente incluída na lista.
- As Regras de Resolvedor são avaliadas de modo ordenado. A primeira regra do resolvedor que corresponde à view é aplicada. Qualquer regra mais abaixo da lista com condições duplicadas (incluindo nenhuma condição) para uma anterior nunca é avaliada. Um exemplo de uma regra inacessível é um qnameCoverCondition ou clientAddressConditions mais específico após um mais geral; se a regra mais geral for uma correspondência, a regra mais específica nunca será avaliada.
- A consulta é resolvida para a internet.
Por exemplo, se um nome de consulta for incluído por uma zona em uma view privada e o nome não existir na zona, a zona retornará uma resposta NXDOMAIN confirmativa.
VCN
A entrada e a saída entre VCNs ou entre VCNs e redes on-premises exigem conectividade. O estabelecimento de uma conexão pode exigir um LPG (gateway de pareamento local ) ou um RPG (gateway de pareamento remoto ) entre VCNs. A conexão entre uma VCN e redes on-premises requer FastConnect ou um túnel IPSec VPN IPSec .
As listas de segurança da VCN e todos os NSGs referenciados precisam permitir o tráfego obrigatório. O DHCP na lista de segurança precisa estar ativado para entrada e saída e incluir o endereço IP do ponto final do resolvedor correspondente. As regras de segurança para pontos finais de listening precisam permitir a entrada UDP sem conexão na porta de destino 53, a saída UDP sem conexão na porta de origem 53 e a entrada TCP na porta de destino 53. As regras de segurança para encaminhar pontos finais precisam permitir saída UDP sem conexão na porta de destino 53, entrada UDP sem conexão na porta de origem 53 e saída TCP na porta de destino 53.
Casos de Uso
Zonas DNS Personalizadas em uma VCN
As zonas DNS privadas são agrupadas em views. Todos os resolvedores dedicados da VCN têm uma view padrão que é criada automaticamente. Para criar uma zona DNS personalizada que seja resolvida de dentro de uma VCN, crie a zona privada na view padrão do resolvedor dedicado ou crie a zona em uma nova view e adicione-a à lista de views anexadas do resolvedor dedicado. Consulte Central de Ajuda/Configurar resolvedores e views das zonas DNS privadas para obter um guia detalhado sobre como fazer a configuração.
Omissão de Rotas
Crie zonas privadas com os nomes semelhantes aos nomes públicos na internet. Em seguida, adicione as zonas a uma das views do resolvedor da VCN . Dentro da VCN, os nomes são resolvidos com base na configuração de DNS privado. Os mesmos nomes atendem a respostas distintas, dependendo de onde a solicitação se origina.
Zonas DNS Privadas Compartilhadas dentro de uma Região
As VCNs dentro da mesma região podem resolver solicitações das views privadas umas das outras. Por exemplo, digamos que você queira implementar essa solução com a VCN A e a VCN B. Adicione a view padrão do resolvedor dedicado da VCN A às views anexadas do resolvedor dedicado da VCN B. Em seguida, adicione a view padrão do resolvedor dedicado da VCN B às views anexadas do resolvedor dedicado da VCN A.
A mesma zona privada ou coleção de zonas privadas pode ser reutilizada em várias VCNs. Esta solução pode reduzir a duplicação de configuração de DNS. Crie uma view e adicione uma ou mais zonas privadas a ela. Para cada VCN, adicione a nova view à lista de views anexadas do resolvedor dedicado da VCN. Consulte Central de Ajuda/Configurar resolvedores e views das zonas DNS privadas para obter um guia detalhado sobre como fazer a configuração.
Resolução de DNS entre VCNs
Envie solicitações entre as VCNs usando pontos finais do resolvedor. As VCNs podem existir em diversas regiões. Esta solução requer um LPG ou RPG (gateway de pareamento local /remoto ). Para enviar tráfego da VCN A para a VCN B, adicione um ponto final de listening ao resolvedor da VCN B. Em seguida, adicione um ponto final de encaminhamento ao resolvedor dedicado da VCN A. Crie uma regra no resolvedor dedicado da VCN A que encaminhe o tráfego por meio do ponto final de encaminhamento da VCN A para o endereço do ponto final de listening da VCN B. Para enviar tráfego nas duas direções entre as VCNs, adicione um ponto final do resolvedor de encaminhamento e listening para cada resolvedor dedicado e adicione uma regra em cada resolvedor dedicado. Consulte o blog A-Team Chronicles/Private DNS Implementation para obter um guia detalhado sobre como fazer essa configuração.
Conectividade entre uma VCN e Servidores de Nomes On-Premises
As solicitações podem ser enviadas entre uma VCN e servidores de nomes on-premises em qualquer direção. Esta solução requer conectividade entre a VCN e a rede on-premises usando FastConnect ou um túnel IPSec (IPSec VPN). Para enviar tráfego para uma VCN, adicione um ponto final de listening ao seu resolvedor dedicado e envie o tráfego para seu endereço. Para enviar tráfego de uma VCN, adicione um ponto final de encaminhamento ao seu resolvedor dedicado e uma regra que encaminhe o tráfego pelo ponto final para o endereço do servidor de nomes on-premises. Consulte o blog A-Team Chronicles/Private DNS Implementation para obter um guia detalhado sobre como fazer essa configuração.
Casos de Uso Avançados
As VCNs podem ser configuradas para mais de um caso de uso. Uma única VCN pode ser pareada com outra VCN e configurada para estabelecer conexão com um servidor de nomes on-premises. O encaminhamento também pode ser encadeado por muitas VCNs.
Registros de Recursos Suportados
O serviço Oracle Cloud Infrastructure DNS suporta muitos tipos de registro de recursos. A lista a seguir fornece uma breve explicação da finalidade de cada tipo de registro suportado para o DNS privado. Para DNS público, consulte Registros de Recursos Suportados por DNS Público. Evite digitar informações confidenciais ao inserir dados do registro. Os links da RFC direcionam você para mais informações sobre os tipos de registro e a estrutura de dados.
Observação sobre RDATA
O OCI normaliza todos os RDATA no formato mais legível por máquina. A apresentação retornada de RDATA pode ser diferente de sua entrada inicial.
Exemplo:
Os RDATA para os tipos de registro CNAME, DNAME e MX podem conter um ou mais nomes de domínio absolutos. Se o RDATA especificado para um desses tipos de registro não terminar em um ponto para representar a raiz, o ponto será adicionado.
www.example.com --> www.example.com.
Você pode usar várias bibliotecas de DNS para normalizar RDATA antes da entrada.
| Linguagem de Programação | Biblioteca |
|---|---|
| Ir | Biblioteca DNS em Linguagem Go |
| Java | dnsjava |
| Python | dnspython |
Tipos de Registro de Recurso de DNS Privado
- A
- Um registro de endereço usado para apontar um nome de host para um endereço IPv4. Para obter mais informações sobre registros A, consulte RFC 1035.
- AAAA
- Um registro de endereço usado aponta um nome de host em um endereço IPv6. Para obter mais informações sobre registros AAAA, consulte RFC 3596.
- CAA
- Um registro de Autorização da Autoridade de Certificação é usado por um titular do nome de domínio para especificar uma ou mais Autoridades de Certificação autorizadas a emitir certificados para esse domínio. Para obter mais informações sobre registros CAA, consulte RFC 6844.
- CNAME
- Um registro de Nome Canônico identifica o nome canônico de um domínio. Para obter mais informações sobre registros CNAME, consulte RFC 1035.
- DNAME
- Um registro de Nome de Delegação tem comportamento semelhante a um registro CNAME, mas mapeia uma subárvore inteira abaixo de um label para outro domínio. Para obter mais informações sobre registros DNAME, consulte RFC 6672.
- MX
- Um registro de Trocador de E-mails define o servidor de e-mail que aceita e-mail para um domínio. Os registros MX devem apontar para um nome de host. Os registros MX não devem apontar para um endereço CNAME ou IP. Para obter mais informações sobre registros MX, consulte RFC 1035.
- PTR
- Um registro de ponteiro faz o mapeamento reverso de um endereço IP para um nome de host. Esse comportamento é o oposto de um Registro A, que faz o mapeamento encaminhado de um nome de host a um endereço IP. Os registros PTR normalmente são encontrados em zonas de DNS reverso. Para obter mais informações sobre registros PTR, consulte RFC 1035.
- SRV
- Um registro do Localizador de Serviço permite que os administradores usem vários servidores para um único domínio. Para obter mais informações sobre registros SRV, consulte RFC 2782.
- TXT
- Um registro de Texto contém texto descritivo, legível por seres humanos, e também pode incluir conteúdo não legível por seres humanos para usos específicos. Geralmente, esse tipo de registro é usado para registros SPF e registros DKIM que exigem itens de texto não legíveis pelo homem. Para obter mais informações sobre registros TXT, consulte RFC 1035.
Políticas Obrigatórias do Serviço IAM
Para trabalhar com o DNS privado, um usuário precisa do suficiente de autoridade (por meio de uma política do IAM). Os usuários do grupo Administradores têm a autoridade necessária. Se um usuário não estiver no grupo Administradores, uma política como essa permitirá que um grupo específico gerencie o DNS privado:
Allow group <GroupName> to manage dns in tenancy where target.dns.scope = 'private'Se você for iniciante em matéria de políticas, consulte conceitos Básicos de Políticas e Políticas Comuns. Para obter mais detalhes sobre políticas para DNS privado, consulte Referência de Política de DNS.
Tarefas de DNS Privado
Configurando o DNS Privado
Tarefas de DNS Privado
Tarefas da VCN
Para criar uma VCN com um resolvedor de DNS dedicado, consulte Visão Geral de VCNs e Sub-redes e DNS na Sua Rede Virtual na Nuvem para obter mais informações.