Os registros do apex (ou raiz da zona) devem ter um registro de PTR / ponteiro correspondente

Question

Estou ciente de que os registros apex (registros na zona "root") podem ter registros PTR, mas freqüentemente vejo que os registros da raiz da zona não têm um PTR correspondente ou estão apontando para um local diferente do host associado registro.

Exemplo:

dig umich.edu @8.8.8.8; dig -x 141.211.243.251

(truncated for brevity)

;; ANSWER SECTION:
umich.edu.              709     IN      A       141.211.243.251

(truncated for brevity)

;; ANSWER SECTION:
251.243.211.141.in-addr.arpa. 1800 IN   PTR     www.umich.edu.

(truncated for brevity)

Razões para não ter um PTR:

1. Uma razão para não colocar um PTR é se você não for autoritário para as zonas de endereço. Por exemplo. Estou fazendo um ponto de registro A para um provedor de nuvem e Eu não posso usar um CNAME porque é uma raiz de região .
2. Outro motivo que eu poderia entender é se você está usando anycast para seus serviços DNS e pode não obter a mesma resposta (geográfica) lugar-a-lugar. O Google.com parece fazer isso.

Mas existe uma razão pela qual alguém deveria "nunca" ou "sempre" fazer isso além de uma exceção como a acima? Eu acho que deve sempre haver um PTR correto por padrão.

    

Answer 1

Eu vejo o argumento de Michael, pois acho que ele está se referindo aos domínios no namespace para lidar com o mapeamento reverso: in-addr.arpa e ip6.arpa . Dito isso, eu entendo no que você está chegando.

A pesquisa de DNS reverso (rDNS) de um domínio não precisa corresponder à pesquisa direta. Eu tenho um domínio em hospedagem compartilhada. Eu recebo o mesmo endereço IP de uma pesquisa direta do meu nome de domínio e www . Uma pesquisa de RDNS desse endereço IP retorna o servidor compartilhado:

23.168.192.in-addr.arpa. 14400 IN PTR foo.bar.example.com.

Como você está procurando práticas recomendadas, confira o rascunho da IETF Considerações para o uso do DNS Reverse Mapping . Vale a pena ler o documento inteiro. Aqui está um ponto particularmente importante:

Applications should not rely on reverse mapping for proper operation, although functions that depend on reverse mapping will obviously not
work in its absence. Operators and users are reminded that the use
of the reverse tree, sometimes in conjunction with a lookup of the
name resulting from the PTR record, provides no real security, can
lead to erroneous results and generally just increases load on DNS
servers. Further, in cases where address block holders fail to
properly configure reverse mapping, users of those blocks are
penalized.

E isso:

By recommending applications avoid using reverse mapping as a
security mechanism this document points out that this practice,
despite its use by many applications, is an ineffective form of
security. Applications should use better mechanisms of
authentication.

Espero que isso ajude.