http://www.rfc-editor.org/rfc/rfc6950.txt.

Desde hace mucho tiempo que el DNS se ha visto como un lugar atractivo para almacenar todo tipo de información, fuera del propósito original de transformar nombres de hosts en direcciones IP. Quizás basado en su ubicuidad y éxito como base de datos distribuida es que es un candidato directo para su utilización en otras aplicaciones. Sin embargo, el diseño del DNS cumple ciertas características que son inherentes a su uso original, y aunque puedan aparecer ciertamente otros usos no previstos que aprovechan con éxito sus capacidades, hay otras arquitecturas que rompen criterios básicos de diseño del DNS, y que es complejo adaptar para sus propios usos. Muchas veces se llega a callejones sin salida, o a forzar comportamientos que resultan artificiales.

El RFC6950 lo que busca es dar consejos y explicar a desarrolladores que tienen la idea de usar el DNS para almacenar su información, en qué propiedades deben fijarse para tomar la decisión. Hay ciertos parámetros básicos del diseño del DNS que indican claramente si una aplicación se encontrará con problemas.

El primer caso exitoso es uno muy antiguo. Se trata de la idea de almacenar el servidor de correo asociado a un dominio en un registro especial, el MX. Fue tan exitoso que se generalizó su formato para permitir ubicar muchos otros tipos de servicios, con el registro SRV.

Otro ejemplo muy documentado en el RFC es el almacenaje de números telefónicos en el DNS, ENUM, que también utiliza un mecanismo generalizado llamado Dynamic Delegation Discovery System, DDDS. Inicialmente fue una idea completamente alineada con el DNS, pero con el uso han surgido nuevos requerimientos que han estrujado el sustrato que otorga el DNS, y no queda muy claro si ya sería hora de usar una nueva infraestructura y protocolo para ciertas funcionalidades, tales como el manejo de números privados, administración de grupos de troncales de origen, etc.

El capítulo 5 del RFC6950 incluye un checklist de propiedades que indican a un desarrollador si el DNS es un buen lugar para sus datos:

1. si los mecanismos convencionales de caching del DNS le sirven sin tener que realizar modificaciones en los intermediarios (caches, resolvers, forwarders, etc), considerando que las respuestas de los autoritativos solo se basan en la tripleta (nombre, tipo, clase);
2. las llaves de indexación de los datos no violan la sintaxis o semántica de los nombres de dominios,
3. se resuelven nombres completos, no fragmentos;
4. las respuestas no dependen de la identidad en la capa de aplicación del que hace la pregunta,
5. las aplicaciones usan el DNS como asistencia para comunicarse con un servicio cuyo nombre es resuelto a través del DNS.

También se indica una lista de las cosas que de ser requeridas por la aplicación, son un signo de preocupación. Acá se incluye por ejemplo las aplicaciones que consideran que existen límites administrativos en los puntos de delegación del DNS, las respuestas muy dependientes de quién hace la pregunta, el almacenaje de respuestas con un tamaño muy grande, entre otras.

Este documento es originado por el Internet Architecture Board (IAB), por lo que no es un RFC clásico en el sentido de haber sido escrito en un working group, ni tampoco indica un consenso del IETF completo. Un documento originado por el IAB es redactado y editado por expertos en el área, y aunque es sometido a discusión a nivel general de toda la IETF, finalmente solo representa la visión de los integrantes del grupo IAB.