Home UC3M
Home IT

Implementación de Linklocal Multicast Name Resolution (LLMNR)
 INTRODUCCIÓN


El objetivo de esta práctica es desarrollar una implementación del protocolo Linklocal Multicast Name Resolution (LLMNR), que permite la resolución de nombres en escenarios en los que no es posible utilizar DNS, bien porque no existe ningún servidor o porque no es posible alcanzarlo. Escenarios de este tipo serán habituales gracias a la proliferación de dispositivos limitados y al uso de protocolos de comunicación de corto alcance, que permiten que los dispositivos formen redes sin infraestructura, denominadas redes ad-hoc.

LLMNR soporta los mismos formatos, tipos y clases de registros de recurso que DNS, y los mismos paquetes, pero utiliza un puerto distinto y maneja una caché de registros de recursos distinta. En la actualidad LLMNR es un draft del grupo DNS-EXT del IETF. En esta práctica se trabajará siempre sobre la versión 36 de este draft, publicada en Septiembre de 2004.

Además de las clases prácticas, se impartirá una clase teórica sobre la práctica en la que se explicarán brevemente conceptos sobre programación con sockets y el protocolo LLMNR. Esta clase teórica será el día 27 de Octubre en el aula de teoría, 2.3.B01.


 OBJETIVOS


Con esta práctica se pretende que los alumnos se enfrenten a la implementación de un protocolo de nivel de aplicación real, partiendo de su especificación original. Además se ha seleccionado LLMNR por estar relacionado con uno de los protocolos estudiados en la parte teórica de la asignatura, el protocolo DNS, de manera que se fijen los conocimientos adquiridos.

La implementación de LLMNR permitirá además que los alumnos adquieran conocimientos de programación con sockets TCP, UDP y Multicast.



 ENUNCIADO


La práctica debe desarrollarse en lenguaje C sobre sistema operativo Linux y debe funcionar en los ordenadores de los laboratorios docentes de Ingeniería Telemática, donde se realizará la corrección presencial (existen dos máquinas a las que os podeis conectar de forma remota (ssh): it001.lab.it.uc3m.es a it018.lab.it.uc3m.es).

La descripción detallada de LLMNR está disponible en el siguiente draft del IETF, draft-ietf-dnsext-mdns-36.txt, es la versión 36. Importante: el grupo encargado de la especificación de LLMNR es muy activo por lo que actualizan el draft constantemente, pero esta práctica siempre estará basada en la versión 36.

A continuación se listan algunas consideraciones sobre el contenido del draft, que se deben tener en cuenta en la realización de la práctica:

  • Dirección multicast link local-scope IPv4 o IPv6:

    • En la práctica se utilizarán direcciones IPv4. Además cualquier consideración sobre el uso en redes IPv6 no se tendrá en cuenta.

  • Implementación de un sender y de sender+resolver:

    • En la página 4 del draft se indica que "Typically a host is configured as both an LLMNR sender and a responder. A host MAY be configured as a sender, but not a responder. However, a host configured as a responder MUST act as a sender...". En esta práctica se debe desarrollar un solo programa que mediante opciones se pueda lanzar como solo "sender" (opción -s) o como "sender+resolver" (opción -r).

  • Inserción de los Registros de Recursos que emplea el "resolver LLMNR":

    • En la página 4 del draft se indica que "This document does not specify how names are chosen or configured. This may occur via any mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315].". En esta práctica esta configuración se realizará a través de un archivo de configuración, que se le pasará como parámetro (opción -c) en el arranque al "resolver LLMNR". El formato de este fichero será el mismo que utiliza el servidor de nombres named, cuya especificación detallada la podeis encontrar en man named.conf

  • Consideraciones sobre el envío de resolución de nombres utilizando LLMNR:

    • En la página 4 del draft se realizan una serie de consideraciones de cuándo se deben enviar peticiones de resolución de nombres a LLMNR, desde "An LLMNR sender may send a request..." hasta "[3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name Error) or RCODE=0, and an empty answer section.". En la práctica NO se debe realizar ninguna comprobación previa sobre la existencia o alcanzabilidad de un servidor DNS tradicional antes de enviar una petición LLMNR.

  • Interacción con servidores de DNS ejecutándose en la misma máquina:

    • En la página 9 del draft se dice: "[f] If a DNS server is running on a host that supports LLMNR, the DNS server MUST respond to LLMNR queries only for the RRSets relating to the host on which the server is running, but MUST NOT respond for other records for which the server is authoritative. DNS servers also MUST NOT send LLMNR queries in order to resolve DNS queries.". En la práctica NO debe tenerse en cuenta esta observación, es suficiente con realizar un servidor stand-alone.

  • Consideraciones sobre la sección 2.5:

    • En la práctica NO es necesario tener en cuenta el contenido del apartado 2.5 del draft, desde "For IPv4, an "on link" address is defined..." hasta "then the query MUST be silently discarded. ".

  • Consideraciones sobre la sección 2.6:

    • En la práctica NO es necesario tener en cuenta el contenido del apartado 2.6 del draft.

  • Consideraciones sobre temporizadores y timeouts:

    • Se utilizarán siempre los valores "RECOMMENDED" del draft.

  • Consideraciones cobre la sección 2.9:

    • No es necesario implementar "negative caching" (especificado en la RFC2308) en los sender. Pero deben utilizarse las secciones adicionales y de autorización de los paquetes DNS tal y como se indica en esta sección.

  • Consideraciones sobre la sección 3:

    • En la práctica NO es necesario tener en cuenta el contenido del apartado 3 del draft.

  • Consideraciones sobre la sección 4:

    • Sólo se deben realizar tareas de comprobación sobre si los registros de recurso son únicos, cuando se arranca el resolver. Respecto a los apartados 4.1 y 4.2, en la práctica NO es necesario implementar el soporte a múltiples interfaces.

  • Consideraciones sobre la sección 5:

    • La implementación de LLMNR de la práctica no tiene soportar que los mecanismos de seguridad TSIG y/o SIG(0) (ver sección 5.4.).

Además deben tenerse en cuenta las siguientes consideraciones sobre parámetros de entrada y formato de salida:

  • El ejecutable del programa debe llamarse llmnr y debe aceptar las siguientes opciones como parámetros:


    • -r que indicará que es un "resolver". Recordemos que un "resolver" debe ser un "sender" pero sólo para operaciones internas, como garantizar que sus registros de recurso son únicos. En este caso además se incluirá la opción -c para pasarle el fichero de configuración.


      • IMPORTANTE El "resolver" debe ser capaz de atender varias peticiones simultaneamente

      Por ejemplo: llmnr -r -c llmnr.conf

    • -s que indicará que es un "sender". En este caso se incluirá también la correspondiente petición:


      • name nombre del registro de recurso que queremos resolver. Este parámetro debe existir siempre.


      • type tipo de petición que realizamos (A,MX,ANY...). Si no se indica este parámetro se considera que el tipo es A.


      Por ejemplo: llmnr -s it.uc3m.es MX.

      El "sender" después de resolver la petición solicitada debe mostrar la respuesta con un formato similar al que proporciona el programa dig y finalizar. Si se quiere realizar más peticiones deberá ejecutarse de nuevo.

 EVALUACIÓN

La evaluación de la práctica se realizará de forma presencial y su nota tendrá un peso del 20% sobre la nota final de la asignatura. Para que se haga media con el examen teórico debe obtenerse una nota superior o igual a 5. La nota de práctica, siempre que esté aprobada, se mantendrá para la convocatoria de Septiembre de 2005.

Fechas importantes

  • 2 de Noviembre de 2004: Clase teórica sobre LLMNR y el API de socket.
    • ¡¡¡CAMBIO DE FECHA!!! (programada incialmente para el 27 de Octubre)
  • 02,09,16,23 de Noviembre de 2004 y 11,18,25 de Enero de 2005: Clases prácticas en los laboratorios 4.SD03 y 4.SD04.

  • 28 de Enero de 2005: Entrega de la práctica a través de Aula Global.

  • Por decidir: Corrección presencial en el laboratorio.

 ENLACES

Material de apoyo

RFC

  • RFC 1034 "Domain names - concepts and facilities". P.V. Mockapetris. Nov. 1987.
  • RFC 1035 "Domain names - implementation and specification". P.V. Mockapetris. Nov. 1987.
  • RFC 2988 "Computing TCP's Retransmission Timer". V. Paxson and M. Allman. Nov. 2000.

Libros

  • P. Albitz and C. Liu: "DNS and BIND". 4 Ed. O'Reilly&Associates, 2001.(L/S 004.7 LIU)
  • W. R. Stevens: "Unix network programming".Volume 1.Networking APIs-Sockets and XTI (L/S 004.451.9 UNIX STE )

Información sobre sockets




inicio | tablón| contacta