Network Working Group H. Eidnes Petición de Comentarios: 2317 SINTEF RUNIT BCP: 20 G. de Groot Categoría: Mejor práctica actual Berkeley Software Design, Inc. P. Vixie Internet Software Consortium Marzo 1998 Delegación IN-ADDR.ARPA sin clase Estado de este memorándum Este documento presenta para su debate y comentarios por parte de la comunidad de internet una "Mejor práctica actual". La distribución de este memorándum no está limitada. Nota de Copyright Copyright (C) The Internet Society (1998). Todos los derechos reservados. 1. Introducción Este documento describe una forma de hacer la delegación IN-ADDR.ARPA en limites diferentes a un octeto para cubrir espacios de direcciones menores de 256 direcciones. El método propuesto debería así, eliminar una de las objeciones a las subredes en limites diferentes a un octeto pero quizás mas significativamente, hace posible el asignar un espacio de direcciones IP en pedazos más pequeños que los prefijados de 24-bit, sin perder la habilidad de delegar la autoridad para los correspondientes mapeos IN-ADDR.ARPA. El método propuesto es totalmente compatible con los mecanismos originales de búsqueda de DNS especificados en el rfc1034 [1], p.e. no hay necesidad de modificar el algoritmo de búsqueda usado, y no es necesario modificar ningún software que haga búsquedas de DNS. Este documento también debate algunas consideraciones operacionales para suministrar alguna guia en la implementación de este método. 2. Motivación Con la proliferación de tecnologías de Classless routing [enrutado sin clase], ha llegado a ser factible asignar un espacio de direcciones en limites diferentes a un octeto. En el caso de una organización muy pequeña con sólo unos pocos hosts, asignar un prefijo completo de 24-bit (que era referido como un "numero de red de clase C") a menudo llevaba a una utilización ineficiente del espacio de direcciones. Eidnes, et al. Mejor práctica actual [Pág. 1] RFC 2317 Delegación IN-ADDR.ARPA sin clase Marzo 1998 Uno de los problemas encontrados cuando asignamos un prefijo más largo (menos espacio de direcciones) es que parece imposible para tal organización el mantener su propia zona inversa ("IN-ADDR.ARPA") autónomamente. Con el uso del método de delegación inversa descrito abajo, la objeción más importante en contra de la asignación de prefijos largos a organizaciones sin relación puede ser apartada. Vamos a asumir que tenemos asignados los espacios de direcciones a tres partes diferentes como sigue a continuación: 192.0.2.0/25 para la organización A 192.0.2.128/26 para la organización B 192.0.2.192/26 para la organización C En el planteamiento clásico, esto puede llevar a una única zona como esta: $ORIGIN 2.0.192.in-addr.arpa. ; 1 PTR host1.A.domain. 2 PTR host2.A.domain. 3 PTR host3.A.domain. ; 129 PTR host1.B.domain. 130 PTR host2.B.domain. 131 PTR host3.B.domain. ; 193 PTR host1.C.domain. 194 PTR host2.C.domain. 195 PTR host3.C.domain. La administración de esta zona es problemática. La autoridad para esta zona solo puede ser delegada una vez y esto normalmente se traduce en que "esta zona solo puede ser administrada por una organización." Las otras organizaciones con el espacio de direcciones que corresponde a los accesos en esta zona les hará así, tener que depender de otra organización para sus traducciones de direcciones a nombres. Con el método propuesto, este potencial problema puede ser anulado. 3. Delegación IN-ADDR.ARPA Classless Empezando con que una única zona puede ser delegada solo una vez, necesitamos más señales para hacer delegación de tal forma que se resuelva el problema de arriba. Estas señales extra de delegación pueden ser introducidas extendiendo el árbol IN-ADDR.ARPA de arriba a abajo, e.g. usando la primera dirección o la primera dirección y la longitud de la mascara de red (como se muestra abajo) en el espacio Eidnes, et al. Mejor práctica actual [Pág. 2] RFC 2317 Delegación IN-ADDR.ARPA sin clase Marzo 1998 de direcciones correspondiente hasta formar el primer componente en el nombre para las zonas. Los siguientes cuatro ficheros de zona muestran como el problema de la sección Motivación puede ser solucionado usando este método. $ORIGIN 2.0.192.in-addr.arpa. @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...) ;... ; <<0-127>> /25 0/25 NS ns.A.domain. 0/25 NS some.other.name.server. ; 1 CNAME 1.0/25.2.0.192.in-addr.arpa. 2 CNAME 2.0/25.2.0.192.in-addr.arpa. 3 CNAME 3.0/25.2.0.192.in-addr.arpa. ; ; <<128-191>> /26 128/26 NS ns.B.domain. 128/26 NS some.other.name.server.too. ; 129 CNAME 129.128/26.2.0.192.in-addr.arpa. 130 CNAME 130.128/26.2.0.192.in-addr.arpa. 131 CNAME 131.128/26.2.0.192.in-addr.arpa. ; ; <<192-255>> /26 192/26 NS ns.C.domain. 192/26 NS some.other.third.name.server. ; 193 CNAME 193.192/26.2.0.192.in-addr.arpa. 194 CNAME 194.192/26.2.0.192.in-addr.arpa. 195 CNAME 195.192/26.2.0.192.in-addr.arpa. $ORIGIN 0/25.2.0.192.in-addr.arpa. @ IN SOA ns.A.domain. hostmaster.A.domain. (...) @ NS ns.A.domain. @ NS some.other.name.server. ; 1 PTR host1.A.domain. 2 PTR host2.A.domain. 3 PTR host3.A.domain. $ORIGIN 128/26.2.0.192.in-addr.arpa. @ IN SOA ns.B.domain. hostmaster.B.domain. (...) @ NS ns.B.domain. @ NS some.other.name.server.too. ; 129 PTR host1.B.domain. 130 PTR host2.B.domain. Eidnes, et al. Mejor práctica actual [Pág. 3] RFC 2317 Delegación IN-ADDR.ARPA sin clase Marzo 1998 131 PTR host3.B.domain. $ORIGIN 192/26.2.0.192.in-addr.arpa. @ IN SOA ns.C.domain. hostmaster.C.domain. (...) @ NS ns.C.domain. @ NS some.other.third.name.server. ; 193 PTR host1.C.domain. 194 PTR host2.C.domain. 195 PTR host3.C.domain. Para cada pedazo de 256 de tamaño dividido usando este método, existe la necesidad de instalarse cerca de 256 registros CNAME en la zona principal. Algunas personas podrán ver esto como feo; no vamos a argumentar ese particular punto de vista. Es, sin embargo, muy fácil generar automáticamente el registro de recursos CNAME en la zona principal una vez y para todos, si es conocida la forma en que el espacio de direcciones es particionado. La ventaja de este método con respecto a otros propuestos para tratar este problema es que no hay necesidad de modificar el software existente. En particular, el mecanismo de lookup en el DNS no tiene que ser modificado para acomodarse a esta división de la responsabilidad para la traducción de la dirección IPv4 a su nombre en limites "sin punto". Además, esta técnica ha estado en uso durante varios años en muchas instalaciones, aparentemente sin efectos secundarios. Como es normal, un registro de recursos como este $ORIGIN 2.0.192.in-addr.arpa. 129 CNAME 129.128/26.2.0.192.in-addr.arpa. puede ser abreviado convenientemente a $ORIGIN 2.0.192.in-addr.arpa. 129 CNAME 129.128/26 Algunas implementaciones DNS no son amables con los caracteres especiales en los nombres de dominios, p.e. el "/" usado en los ejemplos anteriores. Como RFC2181 [3] deja claro, estos son legales aunque alguno pueda parecer feo. Como estos no son nombres de host la restricción del RFC952 [2] no se les aplica. Los clientes modernos y servidores tienen una opción para actuar en la forma liberal y correcta. Los ejemplos aquí usan "/" porque esto parece ser más visible y los Eidnes, et al. Mejor práctica actual [Pág. 4] RFC 2317 Delegación IN-ADDR.ARPA sin clase Marzo 1998 críticos pedantes sentían que el argumento "estos no son hostnames" necesitaba ser repetido. Le aconsejamos que no sea así de pedante, y que no copie igual los ejemplos de arriba, p.ej. substituya por un carácter más conservador, como un guión, el "/". 4. Consideraciones operacionales Esta técnica pretende ser usada para cubrir delegaciones de espacios de direcciones menores de 256 direcciones. Para cubrir delegaciones de grandes bloques de direcciones los métodos tradicionales (delegaciones múltiples) pueden, en cambio, ser usados. 4.1 Servicio de nombres secundario recomendado Algunas versiones antiguas del software del servidor de nombres no necesitaran esforzarse para encontrar y devolver el nombre solicitado en los registros CNAME si el nombre solicitado no es conocido localmente todavía en la cache o como dato con autoridad. Esto puede causar alguna confusión en los resolutores, como solamente el registro CNAME sera devuelto en la respuesta. Para eliminar este problema se recomienda que los servidores de nombres con autoridad para la zona delegada (la zona que contiene todos los registros CNAME) funcionen como servidores de nombres esclavos (secundarios) para las zonas "hijas" delegadas y señaladas en el mediante los registros CNAME. 4.2 Convenciones de nombramiento alternativas Como resultado de este método, la localización de la zona que contiene los registros PTR actuales no vuelve a ser predefinida. Esto da flexibilidad y algunos ejemplos serán presentados aquí. Una alternativa a usar la primera dirección, o la primera dirección y la longitud de la mascara de red en el correspondiente espacio de direcciones, para nombrar las nuevas zonas es usar algún otro nombre (no numérico). Así también es posible apuntar hacia a una parte totalmente diferente del árbol DNS (p.j. fuera del árbol IN- ADDR.ARPA). Esto seria necesario para usar uno de los métodos alternativos si de algún modo dos organizaciones compartieran la misma subred física (y el correspondiente espacio de direcciones IP) sin una "aseada" alineación de las direcciones, pero queriendo todavía administrar sus propios mapeos IN-ADDR.ARPA. Eidnes, et al. Mejor práctica actual [Pág. 5] RFC 2317 Delegación IN-ADDR.ARPA sin clase Marzo 1998 En el siguiente pequeño ejemplo se muestra como puede apuntar fuera del árbol IN-ADDR.ARPA: $ORIGIN 2.0.192.in-addr.arpa. @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...) ; ... 1 CNAME 1.A.domain. 2 CNAME 2.A.domain. ; ... 129 CNAME 129.B.domain. 130 CNAME 130.B.domain. ; $ORIGIN A.domain. @ IN SOA my-ns.A.domain. hostmaster.A.domain. (...) ; ... ; host1 A 192.0.2.1 1 PTR host1 ; host2 A 192.0.2.2 2 PTR host2 ; etc. De esta forma usted puede realmente acabar con el mapeo de datos nombre->dirección y el (indicando-hacia) dirección->nombre en el mismo fichero de zona - algunos pueden ver esto como un bonus añadido como es requerido un conjunto no separado de secundarios para la zona inversa. Fijese sin embargo que el cruzado vía árbol IN-ADDR.ARPA seguirá haciéndose, así los registros CNAME insertados allí necesitan apuntar en la dirección correcta para que esto funcione. Eidnes, et al. Mejor práctica actual [Pág. 6] RFC 2317 Delegación IN-ADDR.ARPA sin clase Marzo 1998 El boceto de abajo es un método alternativo usando la misma solución: $ORIGIN 2.0.192.in-addr.arpa. @ SOA my-ns.my.domain. hostmaster.my.domain. (...) ; ... 1 CNAME 1.2.0.192.in-addr.A.domain. 2 CNAME 2.2.0.192.in-addr.A.domain. $ORIGIN A.domain. @ SOA my-ns.A.domain. hostmaster.A.domain. (...) ; ... ; host1 A 192.0.2.1 1.2.0.192.in-addr PTR host1 host2 A 192.0.2.2 2.2.0.192.in-addr PTR host2 Esta claro que existen muchas posibilidades que pueden ser adaptadas a mano a los requerimientos específicos de la situación. 4.3 Otras cuestiones operacionales Observe que no se puede facilitar dos veces referencias CNAME para el mismo espacio de direcciones, p.e. usted no puede asignar un prefijo /25 a una organización, y ejecutar el IN-ADDR.ARPA de esta forma, y entonces tener la subnet de la organización el /25 en prefijos mas largos, y intentar emplear la misma técnica para dar el control a cada subnet de su propio espacio numérico. Esto resultaría en un registro CNAME que estaría apuntando a un registro CNAME, el cual puede ser menos robusto por todas partes. Desafortunadamente, algunas betas antiguas de la popular implementación DNS BIND 4.9.3 tienen un bug que causa problemas si se encuentraba un registro CNAME cuando se hacia un búsqueda inversa. Las versiones beta implicadas son obsoletas y esta cuestión fue resuelta en las siguientes versiones. Algunos fabricantes de software incluyen el código defectuoso de la beta en sus productos. En algunos casos sabemos que están disponibles o están previstos parches de los propios fabricantes para reemplazar el código obsoleto implicado de la beta. 5. Consideraciones de seguridad Con este esquema, los sitios "hoja" [leaf] necesitaran confiar en otro sitio más que este ejecutando su servicio de nombres DNS correctamente del que ellos serian si tuvieran una asignación /24 de su propiedad, y esta pudiera añadir un componente extra el cual Eidnes, et al. Mejor práctica actual [Pág. 7] RFC 2317 Delegación IN-ADDR.ARPA sin clase Marzo 1998 necesitaría trabajar para una resolución de nombres fiable. Los autores no son conscientes de ninguna consideración adicional sobre seguridad introducida por este mecanismo a parte de esta. 6. Conclusión El esquema sugerido da mayor flexibilidad en la delegación de autoridad en el dominio IN-ADDR.ARPA, haciendo así posible el asignar los espacios de direcciones más eficientemente sin perder la habilidad de delegar la autoridad DNS sobre la correspondiente dirección a los mapeadores de nombres. 7. Reconocimientos Glen A. Herrmannsfeldt describió este truco en comp.protocols.tcp- ip.domains algún tiempo atrás. Alan Barrett y Sam Wilson suministraron valiosos comentarios en el grupo de noticias Nos gustaría dar las gracias a Rob Austein, Randy Bush, Matt Crawford, Robert Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer, y Peter Koch por sus comentarios y criticas constructivas. 8. Referencias [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, noviembre 1987. [2] Harrenstein, K., Stahl, M. y E. Feinler, "DoD Internet Host Table Specification", RFC 952, octubre 1985. [3] Elz, R. y R. Bush, "Clarifications to the DNS Specification", RFC 2181, julio 1997. Dirección de los Autores Havard Eidness SINTEF RUNIT Trondheim N-7034 Norway EMail: Havard.Eidnes@runit.sintef.no Eidnes, et al. Mejor práctica actual [Pág. 8] RFC 2317 Delegación IN-ADDR.ARPA sin clase Marzo 1998 Geert Jan de Groot Berkeley Software Design, Inc. Hendrik Staetslaan 69 Eindhoven, HM 5622 The Netherlands EMail: GeertJan.deGroot@bsdi.com Paul Vixie Internet Software Consortium Star Route Box 159A Woodside, CA 94062 USA Phone: +1 415 747 0204 EMail: paul@vix.com Apéndice A. Créditos de la traducción y conversión a XML Este RFC ha sido traducido y convertido a XML según la especificación del RFC2629 por Raúl Mahiques en marzo de 2003. Eidnes, et al. Mejor práctica actual [Pág. 9] RFC 2317 Delegación IN-ADDR.ARPA sin clase Marzo 1998 Declaración completa de Copyright Copyright (C) The Internet Society (1998). Reservados todos los derechos. Le está permitido copiar y entregar a terceros este documento en su versión original o traducida. Puede procesar, copiar, publicar y distribuir, en parte o en totalidad, sin restricción de ningún tipo, trabajos derivados que comenten, expliquen o ayuden en la implementación de este documento, siempre que en cada copia o trabajo derivado incluya la mención de Copyright anterior junto con la presente nota. No le está sin embargo permitido modificar en ningún modo este documento, eliminar la mención de Copyright ni las referencias a The Internet Society u otras organizaciones de Internet, excepto con el fin de desarrollar los estándares de Internet (en cuyo caso deberá seguir los procedimientos para copyrights definidos en el proceso de Estándares Internet), o con el fin de traducirlo a otros idiomas distintos del inglés. Los permisos limitados concedidos más arriba son perpétuos y no serán revocados por la 'Internet Society' o sus sucesores o cesionarios. Este documento y la información contenida se ofrece "TAL CUAL". THE INTERNET SOCIETY Y THE INTERNET ENGINEERING TASK FORCE DESCARTAN CUALQUIER GARANTÍA EXPRESA O IMPLICITA POR EL USO DE LA INFORMACIÓN AQUÍ CONTENIDA Y EN PARTICULAR EXCLUYEN, SIN LIMITACIÓN ALGUNA, TODA GARANTÍA SOBRE POSIBLES INFRACCIONES DE DERECHOS O GARANTÍAS IMPLÍCITAS DE COMERCIALIZACIÓN Y ADECUACIÓN A LOS FINES PERSEGUIDOS. Agradecimiento Los fondos para las funciones desempeñadas por el editor RFC son proporcionados actualmente por la Internet Society. Eidnes, et al. Mejor práctica actual [Pág. 10]