Por que vários registros PTR no DNS não são recomendados?

Eu muitas vezes ler que o uso de vários registros PTR em uma configuração de DNS não é recomendado.

No entanto, os motivos costumam ser vagos ou pouco óbvios:

"pode causar problemas",
"pode desencadear bugs em programas esperando uma resposta única": é problema do software, não é ?!
"pode tornar o pacote de resposta DNS muito grande": isso não é corrigido com o EDNS ?

Essas são boas razões? Você conhece outras razões (boas)? Tudo isso parece um "medo legado" ...

— Totor
fonte

Por que você deseja ter vários registros PTR para um único endereço IP? Não consigo pensar em uma razão que faria sentido.

— Por von Zweigbergk

@PervonZweigbergk Não foi o que eu pedi, mas por exemplo, porque tenho vários nomes apontando para o mesmo IP e quero que o inverso corresponda a todos eles.

— Totor

@PervonZweigbergk Imagine um servidor de correio que lida com correio para vários domínios. Você pode usar um nome no domínio para o qual está enviando mensagens no EHLOcomando. Certos destinatários exigem que você tenha um PTRregistro correspondente ao domínio em seu EHLOcomando, caso contrário, eles não aceitarão mensagens suas. Mas se você tiver vários PTRregistros, eles podem escolher um deles aleatoriamente e, se esse não corresponder ao EHLOcomando, ele rejeitará o correio.

— precisa saber é o seguinte

Sei que não foi o que você perguntou, e é por isso que perguntei isso por meio de um comentário, não como resposta. :-) Você nunca mencionou sobre qual aplicativo está falando. Você faria bem em ser mais explícito ao falar sobre o contexto dos emails enviados, que é o que @kasperd está especulando.

— Por Von Zweigbergk

@ Kasperd Suponho que alguém possa querer fazer isso, mas isso não é convencional e causa desnecessariamente a situação problemática de que se trata. Espera-se que um servidor de correio use apenas um único nome em seus EHLOcomandos, independentemente de quantos domínios ele lida com o correio. O nome em HELO/ EHLOé esperado para identificar o servidor de email em si, não se relacionam com os MAIL FROMou Frome-mail endereços.

— Håkan Lindqvist

Respostas:

A PTRficha de um nome inversa (por exemplo 7.2.0.192.in-addr.arpa) está prevista para identificar o nome canónica que está associado com esse endereço IP.

Os ponteiros de gateway nos nós da rede e os ponteiros de host normais nos nós de endereço completo usam o RR da PTR para apontar de volta para os nomes de domínio primário dos hosts correspondentes.

De: http://tools.ietf.org/html/rfc1035#section-3.5

Essa expectativa é refletida no software que faz pesquisas inversas; geralmente esse software espera especificamente um único nome de volta e espera poder usá-lo como um nome canônico para esse host. Se houver vários nomes retornados, é comum escolher apenas um aleatoriamente, porque eles não têm como saber qual você preferiria para essa ocasião específica.

Como a expectativa geral é que exista um nome canônico associado a um endereço IP e esse seja o nome que PTRdeve apontar, a adição de vários nomes geralmente não tem vantagem (nada espera que um registro aleatório A/ AAAAtenha uma correspondência PTR), mas tem um potencial desvantagem, pois pode causar resultados estranhos, pois você não tem controle sobre quais PTRregistros serão usados se você tiver adicionado mais de um.

Em essência, se você possui vários PTRregistros, na verdade, você não faz seu host parecer mais legítimo, mas o oposto, corre o risco de falhar em alguma validação ou quebrar algo.

Como uma metáfora talvez um tanto extrema, entregar cinco passaportes, todos com sua foto, mas com nomes diferentes no aeroporto, provavelmente não será recebido, assim como se você apenas entregasse um.

— Håkan Lindqvist
fonte

Elaboração de "um nome canônico": nos casos em que o endereço IP pode estar associado a mais de uma entidade, o mais específico é o preferido. No caso de um servidor da Web com vários hosts virtuais baseados em nome, o nome do servidor da Web é o mais apropriado. Esse é um daqueles casos em que tentar seguir o conselho dos RFCs informativos ( PTRsempre concordando com o Aregistro) é completamente inútil.

— Andrew B

"O registro PTR deve identificar": por quem? Parece uma regra de fato , pois os desenvolvedores de software começaram a considerar que apenas um PTR era a norma. Estou certo?

— Totor

@Totor Adicionou uma cotação e um link para uma fonte.

— Håkan Lindqvist

Como uma anedota, observou-se recentemente que a Apple possui alguns registros PTR com mais de 9k bytes de respostas. Sem dúvida eles não são os únicos. Este é um exemplo bastante extremo do que você pode ter quando as políticas obrigatórias de registro PTR não levam em consideração os detalhes desta resposta.

— Andrew B

Tudo se resume a um comportamento imprevisível, pois o RFC não impõe um limite ou uma maneira de lidar com esses registros PTR. A maioria das implementações escolherá round-robin e você não alcançará o resultado desejado (correspondência perfeita entre muitos nomes em um único IP).

Você pode ler mais sobre isso aqui: https://supernoc.rogerstelecom.net/pdfs/multiple-ptrs.pdf

Além disso, verifique esse bug na função getnameinfo do Glibc ( https://sourceware.org/bugzilla/show_bug.cgi?id=5790 ). Como você pode garantir que isso não esteja acontecendo no número infinito de sistemas diferentes na Internet (alguns deles muito antigos e sem patch)?

Para reforçar, como regra geral, é sempre bom evitar comportamentos não especificados e imprevisíveis. Infelizmente, vários registros PTR para um único IP se enquadram nessa categoria (no que diz respeito às RFCs).

— Giovanni Tirloni
fonte

Como você pode garantir que não ocorra nenhum problema no número "infinito" de sistemas diferentes na Internet? Sua resposta é boa, mas esse argumento não tem valor. Além disso, os bugs de clientes são IMHO irrelevantes, exceto se um número "significativo" deles for impactado.

— Totor

Como você garante que um PTR corresponda a um registro de encaminhamento específico se você tiver vários PTRs?

Isso é especialmente importante nas interações do servidor de correio, em que a maioria dos servidores SMTP receptores de entrada verificará se o encaminhamento corresponde ao inverso

Muito difícil é que você tenha vários PTRs e não há como garantir qual PTR está selecionado e que corresponde ao encaminhamento que você deu ao conectar

A maneira mais fácil de garantir uma combinação perfeita é ter um PTR que corresponda a uma entrada a frente

— user274768
fonte