lunes, 25 de mayo de 2015

Comprobar la delegación de DNS inversa

El nombre más exacto sería Delegación IN-ADDR.ARPA sin clase, pero el que tiene por ahora tiene como más mejor posicionamente en buscadores, y es la forma en que la mayoria del mundo lo conoce.

La idea es que la resolución inversa DNS suele estar fuertemente asociada a los ISP que administran las IP que se han de resolver. Sin embargo, en ocasiones puede ser bastante engorroso tener que consultar con ellos los cambios en nuestras entradas DNS, sobre todo cuando son demasiadas.

Después de las gestiones administrativas necesarias, es posible que nos delegue la resolución inversa para una red sin clase, básicamente, las direcciones IP públicas que nos han sido proporcionadas.

Las comprobaciones pueden ser un poco tediosas, pero son sumamente necesarias para garantizar que todo esté funcionando como es debido. Si bien no hay una especie de fórmula mágica para este caso, es posible establecer una especie de pasos a seguir para comprobar que todo esté funcionando perfectamente

  • Puede obtener los servidores DNS de su proveedor, usualmente preguntandole, sino, puede intentar a buscar los servidores dados para su dominio, en ese caso, proveedor.com
    Una comprobación exhaustiva requiere que se revise cada uno de los servidores DNS que aparecen como respuesta. Un DNS de su proveedor que no tenga los registros actualizados hará que los registros que se propagan por internet tengan errores.
dig NS proveedor.com +noall +additional
; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> NS proveedor.com +noall +additional
;; global options: +cmd
ns.proveedor.net.         35430    IN    A    200.1.2.3
ns.proveedor9.net.        35027    IN    A    200.1.2.4  

  • Luego, hay que comprobar que los servidores DNS del proveedor no pueda resolver la entrada PTR para nuestras IP, como normalmente haría, sino que frente a las consultas DNS devuelva un CNAME que ha de enviar a la autoridad para esas IP, que ya debe estar señalada como nuestros servidores DNS. Usaremos una ip 200.1.2.130, que debe estar dentro del rango de IP públicas de las que el proveedor nos transfiere la autoridad.
dig @200.1.2.3 -x 200.1.2.130 +norecurse +noall +answer +authority +comment
; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> @200.1.2.3 -x 200.1.2.130 +norecurse +noall +answer +authority +comment
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16232
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; ANSWER SECTION:
130.2.1.200.in-addr.arpa. 86400 IN    CNAME    130.128-254.2.1.200.in-addr.arpa.

;; AUTHORITY SECTION:
128-254.2.1.200.in-addr.arpa. 86400 IN NS    ns1.institucion.com.
128-254.2.1.200.in-addr.arpa. 86400 IN NS    ns2.institucion.com.


Podemos obtener la forma actual del registro PTR viendo el CNAME que el servidor de nuestro proveedor devuelve en la sección ANSWER en la respuesta de la consulta anterior, pero bien puede verlo más claro con el siguiente comando
dig @200.1.2.3 -x 200.1.2.130 +norecurse +short
130.128-254.2.1.200.in-addr.arpa.
Dado que nuestros servidores DNS resuelven la reversa en base a la forma en que el servidor de su proveedor se las tranfiere, (Vea el CNAME que el servidor DNS de su proveedor ha devuelto), tenga en cuenta que su servidor ya no puede resolver ninguna de las siguientes consultas
dig @ns1.institucion.com PTR 130.2.1.200.in-addr.arpa

dig @ns1.institucion.com -x 200.1.2.130
que son con las que normalmente haría una comprobación de este tipo, pero tome en cuenta que cualquier otro servidor debe ser capaz de obtener respuestas de las mismas
dig @8.8.8.8 -x 200.1.2.130 +short
130.128-254.2.1.200.in-addr.arpa.
mail.salud.gob.sv.

dig @8.8.8.8 PTR 130.2.1.200.in-addr.arpa +short
130.128-254.2.1.200.in-addr.arpa.
mail.salud.gob.sv.
Para resolver correctamente en sus servidores DNS, debe hacer la consulta PTR igual al CNAME devuelto por los DNS de su proveedor. Lo que significa que usted ha configurado según parámetros del proveedor.
dig @ns1.institucion.com 130.128-254.2.1.200.in-addr.arpa
correo.institucion.com.

  • Una de las pruebas más exhaustivas para empezar a revisar el problema desde un principio es hacer un dig +trace, ya que el resultado especifica el final de cada bloque, en la línea que empieza por Received x bytes… el servidor que responde por dicho bloque, así que puede rastrear si algún servidor están enviando resultados erróneos.
dig @8.8.8.8 -x 200.31.169.130 +trace +nodnssec

; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> @8.8.8.8 -x 200.31.169.130 +trace +nodnssec
; (1 server found)
;; global options: +cmd
.            19272    IN    NS    a.root-servers.net.
.            19272    IN    NS    l.root-servers.net.
.            19272    IN    NS    m.root-servers.net.
.            19272    IN    NS    j.root-servers.net.
.            19272    IN    NS    f.root-servers.net.
.            19272    IN    NS    i.root-servers.net.
.            19272    IN    NS    e.root-servers.net.
.            19272    IN    NS    g.root-servers.net.
.            19272    IN    NS    h.root-servers.net.
.            19272    IN    NS    d.root-servers.net.
.            19272    IN    NS    c.root-servers.net.
.            19272    IN    NS    k.root-servers.net.
.            19272    IN    NS    b.root-servers.net.
;; Received 239 bytes from 8.8.8.8#53(8.8.8.8) in 31 ms

in-addr.arpa.        172800    IN    NS    e.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    a.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    c.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    d.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    f.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    b.in-addr-servers.arpa.
;; Received 432 bytes from 192.33.4.12#53(c.root-servers.net) in 63 ms

200.in-addr.arpa.    86400    IN    NS    a.arpa.dns.br.
200.in-addr.arpa.    86400    IN    NS    ns.lacnic.net.
200.in-addr.arpa.    86400    IN    NS    ns2.lacnic.net.
200.in-addr.arpa.    86400    IN    NS    ns3.afrinic.net.
200.in-addr.arpa.    86400    IN    NS    sec1.authdns.ripe.net.
200.in-addr.arpa.    86400    IN    NS    sec3.apnic.net.
200.in-addr.arpa.    86400    IN    NS    tinnie.arin.net.
200.in-addr.arpa.    86400    IN    NS    ns-lacnic.nic.mx.
;; Received 267 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 174 ms

2.1.200.in-addr.arpa. 86400    IN    NS    NS.PROVEEDOR.NET.
;; Received 83 bytes from 204.61.215.62#53(ns3.afrinic.net) in 120 ms

130.2.1.200.in-addr.arpa. 86400 IN    CNAME    130.128-254.2.1.200.in-addr.arpa.
128-254.2.1.200.in-addr.arpa. 86400 IN NS    ns1.institucion.com.
128-254.2.1.200.in-addr.arpa. 86400 IN NS    ns2.institucion.com.
;; Received 162 bytes from 200.1.2.3#53(NS.PROVEEDOR.NET) in 2 ms

(1) Fuente
(2) Fuente

No hay comentarios:

Publicar un comentario en la entrada

Otros apuntes interesantes

Otros apuntes interesantes