La webZytrax.com, donde aprendí sobreDelegación de mapa inverso sin clases, dice que dig -x <ip address>se supone que no funciona en esto si se usa este método de delegación (usando CNAMES).
Por ejemplo:
Se supone que esto no funciona:
dig -x 192.168.23.66
Y se supone que esto funciona:
dig 66.64/27.168.192.IN-ADDR.ARPA
Y funciona cuando lo modifico un poco (especifica el servidor donde fue delegado y que quiero registro PTR):
dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA
Parece funcionar como se describe en el tutorial:
Configuré una delegación similar y se comporta como se describe arriba: cuando uso dig -xuna dirección IP del rango delegado, el servidor de nombres delegado me dice quién tiene autoridad sobre 66.64/27.168.192.IN-ADDR.ARPA.el servidor donde se delegó la red sin clases funciona solo con el tercer comando ( dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA) .
¿Está bien y es seguro?
Como no funciona con dig -x (o nslookup), me pregunto si hay más cosas que no funcionan. ¿Pueden los solucionadores resolver dichas direcciones IP sin problemas? Por ejemplo, ¿pueden los servidores de correo electrónico realizar búsquedas inversas sin problemas si se utiliza este método de delegación? ¿Hay alguna razón por la que no usarlo?
mi ejemplo(ligeramente modificado):
dig @ns1.example.com -x 192.168.134.1
;; ANSWER SECTION:
1.134.168.192.in-addr.arpa. 60 IN CNAME 1.0-127.134.168.192.in-addr.arpa.
;; AUTHORITY SECTION:
0-127.192.113.134.in-addr.arpa. 10 IN NS ns2.example.com.
dig @ns2.example.com PTR 1.0-127.192.168.134.in-addr.arpa.
;; ANSWER SECTION:
1.0-127.192.168.192.in-addr.arpa. 10 IN PTR 1st_super.example.com.
Por qué no funcionó
El nombre de la zona a la que delegé era incorrecto y como usé el nombre incorrecto en la segunda consulta, obtuve respuesta (los dos errores se anularon parcialmente).
Incorrecto (no invertido):
0-127.192.168.134.in-addr.arpa.
debería haber sido:
0-127.134.168.192.in-addr.arpa.
Con este error solucionado y con el servidor delegado como esclavo para la zona delegada, todo dig -x <ipaddress>funciona.
Respuesta1
TL;DR
Si creas unRFC2317-Estilo de delegación in-addr.arpa sin clases, es completamente normal que no pueda consultar el servidor de nombres autorizado para la subdelegación directamente con la asignación inversa de la dirección IP.
Lo que realmente importa es que un servidor de resolución pueda buscar el nombre inverso (por ejemplo dig -x 192.0.2.1 @8.8.8.8, cualquier combinación de dirección IP y servidor de resolución que sea relevante en su entorno/caso de uso).
Explicación RFC2317
El problema general para el que RFC2317 proporciona una especie de solución alternativa es cómo el mapeo basado en convenciones de la dirección IPv4 al nombre inverso en DNS (por ejemplo, - 192.0.2.1> 1.2.0.192.in-addr.arpa) es anterior a las delegaciones sin clases y bloquea efectivamente los posibles puntos de delegación a /0, /8, 16, /24. /32(Sólo se puede delegar en cada etiqueta, y la asignación se define para simplemente convertir cada octeto de la dirección IPv4 en una etiqueta, en orden inverso).
La asignación se habría tenido que definir de manera diferente, asignando algún esquema de nomenclatura más detallado. permitir realmente algo así como una /27delegación.
RFC2317 NO cambia la situación fundamental, en realidad no cambia el protocolo de ninguna manera.
Todo lo que hace es sugerir un esquema que los operadores humanos puedan utilizar para solucionar la limitación de que las delegaciones sin clases no son posibles.
Ese esquema se puede resumir como:
- Usted define alias (agrega
CNAMEregistros) para algún conjunto de nombres en la zona inversa real (de acuerdo con la convención de nomenclatura), asignándolos a nuevos nombres en unnuevo espacio de nombres
(El nuevo espacio de nombres realmente puede tenercualquiernombre, pero RFC2317 sugiere usar un nombre descriptivo y tener el nuevo espacio de nombres como hijo de su zona existente en algún lugar debajoin-addr.arpa) - Delegas la zona correspondiente a estenuevo espacio de nombressegún sea necesario
El resultado es que un servidor de resolución al que se le pide que busque 1.2.0.192.in-addr.arpasimplemente lo hará normalmente y se encontrará con ese CNAMEregistro en lugar del PTRque realmente estaba buscando.
Luego simplemente sigue el CNAMEen el nuevo espacio de nombres sin necesidad de ningún conocimiento de RFC2317, incluso si existe, y si las cosas se configuraron como lo sugiere RFC2317, encontrará un PTRque puede usar con ese nuevo nombre.
Si, por ejemplo, tuvieras una 2.0.192.in-addr.arpa.zona ns1.other.example.que incluyera esto:
1.2.0.192.in-addr.arpa. IN CNAME 1.0/27.2.0.192.in-addr.arpa.
0/27.2.0.192.in-addr.arpa. IN NS ns7.example.com.
El proceso de búsqueda del nombre inverso real ( 1.2.0.192.in-addr.arpa.) daría como resultado el CNAME, y el solucionador simplemente lo manejaría CNAMEnormalmente, siguiéndolo a donde conduzca.
En este ejemplo, lleva a 1.0/27.2.0.192.in-addr.arpa., y también hay una delegación para la zona 0/27.2.0.192.in-addr.arpa.a ns7.example.com., por lo que el solucionador puede simplemente continuar el proceso de búsqueda de la zona.nuevo nombrey todo saldrá bien.
1.2.0.192.in-addr.arpa.Si, por el contrario, le enviaras una consulta, ns7.example.com.no sabrá nada al respecto.
ns7.example.com. no estiene la zona inversa para esa dirección, solo tiene una zona vagamente relacionada a la que la zona inversa real se refiere mediante estos alias.
Para comprobar que una delegación de estilo RFC2317 funciona, en primer lugar, puede comprobar si un solucionador real logra buscar los nombres.
Pero, profundizando en los detalles, verificaría con qué responde el servidor de nombres para la zona inversa real (debería ser un CNAMEen este caso), verificaría dónde CNAMEse delega el nombre canónico (el "objetivo") y luego verificaría si ese servidor de nombres responde. según lo previsto para el nombre canónico según lo especificado en el CNAMEregistro.