Como superar as restrições de CNAME do domínio raiz?

Estamos hospedando muitos aplicativos da web para nossos clientes. Como é óbvio, eles querem usar seus próprios domínios para se referir a esses aplicativos, geralmente eles querem que qualquer usuário que digite http://www.customer1.exampleou http://customer1.examplevá até seu aplicativo da web.

A situação que enfrentamos é que precisamos ter flexibilidade para alterar os endereços IP em um futuro próximo. E não queremos depender do cliente para fazer a alteração do registro A em seus domínios. Portanto, pensamos que o uso de CNAMEregistros funcionaria, mas, como descobrimos, os CNAMEregistros não funcionarão para o domínio raiz.

Basicamente:

customer1.example IN CNAME customer1.mycompanydomain.example //this is invalid as the RFC
www.customer1.example IN CNAME customer1.mycompanydomain.example //this is valid and will work

Queremos ser capazes de alterar o endereço IP customer1.mycompanydomain.exampleou o Aregistro e nossos clientes seguirão este registro sobre o qual temos controle.

em nosso DNS será semelhante a:

customer1.mycompanydomain.example IN A 192.0.2.1

Alguma ideia?

A razão pela qual essa pergunta ainda surge com frequência é porque, como você mencionou, em algum lugar alguém presumido como importante escreveu que a RFC declara que os nomes de domínio sem subdomínio na frente deles não são válidos. Se você ler o RFC com atenção, no entanto, descobrirá que não é exatamente o que ele diz. Na verdade, a RFC 1912 afirma:

Não exagere com CNAMEs. Use-os ao renomear hosts, mas planeje se livrar deles (e informar seus usuários).

Alguns hosts DNS fornecem uma maneira de obter funcionalidade semelhante a CNAME no ápice da zona (o nível de domínio raiz, para o nome de domínio sem www) usando um tipo de registro personalizado. Esses registros incluem, por exemplo:

• ALIAS em DNSimple
• ANAME em DNS Made Easy
• ANAME em easyDNS
• CNAME em CloudFlare

Para cada provedor, a configuração é semelhante: aponte a entrada ALIAS ou ANAME de seu domínio apex para example.domain.com, da mesma forma que faria com um registro CNAME. Dependendo do provedor de DNS, um valor vazio ou @ Name identifica o ápice da zona.

ALIAS ou ANAME ou @ example.domain.com.

Se o seu provedor de DNS não oferecer suporte a esse tipo de registro e você não conseguir mudar para um que suporte, você precisará usar o redirecionamento de subdomínio, o que não é tão difícil, dependendo do protocolo ou software de servidor que precisa fazer isso .

Eu discordo veementemente da afirmação de que isso é feito apenas por "administradores amadores" ou outras ideias. É um simples "O que o nome e seu serviço precisam fazer?" lidar e, em seguida, adaptar sua configuração DNS para atender a esses desejos; Se seus serviços principais são web e e-mail, não vejo nenhuma razão VÁLIDA para que descartar os CNAMEs para sempre seja problemático. Afinal, quem prefere @ subdomain.domain.org em vez de @ domain.org? Quem precisa de "www" se você já está configurado com o próprio protocolo? É ilógico supor que o uso de um nome de domínio raiz seja inválido.

O CNAME de um registro raiz não é tecnicamente contra o RFC, mas tem limitações, o que significa que é uma prática não recomendada.

Normalmente, seu registro raiz terá várias entradas. Digamos, 3 para seus servidores de nome e um para um endereço IP.

Por RFC:

Se um CNAME RR estiver presente em um nó, nenhum outro dado deve estar presente;

E de acordo com o documento 'Erros comuns operacionais e de configuração de DNS da IETF:

Isso é frequentemente tentado por administradores inexperientes como uma maneira óbvia de permitir que seu nome de domínio também seja um host. No entanto, servidores DNS como o BIND verão o CNAME e se recusarão a adicionar quaisquer outros recursos para esse nome. Como nenhum outro registro pode coexistir com um CNAME, as entradas NS são ignoradas. Portanto, todos os hosts no domínio podunk.xx também são ignorados!

Referências:

• http://tools.ietf.org/html/rfc1912 seção '2.4 Registros CNAME'
• http://www.faqs.org/rfcs/rfc1034.html seção '3.6.2. Aliases e nomes canônicos '

Não sei como eles estão se saindo com isso, ou quais efeitos colaterais negativos podem ser, mas estou usando o Hover.com para hospedar alguns dos meus domínios e recentemente configurei o apex do meu domínio como um CNAME lá. A ferramenta de edição de DNS deles não reclamou, e meu domínio felizmente resolve por meio do CNAME atribuído.

Aqui está o que Dig me mostra para este domínio (domínio real ofuscado como mydomain.com):

; <<>> DiG 9.8.3-P1 <<>> mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2056
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mydomain.com.          IN  A

;; ANSWER SECTION:
mydomain.com.       394 IN  CNAME   myapp.parseapp.com.
myapp.parseapp.com. 300 IN  CNAME   parseapp.com.
parseapp.com.       60  IN  A   54.243.93.102

Minha empresa faz o mesmo com vários clientes, onde hospedamos um site para eles, embora em nosso caso seja xyz.company.com em vez de www.company.com. Fazemos com que eles definam o registro A em xyz.company.com para apontar para um endereço IP que atribuímos a eles.

Quanto a como você poderia lidar com uma mudança no endereço IP, não acho que haja uma solução perfeita. Algumas ideias são:

• Use um balanceador de carga NAT ou IP e forneça aos seus clientes um endereço IP pertencente a ele. Se o endereço IP do servidor da web precisar ser alterado, você pode fazer uma atualização no NAT ou no balanceador de carga,

• Ofereça um serviço de hospedagem DNS também e faça com que seus clientes hospedem seus domínios com você para que você possa atualizar os registros A,

• Faça com que seus clientes configurem seu registro A em um servidor da web principal e use um redirecionamento HTTP para as solicitações da web de cada cliente.

Sipwiz está correto, a única maneira de fazer isso corretamente é a abordagem híbrida de HTTP e DNS. Meu registrador é um revendedor da Tucows e oferece encaminhamento de domínio raiz como um serviço de valor agregado gratuito.

Se o seu domínio for blah.com, eles perguntarão para onde você deseja que o domínio seja encaminhado e você digita www.blah.com. Eles atribuem o registro A ao seu servidor apache e adicionam automaticamente blah.com como um vhost DNS. O vhost responde com um erro HTTP 302, redirecionando-os para o URL adequado. É simples de fazer o script / configuração e pode ser manipulado por baixo custo, caso contrário, seria o hardware descartado.

Execute o seguinte comando para obter um exemplo: curl -v eclecticengineers.com

Você tem que colocar um ponto final no final do domínio externo para que não ache que você se refira ao cliente1.minhaempresa.dominio.com.br.localdomain;

Então, basta mudar:

customer1.com IN CNAME customer1.mycompanydomain.com

Para

customer1.com IN CNAME customer1.mycompanydomain.com.

Vejo que o readytocloud.com está hospedado no Apache 2.2.

Há uma maneira muito mais simples e eficiente de redirecionar o site não www para o site www no Apache.

Adicione as seguintes regras de reescrita às configurações do Apache (dentro ou fora do host virtual. Não importa):

RewriteCond %{HTTP_HOST} ^readytocloud.com [NC]
RewriteRule ^/$ http://www.readytocloud.com/ [R=301,L]

Ou, as seguintes regras de reescrita se você quiser um mapeamento 1 para 1 de URLs do site não www para o site www:

RewriteCond %{HTTP_HOST} ^readytocloud.com [NC]
RewriteRule (.*) http://www.readytocloud.com$1 [R=301,L]

Observe, o módulo mod_rewrite precisa ser carregado para que isso funcione. Felizmente, o readytocloud.com está rodando em uma caixa CentOS, que por padrão carrega o mod_rewrite.

Temos um servidor cliente executando o Apache 2.2 com pouco menos de 3.000 domínios e quase 4.000 redirecionamentos, no entanto, a carga no servidor gira em torno de 0,10 a 0,20.

Graças a sipwiz e MrEvil. Desenvolvemos um script PHP que irá analisar a URL que o usuário inserir e colar wwwno topo dela. (por exemplo, se o cliente acessar kiragiannis.com , ele será redirecionado para www.kiragiannis.com ). Assim, nosso cliente aponta sua raiz (por exemplo, customer1.compara Aregistrar onde está nosso redirecionador da web) e, em seguida, www CNAMEpara o Aregistro real gerenciado por nós.

Abaixo o código caso você tenha interesse em nos futuramente.

<?php
$url = strtolower($_SERVER["HTTP_HOST"]);

if(strpos($url, "//") !== false) { // remove http://
  $url = substr($url, strpos($url, "//") + 2);
}

$urlPagePath = "";
if(strpos($url, "/") !== false) { // store post-domain page path to append later
  $urlPagePath = substr($url, strpos($url, "/"));
  $url = substr($url, 0, strpos($url,"/"));
}


$urlLast = substr($url, strrpos($url, "."));
$url = substr($url, 0, strrpos($url, "."));


if(strpos($url, ".") !== false) { // get rid of subdomain(s)
  $url = substr($url, strrpos($url, ".") + 1);
}


$url = "http://www." . $url . $urlLast . $urlPagePath;

header( "Location:{$url}");
?>