José Urzúa Reinoso
    Tesis Magister

Lista de Características a Revisar

Luego de profundas revisiones de los RFCs relacionados al funcionamiento del DNS, del análisis de los estudios y herramientas que actualmente se utilizan para medir el estado del DNS, se determinaron ciertas características que son de mucho mayor importancia que otras, que son recomendaciones. Para diferenciar las características importantes de las recomendaciones, se agrega la letra I o R, según corresponda. El listado de estas características y recomendaciones son:

  1. Todos los servidores DNS del nombre de dominio deben responder con los mismos servidores de nombres que responde el servidor DNS de primer nivel. (I) De cumplirse, indicaría que existe uniformidad entre la información que se mantiene entre todos los servidores de nombres del dominio y el servidor de nombres de más alto nivel. Para el caso de los dominios .CL, por ejemplo los servidores de nombres del dominio gobierno.cl deben responder con los mismos servidores de nombres que responde el servidor encargado del nombre de dominio .CL. De no cumplirse, se corre el riesgo de que el servidor de nombres no mencionado en alguno de los demás pueda ser inalcanzable para los requerimientos que se generen para el nombre de dominio.
  2. Todos los servidores de nombres del dominio deben responder. (I) Si un servidor de nombres del dominio no responde, podría generar que el dominio sea inalcanzable para algunos requerimientos, sobre todo para el caso en que existe sólo 1 servidor de nombres.
  3. Todos los servidores deben tener un reverso configurado correctamente. Los servidores de nombres del dominio son manejados como nombres de host dentro de las respuestas de los demás servidores de nombres, de no existir un reverso para el nombre del servidor, este será inalcanzable.
  4. El número de servidores DNS para el nombre de dominio debería estar entre 2 y 7. (R) Por motivos de redundancia, es muy importante mantener más de un servidor de nombres para el dominio, pero por velocidad de actualización y disminución del riesgo de información no uniforme, se recomienda mantener entre 2 y 7 servidores de nombres.
  5. Todos los servidores de nombres del dominio deben responder con autoridad. (I) Cuando un servidor DNS de un nombre de dominio no responde de manera autoritativa existirán requerimientos para el dominio que fallarán, además ese servidor no cumplirá con el objetivo de que sea una fuente de redundancia para el nombre de dominio.
  6. Las respuestas de los servidores de nombres no deben ser recursivas. (I) Un servidor que acepte consultas recursivas además de realizar mayor trabajo para responder un requerimiento, esta bajo el riesgo de ser atacado por cache poisoning, con lo cual podría entregar respuestas erróneas para algunos requerimientos.
  7. Los registros NS definidos no deben ser del tipo CNAME. (R) El usar CNAMES obliga a realizar una nueva resolución al nombre del servidor NS, que en el caso de ser un glue record podría generar un ciclo interminable de resolución.
  8. Las direcciones IP de los servidores DNS de un dominio deben estar en clases separadas. (R) Por motivos de robustez ante caídas de enlace para un rango de direcciones IP, es recomendable que los servidores de nombres de un nombre de dominio estén en clases IP distintas.
  9. Versiones del software de DNS en los servidores de nombres deben ser distintas. (R) De esta manera, si se descubre alguna vulnerabilidad en el software que se está usando no todos los servidores se verán afectados.
  10. Todos los servidores de nombres deben responder con el mismo número serial para la información del dominio. (I) El número serial del registro SOA en las zona del dominio, identifica la versión de esa información, para que los servidores respondan con la misma información, todos deben tener el mismo número serial para el registro SOA.
  11. En el registro SOA debe estar el nombre del servidor primario del dominio. (I) El primer parámetro en el registro SOA debe ser el nombre del servidor DNS primario del dominio, ya que este registro es la principal fuente de información del nombre de dominio.
  12. El formato del número serial del SOA debería tener el formato AAAAMMDDnn, con nn el número de versión de la zona de ese día. (R) Este formato, es recomendable debido a que todo cambio que se realice en la zona generará un nuevo número serial que será siempre mayor al que existía.
  13. Los tiempos del registro SOA deberían cumplir con: reintento menor que refresco, refresco menor que ttl, ttl menor que expiración. (I) De esa manera, todas las actualizaciones de la información se realizarán de la manera recomendada, y los nombres estarán acorde a lo que ellos representan.
  14. El tiempo de refresco en el registro SOA debe estar entre 3600 a 7200 (el RFC 1912 dice que debe estar en 1200 y 43200). (R) Es importante que el tiempo de refresco no sea demasiado pequeño, pues generaría demasiado tráfico innecesario en el caso de que la información no cambie muy frecuentemente, en el caso de tener un tiempo demasiado alto, los cambios en la información de dominio se propagarán muy lento.
  15. El tiempo de reintento en el registro SOA debería estar entre 120 a 7200. (R) Además, debería ser menor que el tiempo de refresco para que los reintentos para obtener el número serial de la información, ocurran antes que se cumpla el tiempo de refresco.
  16. El tiempo de expiración en el registro SOA debería estar entre 1209600 a 2419200 (2 a 4 semanas). (R) Por las mismas razones explicadas anteriormente, este tiempo debería estar entre los recomendados. Además, debería ser mayor al TTL.
  17. El tiempo de vida de la información (TTL) debería estar entre 86400 a 432000 (1 a 5 días, RFC 1912). (R) Al igual que las razones para los demás tiempos del registro SOA, este tiempo debería estar entre los recomendados y ser menor que el tiempo de expiración de la información.
  18. No debería ser CNAME el registro WWW. (R) Uno de los registros más consultados es el WWW, si es un CNAME se estaría realizando resoluciones redundantes, lo aconsejable es que sea un registro A directamente.
  19. Deberia existir un registro MX para el nombre de dominio. (I) De no existir, todos los emails que se generen para el dominio los recibirá el registro ADDRESS.
  20. Registros MX no deben ser CNAMES. (R) Si están definidos como CNAME, se estaría obligando a realizar una nueva resolución del nombre del servidor de email, el cual si es un glue record podría generar un ciclo interminable de resolución.
  21. Registro MX debe ser un nombre de host y no una dirección IP. (I) Está establecido que el registro MX debe ser un nombre de host y no una dirección IP.
  22. Debería existir más de un registro MX. (R) Por motivos de redundancia debería existir más de un registro MX.
  23. Registros MX deben tener un reverso bien configurado. (R) Como el registro MX es un nombre de host, para lograr una correcta resolución de la máquina que debe recibir el email, debe existir el reverso bien configurado para el registro MX.

Este listado de características por revisar para los servidores DNS de un nombre de dominio, se consideran suficientes y adecuadas para realizar un primer estudio del estado del DNS. Cabe mencionar que estas características se han recopilado de los variados RFCs que describen el correcto funcionamiento del DNS, de los estudios ya realizados por otras instituciones para otros dominios y de herramientas existentes para el diagnóstico de DNS. Además, está la experiencia del personal de soporte técnico de NIC Chile en donde se reportan y solucionan las dudas de los administradores de servidores DNS de los nombres de dominios registrados bajo .CL.

Probablemente para futuros estudios se agreguen o saquen características, dependiendo de los resultados y experiencia de haber realizado esta investigación por primera vez.

 


Estudios
Curriculum
Tesis Magister
Paper
Memoria
DTEs
CADCC 2002

Personal
Blog
Rugby
Xblast!
Parcela 31
Contacto


Inicio
Valid HTML 4.01! View Jose Urzua's profile on LinkedIn