registros CNAME sendo efetivamente ignorados e substituídos pelo registro CNAME curinga

0

Recentemente, criei o seguinte registro CNAME em nosso DNS público para permitir que nossos clientes do Office 2010 se configurassem automaticamente para o Office 365 (ou seja, para que possamos usar a descoberta automática).

Domain: autodiscover.(ourdomain).com
Target: autodiscover.outlook.com

Infelizmente, depois de permitir mais de 48 horas para o DNS resolver (mais do que tempo suficiente), ainda não podemos usar a descoberta automática.

NSLOOKUP revela que "autodiscover. (ourdomain) .com" resolve "(ourdomain) .com", em vez de "autodiscover.outlook.com". O mesmo acontece com os outros registros CNAME apontando para "lync.com".

O NSLOOKUP parece resolver meus três novos registros CNAME de volta para a raiz do nosso domínio em vez de para os servidores da Microsoft especificados. Isso é exatamente o que eu esperaria ver se os registros CNAME não existissem (como nosso registro CNAME curinga, então, manipularia os subdomínios não reconhecidos).

Por que o registro curinga aparentemente está lidando com essas solicitações se existirem registros CNAME para esses subdomínios específicos do ? Somente os três registros CNAME destacados em vermelho parecem ser substituídos pelo registro curinga. Os outros estão funcionando corretamente.

Parece que esta é mais uma questão geral de DNS do que uma do Office 365.

    
por Austin ''Danger'' Powers 04.04.2014 / 00:19

1 resposta

5

Meu provedor de hospedagem demorou cerca de 2 minutos para identificar o problema.

Acontece que eu tinha esquecido de adicionar períodos ao final dos nomes de host de destino e destino.

Problema resolvido!

" A questão é que você está perdendo um ponto". "no final de cada nome de host, tanto no lado esquerdo quanto no lado direito.

Quando você não insere um período no final, o DNS traduz isso para exemplo:

"sip. (yourdomain) .ca" torna-se "sip. (yourdomain) .ca. (yourdomain) .ca" no DNS.

Mas se você tivesse "gole. (yourdomain) .ca." (com o período), ele reconheceria como "gole (yourdomain) .ca" corretamente.

Lembre-se de fazer isso para o Lync e outros nomes de host no lado direito também.

Por favor, não adicione "." períodos para endereços IP. Eles não precisam do período e causarão um problema se forem adicionados a eles. "

Então, isso explica. O curinga (que direcionava consultas NSLOOKUP para a raiz de nosso domínio) estava sendo aplicado porque o subdomínio "autodiscover. (Ourdomain) .ca. (ourdomain) .ca " era como meu registro CNAME estava sendo interpretado - por isso, não corresponde à consulta NSLOOKUP para "autodiscover. (ourdomain) .ca".

No final, percebi que realmente poderia excluir a raiz do domínio da coluna da esquerda e ela seria automaticamente adicionada, desde que eu não acrescentasse um ponto. (Alternativamente, eu poderia ter deixado a raiz do domínio lá e adicionado um período - mas eu sou um minimalista.)

Isso é o que acabei usando e agora tudo está resolvido corretamente no NSLOOKUP:

Períodos usados apenas no lado direito.

    
por 04.04.2014 / 03:13