O registro cname é responsável por resolver um ip para um nome de domínio

Avançar para o conteúdo principal

Não há mais suporte para esse navegador.

Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.

Considerações ao usar nomes de domínio em uma solução multilocatário

Em muitos aplicativos Web multilocatários, um nome de domínio pode ser usado como forma de identificar um locatário, ajudar com solicitações de roteamento e fornecer uma experiência de marca para seus clientes. Duas abordagens comuns são usar subdomínios e nomes de domínio personalizados. Nesta página, fornecemos orientação para tomadores de decisão técnicos sobre as abordagens que você pode considerar e suas compensações.

Subdomínios

Cada locatário pode obter um subdomínio exclusivo em um nome de domínio compartilhado comum. Vamos considerar um exemplo de solução multilocatário criada pela Contoso. Os clientes compram o produto da Contoso para ajudar a gerenciar a criação de faturas. Todos os locatários da Contoso podem receber seu próprio subdomínio, sob o nome de domínio contoso.com. Alternativamente, se você usar implantações regionais, poderá atribuir subdomínios nos domínios us.contoso.com e eu.contoso.com. Neste artigo, nos referimos a eles como domínios-tronco. Cada cliente obtém seu próprio subdomínio em seu domínio de tronco. Por exemplo, a Tailwind Toys pode ser atribuído a tailwind.contoso.com, e Adventure Works pode ser atribuído a adventureworks.contoso.com.

Observação

Muitos serviços do Azure usam essa abordagem. Por exemplo, quando você cria uma conta de armazenamento do Azure, ela recebe um conjunto de subdomínios para você usar, como <your account name>.blob.core.windows.net.

Gerenciar seu namespace de domínio

Ao criar subdomínios com seu próprio nome de domínio, você precisa estar ciente de que pode ter vários clientes com nomes semelhantes. Como eles compartilham um único domínio de raiz, o primeiro cliente a obter um domínio específico obterá seu nome preferencial, e os clientes subsequentes terão que usar nomes de subdomínio alternativos, pois os nomes de domínio completos devem ser globalmente exclusivos.

DNS curinga

Considere usar entradas de DNS curinga para simplificar o gerenciamento de subdomínios. Em vez de criar entradas DNS para tailwind.contoso.com, adventureworks.contoso.com e assim por diante, você pode criar uma entrada curinga para *.contoso.com e direcionar todos os subdomínios para um único endereço IP (registro A) ou nome canônico (registro CNAME).

Observação

Garanta que seus serviços de camada da Web ofereçam suporte a DNS curinga para usar esse recurso. Muitos serviços do Azure, incluindo Azure Front Door e Serviço de Aplicativo do Azure, dão suporte a entradas DNS curinga.

Subdomínios com domínios-tronco de várias partes

Muitas soluções multilocatários estão espalhadas por várias implantações físicas. Isso é comum quando você precisa cumprir os requisitos de residência de dados ou quando deseja fornecer melhor desempenho implantando recursos geograficamente mais próximos dos usuários. Mesmo dentro de uma única região, você também pode precisar distribuir seus locatários em implantações independentes, como parte de sua estratégia de dimensionamento. Se você planeja usar subdomínios para cada locatário, considere uma estrutura de subdomínio de várias partes.

Veja aqui um exemplo: a Contoso publicou um aplicativo multilocatário para seus quatro clientes. A Adventure Works e a Tailwind Traders estão nos Estados Unidos e seus dados são armazenados em uma instância compartilhada dos EUA da plataforma Contoso. Os importadores globais e da Fabrikam têm sede na Europa, e seus dados são armazenados em uma instância europeia.

Se a Contoso optar por usar um único domínio de raiz, como contoso.com, para todos os seus clientes, veja qual será sua aparência:

As entradas DNS (necessárias para dar suporte a essa configuração) podem ter esta aparência:

Cada novo cliente integrado requer um novo subdomínio e o número de subdomínios cresce com cada cliente.

Como alternativa, a Contoso pode usar domínios de haste específicos de implantação ou região, como este:

As entradas DNS para esta implantação podem ter esta aparência:

A Contoso não precisa criar registros de subdomínio para cada cliente. Em vez disso, eles têm um único registro DNS curinga para a implantação de cada geografia, e todos os novos clientes que forem adicionados a essa raiz herdarão automaticamente o registro CNAME.

Existem vantagens e desvantagens em cada abordagem. Ao usar um único domínio-tronco, cada locatário integrado exigirá a criação de um novo registro DNS, o que imporá mais sobrecarga operacional. No entanto, você tem mais flexibilidade se precisar mover locatários entre implantações, pois pode alterar o registro CNAME para direcionar seu tráfego para outra implantação. Isso não afetará nenhum outro locatário. Ao usar vários domínios-tronco, haverá uma sobrecarga de gerenciamento menor e você pode reutilizar nomes de clientes em vários domínios-tronco regionais, pois cada um representa efetivamente seu próprio namespace.

Nomes de domínio personalizados

Convém permitir que seus clientes tragam seus próprios nomes de domínio. Alguns clientes veem isso como um aspecto importante de sua marca. Também pode ser necessário atender aos requisitos de segurança dos clientes, especialmente se eles precisarem fornecer seus próprios certificados TLS. Embora possa parecer trivial permitir que os clientes tragam seus próprios nomes de domínio, existem algumas complexidades ocultas nessa abordagem e isso requer uma consideração cuidadosa.

Resolução de nomes

Em última análise, cada nome de domínio precisa ser resolvido para um endereço IP. Como você viu, a abordagem pela qual isso acontece pode depender da implantação de uma única instância ou de várias instâncias de sua solução.

Voltemos ao nosso exemplo. Um dos clientes da Contoso, a Fabrikam, pediu para usar invoices.fabrikam.com como o nome de domínio personalizado para acessar o serviço da Contoso. Como a Contoso tem várias implantações de sua plataforma, eles decidem usar subdomínios e registros CNAME para atender aos requisitos de roteamento. A Contoso e a Fabrikam configuram os seguintes registros DNS:

De uma perspectiva de resolução de nomes, essa cadeia de registros resolve com precisão solicitações de invoices.fabrikam.com, para o endereço IP da implantação europeia da Contoso.

Resolução de cabeçalho de host

A resolução de nomes é apenas metade do problema. Todos os componentes da Web (na implantação europeia da Contoso) precisam estar cientes de como lidar com solicitações que chegam com o nome de domínio da Fabrikam em seu cabeçalho de solicitação Host. Dependendo das tecnologias da Web específicas que a Contoso usar, isso poderá exigir configuração adicional para o nome de domínio de cada locatário, o que adiciona uma sobrecarga operacional extra à integração de locatários.

Você também pode considerar reescrever cabeçalhos de host, para que, independentemente do cabeçalho de Host da solicitação recebida, seu servidor da Web veja um valor de cabeçalho consistente. Por exemplo, o Azure Front Door permite reescrever cabeçalhos de Host para que, independentemente da solicitação, o servidor de aplicativos receba um único cabeçalho de Host. O Azure Front Door propaga o cabeçalho do host original no cabeçalho de X-Forwarded-Host, para que seu aplicativo possa inspecioná-lo para resolver o locatário.

Validação do domínio

É importante validar a propriedade de domínios personalizados antes de integrá-los. Caso contrário, você corre o risco de um cliente estacionar um nome de domínio de maneira acidental ou mal-intencionada.

Vamos considerar o processo de integração da Contoso para a Adventure Works, que pediu para usar invoices.adventureworks.com como nome de domínio personalizado. Infelizmente, alguém cometeu um erro de digitação ao tentar integrar o nome de domínio personalizado e perdeu o s. Portanto, a configuração ficou como invoices.adventurework.com. Não só o tráfego não fluirá corretamente, mas quando outra empresa chamada Adventure Work tentar adicionar seu domínio personalizado à plataforma da Contoso, ela será informada de que o nome de domínio já está em uso.

Ao trabalhar com domínios personalizados, especialmente em um processo de autoatendimento ou automatizado, é comum exigir uma etapa de verificação de domínio. Isso pode exigir que os registros CNAME sejam configurados antes que o domínio possa ser adicionado. Como alternativa, a Contoso pode gerar uma cadeia de caracteres aleatória e pedir à Adventure Works para adicionar um registro DNS TXT com o valor da cadeia de caracteres. Isso impediria que o nome de domínio fosse adicionado até que a verificação fosse concluída.

DNS pendente e ataques de tomada de controle de subdomínio

Ao trabalhar com nomes de domínio personalizados, você fica potencialmente vulnerável a uma classe de ataque chamada DNS pendente ou tomada de controle de subdomínio. Esse ataque ocorre quando os clientes desassociam o nome de domínio personalizado do seu serviço, mas não excluem o registro do servidor DNS. Essa entrada DNS aponta para um recurso inexistente e é vulnerável a um controle.

Vamos considerar como o relacionamento da Fabrikam com a Contoso pode mudar:

1. A Fabrikam decidiu não trabalhar mais com a Contoso e, portanto, encerrou o relacionamento comercial.
2. A Contoso removeu o locatário da Fabrikam e eles pediram para interromper o funcionamento do fabrikam.contoso.com. No entanto, a Fabrikam esqueceu de excluir o registro CNAME de invoices.fabrikam.com.
3. Um ator mal-intencionado cria uma nova conta da Contoso e lhe dá o nome fabrikam.
4. O invasor integra o nome de domínio personalizado invoices.fabrikam.com ao novo locatário. Como a Contoso realiza a validação de domínio baseada em CNAME, ela confirma o servidor DNS da Fabrikam. Eles veem que o servidor DNS retorna um registro CNAME para invoices.fabrikam.com, que aponta para fabrikam.contoso.com. A Contoso considera que a validação de domínio personalizado foi bem-sucedida.
5. Se algum funcionário da Fabrikam tentasse acessar o site, as solicitações pareciam funcionar. Se o invasor configurar seu locatário da Contoso com a marca da Fabrikam, os funcionários poderão ser enganados ao acessar o site e fornecer dados confidenciais, que o invasor poderá acessar.

Uma estratégia comum para se proteger contra ataques de DNS pendentes é exigir que o registro CNAME seja excluído antes que o nome de domínio possa ser removido da conta do locatário. Considere também proibir a reutilização de identificadores de locatário e fortalecer seu processo de integração de domínio personalizado usando um registro TXT gerado aleatoriamente (que é diferente em cada tentativa de integração).

Certificados TLS/SSL

O protocolo TLS (Transport Layer Security) é um componente essencial ao trabalhar com aplicativos modernos. Ele fornece confiança e segurança para seus aplicativos Web. A propriedade e o gerenciamento de certificados TLS é algo que precisa de consideração cuidadosa para aplicativos multilocatários.

Normalmente, o proprietário de um nome de domínio será responsável por emitir e renovar seus certificados. Por exemplo, a Contoso é responsável por emitir e renovar certificados TLS para us.contoso.com, bem como um certificado curinga para *.contoso.com. Da mesma forma, a Fabrikam geralmente seria responsável por gerenciar todos os registros para o domínio fabrikam.com, incluindo invoices.fabrikam.com. O tipo de registro DNS CAA (autorização de autoridade de certificação) pode ser usado por um proprietário de domínio, para garantir que apenas autoridades específicas possam criar certificados para seu domínio.

Para permitir que os clientes tragam seus próprios domínios, considere se planeja emitir o certificado em nome do cliente ou se os clientes devem trazer seus próprios certificados. Cada opção tem vantagens e desvantagens. Se você emitir um certificado para um cliente, poderá lidar com a renovação do certificado para que o cliente não precise se lembrar de mantê-lo atualizado. No entanto, se os clientes tiverem registros de CAA em seus nomes de domínio, talvez eles precisem autorizar que você emita certificados em nome deles. Se você espera que os clientes emitam e forneçam seus próprios certificados, você é responsável por receber e gerenciar as chaves privadas de maneira segura e talvez precise lembrar seus clientes de renovar o certificado antes que ele expire, para evitar uma interrupção no seu serviço.

Vários serviços do Azure dão suporte ao gerenciamento automático de certificados para domínios personalizados. Por exemplo, o Azure Front Door e o Serviço de Aplicativo fornecem certificados para domínios personalizados e tratam automaticamente do processo de renovação. Isso remove a carga de gerenciamento de certificados da sua equipe de operações. No entanto, você ainda precisa considerar a questão de propriedade e autoridade, como se os registros CAA estão em vigor e configurados corretamente. Adicionalmente, você precisa garantir que os domínios de seus clientes estejam configurados para permitir os certificados gerenciados pela plataforma.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi escrito originalmente pelos colaboradores a seguir.

Autor principal:

• John Downs | Engenheiro de cliente principal, FastTrack para Azure

Outros colaboradores:

• Daniel Scott-Raynsford | Estrategista de tecnologia de parceiros
• Arsen Vladimirskiy | Engenheiro de cliente principal, FastTrack para Azure

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

Retorne à visão geral das considerações de arquitetura. Ou examine o Microsoft Azure Well-Architected Framework.

Qual a função do CNAME?

É responsável por resolver um IP para um nome de domínio?

O que é uma entrada CNAME?

Que protocolo permite utilizar um nome de domínio?