Visão geral das zonas DNS privadas
Este artigo fornece informações sobre o suporte para registros DNS em zonas DNS privadas do Azure. Para obter uma visão geral das zonas DNS privadas, consulte: O que é uma zona DNS privada do Azure?
Registros DNS
Nomes de registros
Os registros são especificados usando nomes relativos. Um FQDN (nome de domínio totalmente qualificado) inclui o nome da zona, enquanto um nome relativo não o inclui. Por exemplo, o nome relativo do registro www na zona contoso.com fornece o nome totalmente qualificado do registro www.contoso.com.
Um registro apex é um registro DNS na raiz (ou apex) de uma zona DNS. Por exemplo, na zona DNScontoso.com, um registro apex também tem o nome totalmente qualificadocontoso.com (ele às vezes é chamado de domíniodescoberto). Por convenção, o nome relativo \'\@\' é usado para representar os registros de vértices.
Tipos de registro
Cada registro DNS tem um nome e um tipo. Os registros são organizados em vários tipos de acordo com os dados que eles contêm. O tipo mais comum é um registro 'A', que mapeia um nome para um endereço IPv4. Outro tipo comum é um registro 'MX', que mapeia um nome para um servidor de email.
O DNS privado do Azure dá suporte aos seguintes tipos comuns de registro DNS: A, AAAA, CNAME, MX, NS, PTR, SOA, SRV e TXT.
Observação
O campo Host no registro SOA não é editável.
Conjuntos de registros
Às vezes, você precisa criar mais de um registro DNS com determinado nome e tipo. Por exemplo, vamos supor que o site 'www.contoso.com' seja hospedado em dois endereços IP diferentes. O site exige dois registros A diferentes, um para cada endereço IP. Aqui está um exemplo de um conjunto de registros:
www.contoso.com. 3600 IN A 10.10.1.5
www.contoso.com. 3600 IN A 10.10.1.10
O DNS do Azure gerencia todos os registros DNS usando conjuntos de registros. Um conjunto de registros (também conhecido como conjunto de registros de recurso) é uma coleção de registros DNS em uma zona que tem o mesmo nome e o mesmo tipo. A maioria dos conjuntos de registros contém um único registro. No entanto, exemplos como o que é mostrado acima, em que um conjunto de registros contém mais de um registro, não são incomuns.
Por exemplo, digamos que você já criou um registro A “www” na zona “contoso.com” apontando para o endereço IP “10.10.1.5” (o primeiro registro acima). Para criar o segundo registro, você deve adicioná-lo ao conjunto de registros existente em vez de criar um conjunto de registros adicional.
Os conjuntos de registros SOA e CNAME são exceções. Os padrões DNS não permitem vários registros com o mesmo nome para esses tipos e, assim, esses conjuntos de registros podem conter apenas um único registro.
Vida útil
O tempo de vida, ou TTL, especifica quanto tempo cada registro é armazenado em cache pelos clientes antes de ser consultado. No exemplo acima, o TTL tem 3.600 segundos ou 1 hora.
No DNS do Azure, o TTL é especificado para o conjunto de registros, não para cada registro, portanto, o mesmo valor é usado para todos os registros no conjunto de registros. Você pode especificar qualquer valor de TTL entre 1 e 2.147.483.647 segundos.
Registros curinga
O DNS do Azure dá suporte a registros curinga. Os registros curinga são retornados como resposta a qualquer consulta com um nome correspondente, a menos que haja uma correspondência mais próxima em um conjunto de registros não curinga. O DNS do Azure dá suporte a conjuntos de registros curinga para todos os tipos de registro, exceto NS e SOA.
Para criar um conjunto de registros curinga, use o nome do conjunto de registros '*'. Você também pode usar um nome com '*' como o rótulo na extremidade esquerda, por exemplo, '*.foo'.
Registros CNAME
Conjuntos de registros CNAME não podem coexistir com outros conjuntos de registros com o mesmo nome. Por exemplo, você não pode criar um conjunto de registros CNAME com o nome relativo www e um registro A com o nome relativo www ao mesmo tempo.
Como o ápice da zona (nome = “@”) sempre contém os conjuntos de registro SOA e NS durante a criação da zona, não é possível criar um conjunto de registros CNAME nele.
Essas restrições são provenientes dos padrões DNS e não são limitações do DNS do Azure.
Registros SOA
Um conjunto de registros SOA é criado automaticamente no ápice de cada zona (nome ='@') e é excluído automaticamente quando a zona é excluída. Registros SOA não podem ser criados ou excluídos separadamente.
Você pode modificar todas as propriedades do registro SOA, exceto a propriedade host. Essa propriedade é pré-configurada para se referir ao nome do servidor de nomes primário fornecido pelo DNS do Azure.
O número de série da zona no registro SOA não é atualizado automaticamente quando são feitas alterações nos registros na zona. Ele pode ser atualizado manualmente editando o registro SOA, se necessário.
Registros SRV
Os registros SRV são usados por vários serviços para especificar locais de servidor. Ao especificar um registro SRV no DNS do Azure:
- O serviço e o protocolo devem ser especificados como parte do nome do conjunto de registros, prefixado com sublinhados, como "_sip._tcp.name". Para um registro no ápice da zona, não é necessário especificar "@" no nome do registro. Basta usar o serviço e o protocolo, por exemplo, "_sip._tcp".
- A prioridade, o peso, a porta e o destino são especificados como parâmetros de cada registro no conjunto de registros.
Registros TXT
Os registros TXT são usados para mapear nomes de domínio em cadeias de caracteres de texto arbitrárias. Eles são usados em vários aplicativos.
Os padrões do DNS permitem que um único registro TXT contenha várias cadeias de caracteres, e cada uma delas pode ter até 255 caracteres. Quando várias cadeias de caracteres são usadas, elas são concatenadas pelos clientes e tratadas como uma única cadeia de caracteres.
Ao chamar a API REST de DNS do Azure, é necessário especificar cada cadeia de caracteres TXT separadamente. Ao usar interfaces do portal do Azure, PowerShell ou CLI é necessário especificar uma cadeia de caracteres única por registro. Essa cadeia de caracteres é dividida automaticamente em segmentos de 255 caracteres, se necessário.
As várias cadeias de caracteres em um registro DNS não devem ser confundidas com os vários registros TXT em um conjunto de registros TXT. Um conjunto de registros TXT pode conter vários registros e cada um deles pode conter várias cadeias de caracteres. O DNS do Azure dá suporte a um tamanho total de até 4096 caracteres* em cada conjunto de registros TXT (entre todos os registros combinados).
* Atualmente, o suporte a 4096 caracteres só está disponível na Nuvem Pública do Azure. As nuvens nacionais são limitadas a 1.024 caracteres até que a distribuição de suporte de 4k seja concluída.
Marcas e metadados
Marcações
As marcas consistem em uma lista de pares de nome/valor e são usadas pelo Azure Resource Manager na rotulagem de recursos. O Azure Resource Manager usa marcas para habilitar exibições filtradas da sua fatura do Azure e também permite que você defina uma política para determinadas marcas. Para obter mais informações sobre marcas, consulte Usando marcas para organizar os recursos do Azure.
O DNS do Azure dá suporte ao uso de marcas do Azure Resource Manager em recursos de zona DNS. Ele não oferece suporte a marcas em conjuntos de registros DNS, embora, alternativamente, metadados sejam compatíveis com conjuntos de registros DNS, conforme explicado abaixo.
Metadados
Como uma alternativa às marcas de conjunto de registros, o DNS do Azure é compatível com a anotação de conjuntos de registros por meio demetadados. Semelhante às marcas, os metadados permitem que você associe pares de nome-valor a cada conjunto de registros. Esse recurso pode ser útil, por exemplo, para registrar a finalidade de cada conjunto de registros. Diferentemente das marcas, os metadados não podem ser usados para fornecer uma exibição filtrada de sua fatura do Azure e não podem ser especificados em uma política do Azure Resource Manager.
ETags
Suponha que duas pessoas ou dois processos tentem modificar um registro DNS ao mesmo tempo. Qual vence? E o vencedor sabe que substituiu as alterações criadas por outra pessoa?
O DNS do Azure usa as Etags para tratar alterações simultâneas para o mesmo recurso com segurança. As Etags são separadas das "Marcações" do Azure Resource Manager. Cada recurso DNS (zona ou conjunto de registros) tem uma Etag associada a ele. Sempre que um recurso é recuperado, a Etag também é recuperada. Ao atualizar um recurso, você pode escolher devolver a Etag para que o DNS do Azure possa verificar se a Etag no servidor é correspondente. Uma vez que cada atualização a um recurso resulta em uma Etag sendo gerada novamente, uma incompatibilidade de Etag indica que ocorreu uma alteração simultânea. As Etags também podem ser usadas ao criar um recurso para verificar se o recurso já existe.
Por padrão, o PowerShell do DNS do Azure usa as Etags bloquear alterações simultâneas às zonas e conjuntos de registro. O switch opcional -Overwrite pode ser usado para suprimir as verificações de Etag. Nesse caso, as alterações simultâneas que ocorrerem são substituídas.
No nível da API REST do DNS do Azure, as Etags são especificadas usando cabeçalhos HTTP. Seu comportamento é descrito na tabela a seguir:
| parâmetro | Comportamento |
|---|---|
| Nenhum | PUT sempre terá êxito (nenhuma verificação de Etag) |
| If-match <etag> | PUT só terá êxito se o recurso existir e a Etag corresponder |
| If-match * | PUT só terá êxito se houver recursos |
| If-none-match * | O PUT só terá êxito se o recurso não existir |
Limites
Os limites padrão abaixo se aplicam ao usar o DNS privado do Azure:
Zonas DNS privadas
| Recurso | Limite |
|---|---|
| Zonas DNS privadas por assinatura | 1000 |
| Conjuntos de registros por zona DNS privada | 25000 |
| Registros por conjunto de registros para zonas DNS privadas | 20 |
| Links de Redes Virtuais por zona DNS privada | 1000 |
| Links de redes virtuais por zonas DNS particulares com registro automático habilitado | 100 |
| Número de zonas DNS particulares às quais uma rede virtual pode ser vinculada com o registro automático habilitado | 1 |
| Número de zonas DNS privadas às quais uma rede virtual poderá ser vinculada | 1000 |