Partilhar via

Descrição geral de zonas e registos DNS

  • Artigo

Este artigo explica os conceitos-chave de domínios, zonas DNS, registos DNS e conjuntos de registos. Você aprende como eles são suportados no DNS do Azure.

Nomes de domínio

O Sistema de Nomes de Domínio é uma hierarquia de domínios. A hierarquia começa a partir do root domínio, cujo nome é simplesmente '.'. Abaixo disso, vêm os domínios de nível superior, como com, net, orguk ou jp. Abaixo dos domínios de nível superior estão os domínios de segundo nível, como org.uk ou co.jp. Os domínios na hierarquia DNS são distribuídos globalmente, hospedados por servidores de nomes DNS em todo o mundo.

Um registrador de nomes de domínio é uma organização que permite que você compre um nome de domínio, como contoso.com. A compra de um nome de domínio dá-lhe o direito de controlar a hierarquia de DNS sob esse nome, por exemplo, permitindo-lhe direcionar o nome www.contoso.com para o Web site da sua empresa. O registrar pode hospedar o domínio em seus próprios servidores de nomes em seu nome ou permitir que você especifique servidores de nomes alternativos.

O DNS do Azure fornece uma infraestrutura de servidor de nomes distribuída globalmente e de alta disponibilidade que você pode usar para hospedar seu domínio. Ao hospedar seus domínios no DNS do Azure, você pode gerenciar seus registros DNS com as mesmas credenciais, APIs, ferramentas, cobrança e suporte que seus outros serviços do Azure.

Atualmente, o DNS do Azure não oferece suporte à compra de nomes de domínio. Por uma taxa anual, você pode comprar um nome de domínio usando domínios do Serviço de Aplicativo ou um registrador de nomes de domínio de terceiros. Os domínios podem, então, ser alojados no DNS do Azure para a gestão de registos. Para obter mais informações, veja Delegar um domínio ao DNS do Azure.

Zonas DNS

Uma zona DNS é utilizada para alojar os registos DNS para um domínio particular. Para começar a alojar o seu domínio no DNS do Azure, tem de criar uma zona DNS para esse nome de domínio. Cada registo DNS para o seu domínio é então criado no interior desta zona DNS.

Por exemplo, o domínio “contoso.com” pode conter vários registos DNS, como “mail.contoso.com” (para um servidor de e-mail) e “www.contoso.com” (para um Web site).

Ao criar uma zona DNS no Azure DNS:

  • O nome da zona deve ser exclusivo dentro do grupo de recursos e a zona não pode já existir. Caso contrário, a operação falha.
  • O mesmo nome de zona pode ser reutilizado num grupo de recursos diferente ou numa subscrição diferente do Azure.
  • Onde as várias zonas partilham o mesmo nome, cada instância é atribuída a diferentes endereços do servidor do nome. Apenas um conjunto de endereços pode ser configurado com a entidade de registo de nome de domínio.

Nota

Não é necessário possuir um nome de domínio para criar uma zona DNS com esse nome de domínio no DNS do Azure. No entanto, tem de ser o proprietário do domínio para configurar os servidores de nomes DNS do Azure como os servidores de nomes corretos para o nome de domínio com a entidade de registo do nome de domínio.

Para obter mais informações, veja Delegar um domínio ao DNS do Azure.

Registos DNS

Nomes de registo

No DNS do Azure, os registos são especificados com nomes relativos. Um nome de domínio totalmente qualificado (FQDN) inclui o nome da zona, enquanto um nome relativo não. Por exemplo, o nome www do registro relativo na zona contoso.com fornece o nome www.contoso.comde registro totalmente qualificado.

Um registo apex é um registo DNS na raiz (ou apex) de uma zona DNS. Por exemplo, na zona contoso.comDNS, um registro do apex também tem o nome contoso.com totalmente qualificado (às vezes é chamado de domínio nu ). Por convenção, o nome relativo '@' é utilizado para representar registos apex.

Tipos de registo

Cada registo DNS tem um nome e um tipo. Os registos são organizados em vários tipos de acordo com os dados que contêm. O tipo mais comum é um registo “A”, que mapeia um nome para um endereço IPv4. Outro tipo comum é um registo “MX”, que mapeia um nome para um servidor de correio.

O DNS do Azure suporta todos os tipos de registo DNS comuns: A, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV e TXT. Tenha em atenção que os registos SPF são representados utilizando registos TXT.

Há suporte para tipos de registro adicionais se a zona for assinada com DNSSEC (DNS Security Extensions), como registros de recursos DS (Delegation Signer) e TLSA (Transport Layer Security Authentication).

Os tipos de registro de recursos DNSSEC, como DNSKEY, RRSIG e NSEC3, são adicionados automaticamente quando uma zona é assinada com DNSSEC. Esses tipos de registros de recursos DNSSEC não podem ser criados ou modificados após a assinatura da zona.

Conjuntos de registos

Por vezes, precisa de criar mais do que um registo DNS com um determinado nome e tipo. Por exemplo, suponha que o site “www.contoso.com” está alojado em dois endereços IP diferentes. O site necessita de dois registos A diferentes, um para cada endereço IP. Aqui está um exemplo de um conjunto de registros:

www.contoso.com.        3600    IN    A    134.170.185.46
www.contoso.com.        3600    IN    A    134.170.188.221

O DNS do Azure gere todos os registos DNS com conjuntos de registos. Um conjunto de registos (também conhecido como conjunto de registos de recurso) é uma coleção de registos DNS numa zona com o mesmo nome e do mesmo tipo. A maioria dos conjuntos de registos contêm um único registo. No entanto, exemplos como o acima, em que um conjunto de registros contém mais de um registro, não são incomuns.

Por exemplo, imagine que já criou um registo "www" A na zona "contoso.com", a apontar para o endereço IP "134.170.185.46" (o primeiro registo acima). Para criar o segundo registo, deverá adicionar esse registo para o conjunto de registos existente, em vez de criar um conjunto de registos adicional.

Os tipos de registos SOA e CNAME são exceções. As normas DNS não permitirem vários registos com o mesmo nome para estes tipos, por conseguinte, estes conjuntos de registos só podem conter um único registo.

Tempo de vida

O tempo de vida, ou TTL, especifica por quanto tempo cada registro é armazenado em cache pelos clientes antes de ser consultado. No exemplo acima, o TTL é de 3600 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 dentro desse conjunto de registros. Você pode especificar qualquer valor TTL entre 1 e 2.147.483.647 segundos.

Registros curinga

O DNS do Azure suporta registos de carateres universais. Os registros curinga são retornados em resposta a qualquer consulta com um nome correspondente, a menos que haja uma correspondência mais próxima de 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 seu rótulo mais à esquerda, por exemplo, '*.foo'.

Registos CAA

Os registros CAA permitem que os proprietários de domínio especifiquem quais Autoridades de Certificação (CAs) estão autorizadas a emitir certificados para seu domínio. Esse registro permite que as autoridades de certificação evitem a emissão incorreta de certificados em algumas circunstâncias. Os registros CAA têm três propriedades:

  • Sinalizadores: Este campo é um número inteiro entre 0 e 255, usado para representar o sinalizador crítico que tem significado especial por RFC6844
  • Tag: uma cadeia de caracteres ASCII que pode ser uma das seguintes:
    • problema: se você quiser especificar CAs com permissão para emitir certificados (todos os tipos)
    • issuewild: se você quiser especificar CAs que têm permissão para emitir certificados (somente certificados curinga)
    • iodef: especifique um endereço de e-mail ou nome de host para o qual as autoridades de certificação possam notificar solicitações de emissão de certificados não autorizados
  • Valor: o valor para a Tag específica escolhida

Registos CNAME

Os conjuntos de registros CNAME não podem coexistir com outros conjuntos de registros com o mesmo nome. Por exemplo, não é possível criar um conjunto de registros CNAME com o nome www relativo e um registro A com o nome www relativo ao mesmo tempo.

Como o ápice da zona (name = '@') sempre conterá os conjuntos de registros NS e SOA durante a criação da zona, não é possível criar um conjunto de registros CNAME no ápice da zona.

Estas restrições derivam das normas DNS e não são limitações do DNS do Azure.

Registos NS

O registro NS definido no ápice da zona (nome '@') é criado automaticamente com cada zona DNS e é excluído automaticamente quando a zona é excluída. Ele não pode ser excluído separadamente.

Este conjunto de registos contém os nomes dos servidores de nomes DNS do Azure atribuídos à zona. Você pode adicionar mais servidores de nomes a esse conjunto de registros NS, para oferecer suporte a domínios de cohospedagem com mais de um provedor DNS. Você também pode modificar o TTL e os metadados desse conjunto de registros. No entanto, remover ou modificar os servidores de nomes DNS do Azure pré-preenchidos não é permitido.

Essa restrição só se aplica ao registro NS definido no ápice da zona. Outros conjuntos de registros NS em sua zona (como usados para delegar zonas filhas) podem ser criados, modificados e excluídos sem restrições.

Registos SOA

Um conjunto de registros SOA é criado automaticamente no ápice de cada zona (nome = '@') e é excluído automaticamente quando a zona é excluída. Os registros SOA não podem ser criados ou excluídos separadamente.

Você pode modificar todas as propriedades do registro SOA, exceto a host propriedade. Esta propriedade é pré-configurada para fazer referência 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.

Nota

Atualmente, o DNS do Azure não oferece suporte ao uso de um ponto (.) antes do '@' na entrada de caixa de correio do mestre de host SOA. Por exemplo: john.smith@contoso.xyz (convertido em john.smith.contoso.xyz) e john\.smith@contoso.xyz não são permitidos.

Registos SPF

Os registros SPF (Sender Policy Framework) são usados para especificar quais servidores de email podem enviar emails em nome de um nome de domínio. A configuração correta dos registros SPF é importante para evitar que os destinatários marquem seu e-mail como lixo.

As RFCs DNS originalmente introduziram um novo tipo de registro SPF para dar suporte a esse cenário. Para oferecer suporte a servidores de nomes mais antigos, eles também permitiam o uso do tipo de registro TXT para especificar registros SPF. Esta ambiguidade levou à confusão, que foi resolvida pelo RFC 7208. Ele afirma que os registros SPF devem ser criados usando o tipo de registro TXT. Ele também afirma que o tipo de registro SPF foi preterido.

Os registros SPF são suportados pelo DNS do Azure e devem ser criados usando o tipo de registro TXT. O tipo de registro SPF obsoleto não é suportado. Quando você importa um arquivo de zona DNS, todos os registros SPF que usam o tipo de registro SPF são convertidos para o tipo de registro TXT.

Registos 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, prefixados com sublinhados, como '_sip._tcp.name'. Para um registro no ápice da zona, não há necessidade de especificar '@' no nome do registro, basta usar o serviço e o protocolo, como '_sip._tcp'.
  • A prioridade, o peso, a porta e o destino são especificados como parâmetros de cada registro no conjunto de registros.

Registos TXT

Os registros TXT são usados para mapear nomes de domínio para cadeias de texto arbitrárias. Eles são usados em vários aplicativos, em particular relacionados à configuração de e-mail, como o SPF (Sender Policy Framework) e o DKIM (DomainKeys Identified Mail).

Os padrões DNS permitem que um único registro TXT contenha várias cadeias de caracteres, cada uma das quais pode ter até 255 caracteres de comprimento. Quando várias cadeias de caracteres são usadas, elas são concatenadas por clientes e tratadas como uma única cadeia de caracteres.

Ao chamar a API REST do Azure DNS, você precisa especificar cada cadeia de caracteres TXT separadamente. Ao usar o portal do Azure, o PowerShell ou as interfaces da CLI, você deve especificar uma única cadeia de caracteres por registro. Esta cadeia de caracteres é automaticamente dividida 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, cada um dos quais pode conter várias cadeias de caracteres. O DNS do Azure dá suporte a um comprimento total de cadeia de caracteres de até 4096 caracteres em cada conjunto de registros TXT (em todos os registros combinados).

Registos DS

O registro de assinante de delegação (DS) é um tipo de registro de recurso DNSSEC usado para proteger uma delegação. Para criar um registro DS em uma zona, a zona deve primeiro ser assinada com DNSSEC.

Registos TLSA

Um registro TLSA (Transport Layer Security Authentication) é usado para associar um certificado de servidor TLS ou chave pública ao nome de domínio onde o registro é encontrado. Um registro TLSA vincula a chave pública (um certificado de servidor TLS) ao nome de domínio, fornecendo uma camada adicional de segurança para conexões TLS.

Para utilizar os registos TLSA de forma eficaz, o DNSSEC tem de estar ativado no seu domínio. Isso garante que os registros TLSA possam ser confiáveis e devidamente validados

Tags e metadados

Etiquetas

As marcas são uma lista de pares nome-valor e são usadas pelo Azure Resource Manager para rotular recursos. O Azure Resource Manager utiliza etiquetas para ativar vistas filtradas da sua fatura do Azure e também lhe permite definir uma política para determinadas etiquetas. Para obter mais informações sobre etiquetas, consulte Utilizar etiquetas para organizar os recursos do Azure.

O DNS do Azure dá suporte ao uso de tags do Azure Resource Manager em recursos de zona DNS. Ele não suporta tags em conjuntos de registros DNS, embora, como alternativa, os metadados sejam suportados em conjuntos de registros DNS, conforme explicado abaixo.

Metadados

Como alternativa às marcas do conjunto de registros, o DNS do Azure dá suporte à anotação de conjuntos de registros usando metadados. Semelhante às tags, os metadados permitem associar pares nome-valor a cada conjunto de registros. Este recurso pode ser útil, por exemplo, para registrar a finalidade de cada conjunto de registros. Ao contrário das tags, os metadados não podem ser usados para fornecer uma exibição filtrada da sua fatura do Azure e não podem ser especificados em uma política do Azure Resource Manager.

Etiquetas

Suponha que duas pessoas ou dois processos tentem modificar um registro DNS ao mesmo tempo. Qual deles ganha? E o vencedor sabe que substituiu as alterações criadas por outra pessoa?

O DNS do Azure usa Etags para lidar com alterações simultâneas no mesmo recurso com segurança. As etags são separadas das 'Tags' do Azure Resource Manager. Cada recurso DNS (zona ou conjunto de registros) tem um Etag associado a ele. Sempre que um recurso é recuperado, seu Etag também é recuperado. Ao atualizar um recurso, você pode optar por passar de volta o Etag para que o DNS do Azure possa verificar se o Etag no servidor corresponde. Como cada atualização de um recurso resulta na regeneração do Etag, uma incompatibilidade de Etag indica que ocorreu uma alteração simultânea. Etags também podem ser usados ao criar um novo recurso para garantir que o recurso ainda não exista.

Por padrão, o Azure DNS PowerShell usa Etags para bloquear alterações simultâneas em zonas e conjuntos de registros. A opção opcional -Overwrite pode ser usada para suprimir verificações Etag, caso em que quaisquer alterações simultâneas que tenham ocorrido são substituídas.

No nível da API REST do Azure DNS, os Etags são especificados usando cabeçalhos HTTP. O seu comportamento é dado na tabela seguinte:

Cabeçalho Comportamento
Nenhuma PUT sempre é bem-sucedido (sem verificações Etag)
Etag If-match <> PUT só terá êxito se o recurso existir e o Etag corresponder
Se corresponder * O PUT só é bem-sucedido se existir recurso
Se-nenhum-correspondência * PUT só é bem-sucedido se o recurso não existir

Limites

Os seguintes limites padrão se aplicam ao usar o DNS do Azure:

Zonas DNS públicas

Recurso Limite
Zonas DNS públicas por subscrição 250 1
Conjuntos de registos por zona DNS pública 10.000 1
Registos por registo definido na zona DNS pública 20
Número de registros Alias para um único recurso do Azure 20

1 Se precisar de aumentar estes limites, contacte o Suporte do Azure.

Próximos passos