¿Mi ISP ha destrozado mi registro de búsqueda inversa de DNS para una sola dirección IP estática?

26

Asumí la tarea de ejecutar un pequeño servidor de correo electrónico, y el mundo del spam lo hace más desafiante para una persona, ya que muchos MTA son muy paranoicos acerca de aceptar el correo electrónico.

Creo que he configurado casi todo lo que podría ser un problema con éxito: un certificado SSL comercial, DKIM, un dominio adecuado y una dirección IP estática. Mi correo electrónico (piddly) de hecho sale casi todo el tiempo. Pero los MTA más paranoicos siguen rechazando mi correo electrónico, por ejemplo, Craigslist , y parece que es mi búsqueda inversa la culpable.

Recientemente he cambiado mi dirección IP estática y mi servicio con mi ISP. Cuando lo cambiaron, intenté configurarlo correctamente, pero me temo que no. Pero no estoy 100% seguro de lo que está mal o de cómo debería verse mi registro inverso.

Especialmente no quiero acercarme a mi ISP con una actitud de "Mira, no sé cuál es el problema, pero debes solucionarlo de todos modos". Si hay un problema, quiero poder describir exactamente lo que es antes de hablar por teléfono con el NOC. Por lo que puedo decir, no ofrecen un panel de control para esto, por lo que no quiero probar la paciencia de nadie con un montón de prueba y error.

OK, los detalles, redactados y ficticios, pero consistentes:

Domain:                      funkeedomain.org
Mailserver (DNS MX record):  mx.funkeedomain.org
Static IP address:           111.222.333.444
Static IP address reversed:  444.333.222.111
FQDN originally requested of the ISP for reverse lookups: main.funkeedomain.org

Aquí hay un aviso de rechazo típico de mi servidor de correo (hMailServer):

Your message did not reach some or all of the intended recipients.

   Sent: Thu, 12 Jan 2017 11:53:50 -0800 (PST)
   Subject: Blah blah blah

The following recipient(s) could not be reached:

[email protected]
   Error Type: SMTP
   Remote server (64.235.154.109) issued an error.
   hMailServer sent: .
   Remote server replied: 550 permanent failure for one or more recipients ([email protected]:550 Sender IP reverse lookup rejected)

hMailServer

Un verificador comercial de envío de correo electrónico me dice:

main.funkeedomain.org.333.222.111.in-addr.arpa          Failed - No A Record Found in DNS

Entonces bien. ¿Qué me dicen las herramientas DNS?

stew@griffin:~$ host 111.222.333.444
444.333.222.111.in-addr.arpa domain name pointer main.funkeedomain.org.333.222.111.in-addr.arpa.

stew@griffin:~$ dig -x 111.222.333.444
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -x 111.222.333.444
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16150
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;444.333.222.111.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
444.333.222.111.in-addr.arpa. 86365 IN   PTR     main.funkeedomain.org.333.222.111.in-addr.arpa.

;; Query time: 0 msec
;; SERVER: 10.0.0.4#53(10.0.0.4)
;; WHEN: Thu Jan 12 19:09:11 PST 2017
;; MSG SIZE  rcvd: 93

Al leer ejemplos ( http://www.gettingemaildelivered.com/how-to-set-up-reverse-dns-rdns, por ejemplo), mi fuerte impresión es que esto está mal, y mi registro inverso establecido por mi ISP debería ser un PTR para "main.funkeedomain.org", NO "main.funkeedomain.org.333.222.111.in-addr.arpa".

¿Tengo razón al pensar esto? ¿Qué debería esperar en mi registro inverso si no es lo que estoy encontrando?


Gracias a todos los que respondieron, y mi editor de gramática post-post.

Las respuestas tanto de HBruijn como de Andrew B fueron correctas, pero parecen querer que seleccione las de HBruijn, que también es más corta, y así lo he hecho.

Tuve que llamar no menos de cinco veces para resolver esto. Tener un diagnóstico 100% exacto fue sin duda la clave para que esto pasara ciegamente 3 niveles de escalado con éxito: nunca se me permitió hablar directamente con el departamento de DNS.

Gracias a todos de nuevo.

StewLG
fuente
10
En general, con problemas de DNS, el uso del dominio real ayuda a la comunidad a resolver problemas con mucha más facilidad.
HBruijn
1
Google también verifica el registro PTR. No estoy seguro de por qué llamas a esto paranoico; detiene una gran cantidad de spam.
Michael Hampton
1
Se ha debatido mucho sobre el uso de dominios de ejemplo oficiales, no un nombre aleatorio. Dado que oculta la dirección IP, supongo que el nombre que usa tampoco es su dominio real.
JDługosz
xxxxxxxxxxxxxxx
StewLG

Respuestas:

33

444.333.222.111.in-addr.arpa. 86365 IN PTR main.funkeedomain.org.333.222.111.in-addr.arpa.

Parece que en los datos de la zona DNS inversa, alguien olvidó agregar un período final .a su nombre de host para indicar que es un nombre de host totalmente calificado. En la abreviatura de DNS, cualquier nombre de host simple se agrega con $ ORIGIN.

Los datos de zona correctos serían

444.333.222.111.in-addr.arpa. 86365 IN   PTR     main.funkeedomain.org.

o en DNS abreviado, opcionalmente puede omitir el $ORIGINie 333.222.111.in-addr.arpa:

444                           86365 IN   PTR     main.funkeedomain.org.
HBruijn
fuente
49

Mira la sección de respuestas un poco más de cerca:

;; ANSWER SECTION:
444.333.222.111.in-addr.arpa. 86365 IN   PTR     main.funkeedomain.org.333.222.111.in-addr.arpa.

Específicamente, el valor del registro PTR:

main.funkeedomain.org.333.222.111.in-addr.arpa.

Su ISP olvidó agregar el punto final a su FQDN. Esto está causando que el software DNS agregue el nombre del archivo de zona al final de los datos.

Dígales que vuelvan a mirar su registro DNS inverso, mencione el punto final y, si tienen algún sentido para ellos, sabrán exactamente lo que hicieron mal.

Andrew B
fuente
Si vienes de Hot Network Questions, vota a HBrujin en su lugar. Esta respuesta ya está en mi top 5 de todos los tiempos y se está volviendo un poco tonta. (@HBrujin, tu campaña de guerra psicológica para hacerme arrepentirme de responder esta pregunta 60 segundos antes de que estés trabajando)
Andrew B
Si cree que es malo, eche un vistazo a mis 5 respuestas principales en StackOverflow. Solo el # 2 es bastante interesante en mi humilde opinión.
Barmar
@ AndrewB Ya tengo privilegios de moderador, podrías tomar los puntos para que puedas obtener tus propios superpoderes de siguiente nivel a 20k
HBruijn
1

Además de corregir la entrada inversa (ver las respuestas de Andrew B y HBruijn), parece que sus entradas directas también pueden confundirse. Si el nombre de host del servidor es main.funkeedomain.org, tampoco debería tener mx.funkeedomain.org involucrado; en su lugar, debe tener un registro de tipo "MX" que señale desde funkeedomain.org a main.funkeedomain.org, y un registro "A" que señale desde main.funkeedomain.org a 111.222.333.444. Básicamente, desea que las búsquedas directas se vean así:

$ host -t mx funkeedomain.org
funkeedomain.org mail is handled by 10 main.funkeedomain.org.
$ host main.funkeedomain.org
main.funkeedomain.org has address 111.222.333.444

Los registros en su archivo de zona deberían verse así:

funkeedomain.org.       MX 10 main.funkeedomain.org.
main.funkeedomain.org.  A 111.222.333.444

O pueden tener el nombre de la zona (funkeedomain.org) implícito, indicado por un "." Final que falta. (como Andrew B sospecha que es el problema con el registro inverso), así:

     MX 10 main.funkeedomain.org.
main A 111.222.333.444

... o cualquier número de otras variantes.

Gordon Davisson
fuente
MX no es relevante aquí, ya que solo se trata del correo entrante. Para ser acogido como una fuente de correo saliente, el OP debe verificar que haya una coincidencia entre (1) el fqdn que su MTA emite como saludo EHLO, (2) el fqdn obtenido al buscar el DNS inverso de la IP que usa su MTA , y (3) la IP a la que se resuelve este problema en DNS reenviado. Para evitar confusiones, es mejor evitar múltiples PTR y / o múltiples registros A para el ip / fqdn involucrado ...
Hagen von Eitzen