Veja: Como configurar o CNAME para apontar para Azure
ou o texto dentro do portal azure:
Por que isso é necessário em primeiro lugar? Por que apontar o nome de domínio através de um registro A não prova que eu sou o proprietário do domínio?
Quero dizer, como você pode mudar um registro de DNS?
Qual abuso essa regra impede?
Se você tiver controle de uma pesquisa de DNS para um computador ou se puder injetar um registro de host, poderá falsificar um registro A para essa máquina e apontá-la para um site do Azure (não há nada que impeça você de fazer isso para uma VM embora)
Ao criar um registro cname e verificá-lo independentemente (por meio do sistema DNS interno / público), significa que você tem controle sobre o domínio e não está falsificando o domínio de outra pessoa.
Para comprovar o controle do domínio, você precisa colocar algumas informações em um registro DNS no domínio, que identificará sua conta do Azure.
Essas informações podem ser incorporadas no nome de domínio para o qual um CNAME aponta. A parte do domínio que foi omitida da postagem esperaria identificar sua conta do Azure em particular.
Você não precisa manter esse nome em segredo. Afinal, ele ficará visível publicamente quando você o colocar em um registro DNS.
A razão pela qual eles não poderiam fazer o mesmo com um registro A é que não há entropia suficiente em um registro A para obter a mesma segurança.
Isso não significa que o CNAME é o único método que eles poderiam usar. Outros métodos que poderiam ter funcionado incluem:
Pessoalmente, considero um registro TXT em um subdomínio gerado aleatoriamente pelo verificador como o melhor método, já que é o menos intrusivo. Mas isso parece não ser suportado no seu caso.
Deixe-me tentar responder à sua pergunta fornecendo dois casos. Em ambos os casos, você ainda precisará verificar se é o proprietário, é apenas uma etapa de segurança.
1) www.example.com não está sendo visitado e não está em produção
2) www.example.com está atualmente em produção e está sendo muito usado
1) Se o seu domínio estiver sendo configurado ou não estiver em produção / sendo acessado, você poderá criar um registro CNAME que aponte para yoursite.azurewebsites.net . Não é necessário awverify.myhost.azurewebsites.net .
2) Se o seu domínio estiver em uso pesado e estiver sendo acessado atualmente, e você quiser testar para ver se o Azure vê as alterações em seus registros DNS, você pode criar um subdomínio chamado ' awverify ' como em awverify.example.com e aponte para um subdomínio criado awverify.myhost.azurewebsites.net . Isso não afetará seus usuários atuais que acessam seu website, indo para www.example.com . Depois que o Azure verificar que ele vê a alteração no CNAME, você poderá notificar os usuários sobre manutenção e alterar o registro A. Se você acabou de alterar o registro A, o site pode ser visto como off-line por até 8 horas.
Para responder à sua pergunta, não é necessário usar awverify . Apenas mudando o CNAME pode funcionar também. Além disso, apenas alterar o registro A redirecionará todo o tráfego de yourdomain.com para yoursite.azurewebsites.net
Espero que isso ajude.
1) Eu configurei vários sites no Azure e todos eles têm o mesmo endereço IP no registro A. Não sei se o endereço IP do registro A também pode ser atribuído a outra conta, mas talvez seja uma possibilidade. Em caso afirmativo, pode-se conseguir retirar o site do Azure de outra pessoa simplesmente inserindo o domínio no painel de controle do Azure. Esta é apenas uma teoria, não sei se é remotamente possível.
2) Como mencionado acima, o registro CNAME é basicamente um registro inerte. Não redireciona o tráfego. Quando migrei um site grande e seu certificado SSL, foi uma bênção poder reivindicar a propriedade com o awsverify, configurar o domínio e o certificado SSL e, em seguida, todo o código testado no Azure. Semanas depois, mudei o registro A para ir ao vivo. O ponto é que o registro A não foi alterado até o momento da ativação, semanas após o uso do awsverify para validar a propriedade no domínio. Então, no meu caso, foi útil.
Não que eu concorde com isso, mas aqui está a resposta que recebi diretamente da Microsoft. Em resumo, ele impede que alguém adicione um domínio que você possui a outro aplicativo da web do Azure, mas apenas no mesmo datacenter que você. Então, essencialmente, alguém teria que tentar registrar um domínio que você possui E estar no mesmo datacenter (região do Azure) para que essa proteção seja útil. Do ponto de vista do DNS, faz pouco sentido, já que posso adicionar www.microsoft.com e criar uma página da Web falsa em todos os servidores da Web que possuo, mas se eu não tiver acesso para alterar o registro DNS, isso não significará nada. Claro que eu poderia fazer isso com um servidor DNS desonesto em um ponto de acesso não autorizado, mas o que eu preciso para um aplicativo da Web do Azure nessa instância? Eu posso girar uma VM e ignorar a restrição de qualquer maneira. Realmente não faz sentido para mim e é realmente apenas um aborrecimento sempre que chega a hora de adicionar um novo site. O processo que leva alguns minutos agora coloca uma dependência do DNS antes que eu possa até adicionar um domínio a um aplicativo da web. Isso geralmente é bom para novos domínios, mas se eu tenho um domínio existente, é uma dor. Eu tenho que criar esse outro registro DNS, excluí-lo depois de adicionar meu domínio ao meu aplicativo da web e, em seguida, modificar o registro DNS que realmente quero alterar. De qualquer forma, aqui está a resposta da Microsoft sobre o porquê:
A preocupação com a segurança é, considerando este cenário, se permitir que alguém adicione seu domínio ao aplicativo antes de fazer isso no seu aplicativo da web, não será possível adicionar seu domínio novamente devido a conflitos, pois os aplicativos da web do Azure compartilhe os mesmos servidores front-end no mesmo datacenter. Por isso, deve verificar cada domínio / subdomínio antes de atribuí-lo a um aplicativo da web. Se hospedarmos sites em uma máquina virtual, não haverá restrições a ela.