Um CNAME pode ser um nome de host

2

Esta é uma questão teológica, mas mesmo assim ...

Assim, um servidor tem um nome de host, digamos que o fqdn é hostname.example.com (para ser realmente preciso sobre o que quero dizer, este é o nome que está definido em /etc/sysconfig/network ).

O mesmo servidor tem várias interfaces em diferentes sub-redes. Digamos que os IPs sejam 10.0.0.1 e 10.0.1.1.

Agora a questão é, teoricamente (veja bem, isso é importante, eu sei que praticamente funciona, mas estou interessado em respostas puramente acadêmicas) permitido ter a seguinte configuração:

interface1.example.com. IN A 10.0.0.1
interface2.example.com. IN A 10.0.1.1
hostname.example.com. IN CNAME interface1.example.com.

OU deveria ser:

hostname.example.com. IN A 10.0.0.1
interface2.example.com. IN A 10.0.1.1
interface1.example.com. IN CNAME hostname.example.com.

Eu acho que é óbvio qual deles está fazendo mais sentido a partir do POV de gerenciamento / administração, mas é tecnicamente correto?

O argumento contra a primeira configuração é que uma pesquisa inversa para 10.0.0.1 retorna interface1.example.com e não o que se poderia esperar (ou seja, o nome do host: hostname.example.com ), portanto a solicitação direta e então as pesquisas inversas sequenciais retornariam resultados diferentes.

Agora, como eu disse, quero uma resposta teórica. Links para seções RFC etc, que explicitamente permitem ou não o uso do nome CNAME como um nome de host. Se não houver nenhum, tudo bem também, eu só preciso confirmar. Eu não consegui encontrar nenhuma declaração explícita até agora, bar este livro , onde esta situação é dada como um exemplo e implica que isso pode ser feito como uma das maneiras de evitar registros MX apontando para um CNAME.

UPDATE: Múltiplas interfaces não são para redundância (de qualquer maneira, são obrigações), mas para conseguir uma separação lógica no tráfego. Por exemplo, todo o tráfego de banco de dados está na sub-rede A, o tráfego de serviços está na sub-rede B e o acesso público está na sub-rede C.

UPDATE2: Parece que isso não é regulado por RFCs / outras regras e é uma questão de preferência. Por isso, marcarei a resposta @Vatine como a resposta viável por agora, o que implica que não há regulamentos. Também muito obrigado ao @Alnitak por sugestões e discussão!

    
por rytis 31.03.2010 / 09:29

3 respostas

6

Eu diria que não há nenhuma conexão entre os registros no DNS e o que um servidor informa seu nome, portanto, do ponto de vista do DNS, a única diferença entre seus dois cenários é o nome que vai para onde.

Do ponto de vista da máquina, não se importa. No entanto, do ponto de vista de seus usuários, eu escolheria um dos dois e depois ficaria com ele.

    
por 31.03.2010 / 10:12
3

Em geral, o nome do host deve ser um registro A , pois há lugares onde não é permitido usar CNAME quando esse nome de host é referido em outros registros DNS (por exemplo, o caso de registro MX que você forneceu) .

Por que vale a pena, eu gostaria de saber o que você está tentando alcançar tendo várias interfaces?

Se eles fornecerem redundância, um método melhor do que publicar o endereço IP de um endereço físico específico é configurar um endereço IP público em uma interface "virtual" (ou loopback). Em seguida, use os protocolos de roteamento (por exemplo, OSPF) para garantir que o tráfego para o endereço possa usar uma interface física.

O que você pode conseguir é:

$ORIGIN example.com
@       IN SOA (...)
en0.server IN A 10.0.0.1
en1.server IN A 10.0.1.1
lo1.server IN A 192.168.1.1
www        IN CNAME lo1.server

Isso garante a resiliência, garantindo que o endereço IP público anunciado seja atingido mesmo que uma das interfaces físicas caia.

update: como isso é para separação de tráfego, eu pessoalmente tornaria o nome de host nulo um registro A apontando para a interface pública (já que esse é o mundo externo) e depois separar A registros para as duas interfaces internas.

    
por 31.03.2010 / 12:08
-1

Eu colocaria desta maneira: um IN CNAME requer duas consultas DNS, um IN A requer uma única consulta DNS.

Pessoalmente, não gosto de IN CNAMEs e uso apenas IN A

    
por 31.03.2010 / 09:44