Saltar para o conteúdo
Networks

Blog

DNS reverso para espaço IP alugado: registos PTR, delegação e email

Última atualização a RTM NetworksTraduzido do inglês. Ler o original

O DNS reverso faz corresponder um endereço IP a um nome, através de um registo PTR. Para a maioria dos serviços, é um pormenor. Para um servidor de email, não é: a Google exige que cada endereço que envia para o Gmail tenha um registo PTR cujo nome resolva de volta para o mesmo endereço, e muitos outros recetores procuram a mesma correspondência. Com espaço alugado, o registo está numa zona que, por omissão, não controla, por isso convém saber quem o configura e como.

Como funciona o DNS reverso

Uma consulta direta transforma um nome num endereço. Uma consulta inversa transforma um endereço num nome, invertendo os seus quatro números sob um domínio especial: o registo PTR de 203.0.113.10 está em 10.113.0.203.in-addr.arpa. O IPv6 funciona da mesma forma sob ip6.arpa, um dígito hexadecimal de cada vez.

A zona de um /24, 113.0.203.in-addr.arpa neste exemplo, é delegada pelo registo nos servidores de nomes indicados para ela. Na região de serviço do RIPE NCC, são as linhas nserver de um objeto domain na RIPE Database. Quem gere esses servidores de nomes decide o que dizem os registos PTR.

Shell
dig -x 203.0.113.10 +short

Quem o controla no espaço alugado

O registo delega a zona inversa no titular do bloco, pelo que, no espaço alugado, é o locador, e não o cliente. Na prática há duas formas.

  • O locador configura os registos que pede. Envia o nome de cada endereço, e o locador publica os registos PTR. É a forma mais simples e basta para quase toda a gente.
  • O locador delega-lhe a zona. Com um objeto domain a apontar para os seus servidores de nomes, gere os registos PTR por si. Isso funciona para um /24 inteiro. Para uma parte menor, o locador pode entregar-lhe apenas os seus endereços com a delegação classless descrita no RFC 2317: registos CNAME na zona dele que apontam para uma zona nos seus servidores de nomes.

Em qualquer dos casos, pergunte antes de o aluguer começar como se fazem as alterações e com que rapidez aparecem, porque um servidor de email a que não pode dar um nome adequado é um servidor de email que não entrega.

O que os recetores de email verificam

As diretrizes da Google para remetentes explicitam a regra para todos os remetentes, não só os de envios em massa: "The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname." (tradução: «O endereço IP público de um servidor SMTP de envio tem de ter um registo PTR correspondente que resolva para um nome de anfitrião.») Esse nome de anfitrião tem por sua vez de ter um registo A, ou AAAA para IPv6, que resolva para o mesmo endereço. Isto é DNS reverso com confirmação direta: do endereço para o nome, e do nome de volta para o mesmo endereço. O Gmail responde a um registo em falta ou não correspondente com um erro temporário ou permanente, e aplica as suas regras de forma mais rigorosa desde novembro de 2025.

Dois hábitos acompanham isto. Use o mesmo nome na saudação que o seu servidor de email envia (HELO ou EHLO), e escolha nomes que pareçam um servidor e não um pool. O Yahoo, que exige DNS reverso de todos os remetentes, pede registos PTR "meaningful, non-generic" (tradução: «significativos, não genéricos»), e alguns filtros tratam um nome como 203-0-113-10.dynamic.example.net como sinal de uma ligação doméstica.

Configurá-lo, passo a passo

  1. Escolha um nome por endereço de envio, num domínio que controla: mail1.example.com.
  2. Crie o registo direto: mail1.example.com. A 203.0.113.10.
  3. Configure o registo PTR: 10.113.0.203.in-addr.arpa. PTR mail1.example.com., através do seu locador ou na sua zona delegada.
  4. Verifique os dois sentidos a partir de uma rede fora da sua:
Shell
dig -x 203.0.113.10 +short        # expect: mail1.example.com.
dig +short mail1.example.com A    # expect: 203.0.113.10
  1. Faça o servidor de email usar o mesmo nome. No Postfix, é myhostname = mail1.example.com.

Erros que estragam a entrega

  • Um registo PTR sem registo A correspondente. A consulta inversa funciona e a verificação direta falha.
  • Dois registos PTR para um endereço. As verificações discordam sobre qual conta. Mantenha um.
  • Uma mudança de nome com um TTL longo. Os resolvers continuam a servir o nome antigo até o TTL expirar. Baixe-o um dia antes de uma alteração planeada.
  • O IPv6 esquecido. Se o servidor envia por IPv6, o seu endereço IPv6 precisa do mesmo tratamento sob ip6.arpa, com um registo AAAA correspondente.
  • Uma zona delegada em servidores de nomes que deixam de responder. O registo só verifica os servidores de nomes quando a delegação é feita. Se falharem mais tarde, todas as consultas inversas do bloco falham com eles.

Onde entra a RTM Networks

O DNS reverso faz parte de todos os alugueres sem custo adicional: indique-nos o nome de cada endereço e configuramos os registos PTR (alugar IPv4). Se os endereços vão enviar email, a sua reputação importa tanto como os seus nomes, por isso verificamos todos os blocos IPv4 que alugamos contra blocklists antes da entrega e todos os dias enquanto os tiver (manter um bloco limpo).

Contacto

Precisa de aconselhamento para a sua situação?

Este artigo é geral; a sua rede não é. Diga-nos com o que está a trabalhar e analisamos o caso com atenção. Normalmente respondemos em 1 a 3 horas úteis.

Contacte-nos