viernes, 29 de agosto de 2008

Ataque de DNS Amplification


1. DoS contra el servidor de nombres

De forma general, los ataques de negación de servicio pretenden sobrecargar las redes y servidores con un conjunto de solicitudes o respuestas con el fin de sacar de operación a dichos servicios.

La tendencia en el uso de ataques de negación de servicio a través del uso de peticiones spoof al DNS en últimas fechas ha visto un incremento de consideración, este problema es fundamental tomando en cuenta que muchas de las comunicaciones en internet hacen uso del DNS.


2. Ataque de DNS Amplification

El atacante envía una alta cantidad de peticiones con una dirección IP falsificada (spoof) al DNS que permite recursión, el DNS procesa estas peticiones como si éstas fueran válidas mandando una respuesta al sistema al cual se quiere atacar, es decir al sistema víctima. Cuando estas peticiones alcanzan un volumen importante pueden inundar al sistema víctima de repuestas del DNS a las peticiones que se le realizan. Este ataque es llevado a cabo gracias a errores en la configuración del DNS y es llamado amplification puesto que los DNS al reflejar el ataque, potencian el nivel de éste hacia un blanco en especifico a causa de que las respuestas del servidor de nombres son de un tamaño considerablemente mayor que las peticiones que se le realizan causando con esto, en ocasiones, la caída del servicio y con ello la negación del mismo.


3. Servidores vulnerables

Los ataques de este tipo son susceptibles de ser exitosos en servidores de nombres de dominio en los cuales la recursión esté activada; esto es en una inmensa mayoría de los servidores de este tipo. Para hacer una detección exitosa de este tipo de servidores se puede hacer realizando un escaneo con ciertas herramientas las cuales nos indican el nivel de recursión que implementan los servidores de dominio. Algunas de estas son :

  • DNSCheck

    Esta herramienta web nos indica el nivel de recursión implementado en lo servidores de nombre que se hayan especificado a través del nombre del dominio

    http://dnscheck.se/

  • dlint

    Herramienta libre que pude ser de utilidad al indicarnos las subzonas de un dominio en específico, indicándonos si en ésta se lleva a cabo la recursión o no.


4. Impacto Potencial

La potencialidad de este ataque es de dimensiones sumamente grandes puesto que la mayoría de los servidores de nombre en internet tiene un problema en cuanto a la configuración de la recursión (que se describe en la sección siguiente), causa por la cual un ataque coordinado podría tener consecuencias desastrosas con incluso la caída de internet o la negación de servicio en muchos de sus servidores de nombres. El aumento en este tipo de prácticas nos da una idea y una base fundamentada para tomar medidas precautorias que nos ayuden y preparen para un ataque de estas magnitudes


5. Recomendaciones

En un sentido más amplio, la recursión es completamente inevitable puesto que al desaparecer esta, la razón de ser y la utilidad del DNS pierde la funcionalidad casi por completo. Esto se debe a la necesidad en el sistema de nombres de consultar a distintos servidores DNS puesto que la mayoría de las veces el DNS autoritativo para nuestro dominio no tendrá la respuesta a nuestra consulta y tendrá que preguntar en forma recursiva a partir de los DNS raíz hasta encontrar el DNS que pueda resolver nuestra consulta. Es decir, en estricto sentido la recursión no es ningún error de configuración. Se convierte en error al tiempo de que no se restringe la recursión en el servicio de nombres a solo una lista de solicitantes en los cuales confiamos. Una práctica de configuración ampliamente recomendable sería el permitir la realización de consultas recursivas solo a un grupo específico de direcciones IP. Si bien el riesgo no es completamente eliminado si logramos mitigar en gran medida la posibilidad de ser víctimas de una práctica maliciosa de este tipo.

Por otra parte una regla que debe aplicarse para minimizar el riesgo de DNS amplification es la del mínimo privilegio, esto es, un DNS no tiene que permitir la recursión a nadie mas que a los host estrictamente indispensables. Si nuestro DNS no tiene la necesidad de realizar consultas recursivas, puesto que no tenemos un dominio de menor jerarquía al cual permitirle la recursión, no existe la necesidad de permitirla o, en el caso de que tengamos ciertos dominios de mas baja jerarquía, debemos permitir la recursión solo a los hosts en los cuales tengamos confianza.

Ahora bien, ¿por qué limitar la recursión?. Si hasta ahora permitimos en nuestros servidores de nombres la recursión ilimitada (es decir, permitimos las consultas recursivas sin validar antes quién nos las está solicitando), estamos aumentando la posibilidad de que nuestro servidor DNS sea utilizado para hacer ataques de DoS ya que al no validar cualquier host puede realizar consultas falsificando la IP redirigiendo un ataque amplificado hacia cualquier objetivo de la red. Por otro lado, al configurar nuestro servicio de nombres restringiendo las IPs que nos pueden realizar consultas recursivas lo que hacemos es que nuestro servidor no podrá ser utilizado para llevar acabo ataques DoS a menos que se logre la falsificación de una de las IPs a las cuales tenemos otorgado el permiso de recursión

A continuación se describe quién se vería afectado y de que manera en el caso de una restricción de la recursión en un DNS.

En el caso de que se realice una restricción de la recursión, se verán afectados aquellos usuarios de nuestro DNS los cuales salgan del rango de IPs que nosotros tengamos configuradas. En este caso se verán afectados puesto que no les será posible acceder al servicio de nombres, cuando menos a partir de nuestro servidor DNS.

Todos los usuarios que tengan una IP que pertenezca al rango establecido en la configuración previamente mencionada no se verán afectados de ninguna manera puesto que el servicio de DNS les seguirá siendo proporcionado sin diferencia alguna.

5.1 Ejemplos de configuración recomendada (eliminar recursión)

5.1.1 Bind 8/9

En el siguiente ejemplo tenemos la configuración deseable (en BIND 8/9) para un servidor de nombres el cual no tiene ningún dominio de menor jerarquía al cual tengamos estrictamente que permitirle realizar consultas recursivas

options {

directory "/var/named";

recursion no;

};

5.1.2 Microsoft DNS

En el caso de Microsoft DNS se realizaría añadiendo un registro de tipo REG_DWORD llamado NoRecursion con el valor 1.a la siguiente llave del registro

HKEY_LOCAL:MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

5.2 Ejemplos de configuración recomendada (limitar recursión)

5.2.1 Bind 8/9

El siguiente ejemplo es útil en el caso en que tengamos dominios de menor jerarquía a los cuales tengamos que permitirles la recursión siempre y cuando esos hosts sean de nuestra confianza (BIND 8/9).

acl recurseallow { x.x.x.x; y.y.y.y; z.z.z.z; };

options {

directory "/var/named";

allow-recursion { recurseallow; };

};

5.2.2 Microsoft DNS

En el servidor de DNS de Microsoft Windows 2000 no existe manera conocida para hacer un bloqueo discriminatorio entre las IPs a las cuales otorgarles la recursión y a cuáles no. Es decir, la única manera que resultaría efectiva sería definir reglas en un firewall que bloqueen el protocolo UDP por el puerto 53 de entrada y arriba del 1023 de salida para las IPs que no tengamos contemplado permitirles la realización de queries.

* Referencia: Building Internet Firewalls 2da edición


6. Conclusiones

La recursión en el servicio de nombres no puede ser eliminada pero si puede ser controlada a través de la correcta configuración de los hosts a los cuales les es permitido hacer consultas recursivas en nuestro DNS. Si bien esto no elimina el riesgo de que nuestro DNS pueda ser usado como amplificador de recursión, sí disminuye el riesgo de manera considerable.

¿Porque no se elimina el riesgo?

El riesgo no se puede eliminar por el hecho de que siempre existe la posibilidad de que un atacante falsifique alguna IP para la cual nuestro servidor de nombres permite las consultas recursivas haciendo que el riesgo siempre esté latente. ¿Puede nuestro servidor ser víctima de la amplificación en la recursión producto del ataque a otro servidor DNS?

Si bien se puede mitigar el riego de que nuestro servidor lleve a cabo ataques a partir de la amplificación de recursión, nuestro servidor no puede ser responsable de la correcta configuración de los servidores que puedan llegar a realizar peticiones. Es decir , nuestro servidor puede ser víctima de un ataque de amplificación aun cuando en nuestro servidor no existan errores en la configuración, ya que las peticiones enviadas serían procesadas como válidas.

Existen medidas que pueden ayudarnos a contrarrestar este tipo de acciones utilizando herramientas de detección de peticiones provenientes de IPs falsificadas (spoof) por ejemplo basadas en el calculo del TTL (tiempo de vida) de los paquetes. Un ejemplo de una herramienta de este tipo es despoof, herramienta para el servidor de nombres BIND.


7.FAQ

1 ¿A quien permitirle la recursión?

Es recomendable permitir la realización de consultas recursivas solo a aquellos hosts en los cuales confiamos o es indispensable proporcionar el servicio. Por ejemplo, en el caso de una universidad, solamente a las IPs que tengamos asignadas.

2 ¿En que casos es recomendable bloquear por completo la recursión?

En los casos en los cuales nuestro dominio no tenga un dominio de menor jerarquía al cual debamos permitir la recursión. Es decir, en la estructura jerárquica del DNS las hojas de ese árbol tendrían que tener la recursión bloqueada.

3 ¿Es indispensable la recursión?

La recursión en las consultas al DNS se vuelve indispensable ya que el DNS en su conjunto es una base de datos distribuida, eso significa que no todos los datos que queremos obtener van a estar siempre en nuestro servidor predeterminado, por lo cual es necesario que nuestro servidor haga consultas a otros DNS para obtener la información de nuestro interés.

4 ¿Porque se produce una Negación de Servicio con este ataque?

Esto se debe a que el servidor DNS produce una respuesta mucho más grande en comparación con las peticiones que recibe. Estas respuestas en cantidades considerables pueden llegar a bloquear la actividad de otra máquina además de afectar el ancho de banda de la red en la que se produzca el ataque


8. Referencias

RFC relacionados al DNS

RFC relacionados a DNS.

Abajo se muestra una lista de RFCs (Solicitud para comentarios) que están relacionados directamente con DNS, el Sistema de Nombres de Dominio. Son 114 documentos los que se muestran a continuación. Las dependencias entre documentos, es listada mediante 20 documentos RFC obsoletos relacionados al DNS, así como algunos que no están relacionados directamente al DNS.

  • RFC 3696 (Informativo).

    Aplicación de Técnicas para la revisión y transformación de nombres por J. Klensin.

    Resume la síntesis de nombre de DNS válidos, direcciones de correo, y URL's, así como los programas que pueden aplicar correctamente una revisión local de entradas. De hecho, muchas aplicaciones no aceptan nombres de domino perfectamente válidos, direcciones de correo o URL por que suponen errores en su sintaxis. Deben ser leídos por codificadores en cualquier parte, pero que probablemente no tengan muchas esperanzas.

    Febrero-2004, revisado el 19-Marzo-2004.

  • RFC 3675 (Informativo).

    .sex Considerado peligroso por D. Eastlake 3rd.

    Durante algunas semanas, las fallas para clasificar contenido en Internet están basadas en nombres de dominio. Esto es una mala idea, y este documento explica por qué. Los principales argumentos técnicos contra el contenido en las etiquetas basadas en nombres de dominio, es que nada se puede decir sobre los nombres de dominio donde la administración del directorio se distribuye: es trivial crear ligas cruzadas para que cualquiera escape de la segregación, o que cause da no a usuarios inocentes. En cambio, las etiquetas deben ser aplicadas usando un mecanismo separado de la clasificación no-DNS. Ver también RFC 3467.

    Febrero-2004, revisado el 27-Febrero-2004.

  • RFC 3658 (Estándar propuesto) actualiza los RFC 1035, RFC 2535, RFC 3008 y RFC 3090.

    Registro de Recurso (RR) de la Delegación Signataria (DS) por O. Gudmundsson.

    Introduce el registro de recurso del DS, un mejor cambio semántico importante a la cadena de confianza del DNSSEC, pero uno que deba reducir la necesidad de la comunicación cuando cambien las llaves.

    Diciembre-2003, revisado el 27-Febrero-2004.

  • RFC 3655 (Estándar propuesto) actualiza el RFC 2535.

    Redefinición del bit DNS Dato Autenticado (AD) por B. Wellington y O. Gudmundsson.

    Un paso cerca de dar significado al bit AD en DNSSEC, pero la opción para fijarlo si los medios de la información ``cumplen con la política local'' no es incentivo para cambiar los servidores de nombres existentes.

    Noviembre-2003, revisado el 27-Febrero-2004.

  • RFC 3646 (Estándar propuesto).

    Opciones de configuración DNS para el protocolo dinámico de configuración de equipo para Ipv6 (DHCPv6) por R. Droms (editor).

    Permite un resolver IPv6 séa configurado usando DHCPv6, fijando la lista de servidores de nombres recursivos y la lista de la búsqueda del dominio.

    Diciembre-2003, revisado el 27-Febrero-2004.

  • RFC 3645 (Estándar propuesto) actualiza el RFC 2845.

    Algoritmo genérico de servicio de seguridad para la autenticación de transacción de llave secreta para el DNS (GSS-TSIG) por S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead y R. Hall.

    Define un algoritmo conveniente GSS para TSIG. Cinco de seis autores estaban afiliados con Microsoft cuando esto fue publicado.

    Octubre-2003, revisado el 27-Febrero-2004.

  • RFC 3597 (Estándar propuesto) actualiza los RFC 2163 y RFC 2535.

    Manejo de tipos de registros de recursos (RR) DNS desconocidos por A. Gustafsson.

    Mandatos que servidores DNS deben aceptar, almacenar y regresar registros desconocidos de tipos desconocidos como debe ser. Muy atrasado, pero incrementa la complejidad de la implementación DNSSEC y actualizaciones dinámicas.

    Septiembre-2003, revisado el 27-Febrero-2004.

  • RFC 3596 (Estándar de Bosquejo) hace obsoletos los RFC 1886 y RFC 3152.

    Extensiones DNS para soporte de IP Versión 6 por S. Thomson, C. Huitema, V. Ksinant y M. Souissi.

    Define el tipo de registro AAAA y el dominio IP6.ARPA, y especifica qué registros AAAA deben también ser procesados donde estaban antes los registro A.

    Octubre-2003, revisado el 27-Febrero-2004.

  • RFC 3492 (Estándar propuesto).

    Punycode: Una codificación Bootstring de Unicode para nombres de dominio internacionalizados en aplicaciones (IDNA) por A. Costello.

    Un (relativamente) sencillo mapéo de nombres de dominio Unicode en nombres de equipo DNS.

    Marzo-2003, revisado el 27-Febrero-2004.

  • RFC 3491 (Estándar propuesto).

    Nameprep: Un sencillo perfil para Nombres de Dominio Internacionalizados (IDN) por P. Hoffman y M. Blanchet.

    Un método un poco complejo para mapear nombres de dominio Unicode en nombres de equipo DNS.

    Marzo-2003, revisado el 27-Febrero-2004.

  • RFC 3490 (Estándar propuesto).

    Internacionalización de Nombres de Dominio en Aplicaciones (IDNA) por P. Faltstrom, P. Hoffman y A. Costello.

    Estructura global para mapear nombres de dominio Unicode en nombres de equipo DNS. Ver también una crítica.

    Marzo-2003, revisado el 27-Febrero-2004.

  • RFC 3467 (Informativo).

    Papel del Sistema de Nombres de Dominio (DNS) por J. Klensin.

    Describe la motivación original para el DNS. Discute qué no es apropiado para las nuevas aplicaciones en el DNS simplemente por que la infraestructura está extensamente desplegada. Sugiere que aplicaciones, como IDN, no están dentro de los principios del dise no del DNS, y deben estar fuera del DNS. Ver también RFC 2825.

    Febrero-2003, revisado el 27-Febrero-2004.

  • RFC 3445 (Estándar propuesto) actualiza el RFC 2535.

    Limitación del Alcance de Registros de Recursos KEY (RR) por D. Massey y S. Rose.

    Limita el uso de registros KEY para DNSSEC. Quita soporte para la aplicación de almacenamiento de llaves arbitrarias en registros KEY (previamente permitidos).

    Diciembre-2002, revisado el 27-Febrero-2004.

  • RFC 3425 (Estándar propuesto) actualiza el RFC 1035.

    IQUERY obsoleto por D. Lawrence.

    Declara el tipo de consulta IQUERY obsoleta, puesto que el DNS inverso usa registros PTR, alcanzando el mismo objetivo con mucho mejor comportamiento.

    Noviembre-2002, revisado el 27-Febrero-2004.

  • RFC 3405 (BCP 65).

    Sistema de Descubrimiento de Delegación Dinámica (DDDS) Parte cinco: Procedimiento de asignación de UR1.ARPA por M. Mealing.

    Políticas y procedimientos para UR1.ARPA y URN.ARPA, según lo usado por RFC 3402.

    Octubre-2002, revisado el 06-Marzo-2004.

  • RFC 3404 (Estándar propuesto) hace obsoletos los RFC 2915 y RFC 2168.

    Sistema de Descubrimiento de Delegación Dinámica (DDDS) Parte cuatro: La aplicación de Resolución de Identificadores de Recursos Uniformes (URI) por M. Mealling.

    Aplicación de DDDS, usando registros NAPTR para transformar URN's y URI's. Parece un intento de rescatar el esfuerzo URI/URN, pero hay muchas capas nuevas enga nosas, para que tenga éxito.

    Octubre-2002, revisado el 27-Febrero-2004.

  • RFC 3403 (Estándar propuesto) hace obsoletos los RFC 2915 y RFC 2168.

    Sistema de Descubrimiento de Delegación Dinámica (DDDS) Parte tres: La base de datos del Sistema de Nombres de Dominios por M. Mealling.

    Define el tipo de registro NAPTR (Apuntador de nombre autoritativo), con reglas DDDS almacenadas en la base de datos DNS. Muy general, pero esta es una instancia para las aplicaciones en RFC 3467.

    Octubre-2002, revisado el 27-Febrero-2004.

  • RFC 3402 (Estándar propuesto) hace obsoletos los RFC 2915 y RFC 2168.

    Sistema de Descubrimiento de Delegación Dinámica (DDDS) Parte dos: El algoritmo por M. Mealling.

    Detalla cómo DDDS transforma sus entradas de cadena, aplicando reglas obtenidas desde una base de datos dinámica. Una generalización simple del algoritmo DNS loockup, que puede ser visto como una transformación de un nombre de dominio en el contenido del registro de recurso asociado vía las reglas de delegación almacenadas en servidores DNS. El nivel de abstracción puede ser demasiado alto para los dise nadores del protocolo.

    Octubre-2002, revisado el 27-Febrero-2004.

  • RFC 3401 (Informativo) actualiza el RFC 2276; hace obsoletos los RFC 2915 y RFC 2168.

    Sistema de Descubrimiento de Delegación Dinámica (DDDS) Parte uno: EL DDDS Comprensivo por M. Mealling.

    Descripción de los documentos que abarcan DDDS, que es un método que transforma cadenas usando reglas almacenadas en una base de datos dinámica.

    Octubre-2002, revisado el 27-Febrero-2004.

  • RFC 3368 (Estándar propuesto).

    EL esquema URI 'go' para el Protocolo de Resolución de Nombre Común por M. Mealling.

    Esto parece ser el propósito principal de CNRP; un servicio de directorio de palabra clave, de manera que el navegador pueda ejecutar consultas de la forma;
    go:Some%20Company%20Name y similar. La gente de LDAP intenta crear un nuevo protocolo para el papel de servicio de directorio que el DNS no tiene; ver también RFC 2517. El DNS no tiene un buen servicio general de directorio, pero no parece malo que las alternativas tengan bastante espacio para establecerse.

    Agosto-2002, revisado el 27-Febrero-2004.

  • RFC 3367 (Estándar propuesto).

    Protocolo de Resolución de Nombre Común (CNRP) por N. Popp, M. Mealling y M. Moseley.

    CNRP consiste en bits útiles de LDAP expresados en sintáxis XML; ver también RFC 2168.

    Agosto-2002, revisado el 27-Febrero-2004.

  • RFC 3364 (Informativo) actualiza los RFC 2673 y RFC 2874.

    Tradeoffs Soporta Sistema de Nombres de Dominio (DNS) para la versión 6 del Protocolo de Internet (IPv6) por R. Austein.

    Una comparación crítica de registros AAAA (RFC 1886) contra (RFC 2874) para Ipv6. Ver también RFC 3363.

    Agosto-2002, revisado el 27-Febrero-2004.

  • RFC 3363 (Informativo) actualiza los RFC 2673 y RFC 2874.

    Representación de Direcciones de la versión 6 del Protocolo de Internet (IPv6) en el Sistema de Nombres de Dominio editado por R. Bush, A. Durand, B. Fink, O. Gudmundsson y T. Hain.

    Degrada RFC 2673 y RFC 2874 a estado experimental, pues los registros A6 y etiquetas binarias para direcciones IPv6 no son consideradas como importantes. Ver también RFC 3364.

    Agosto-2002, revisada el 27-Febrero-2004.

  • RFC 3352 (Informativo) hace obsoleto el RFC 1798.

    Protocolo de Acceso al Directorio en Conexiones de Bajo Peso a estado histórico por K. Zeilenga.

    El intento original por LDAP para asumir el control de fallo de DNS, según lo detallado aquí.

    Marzo-2003, revisado el 27-Febrero-2004.

  • RFC 3263 (Estándar propuesto) hace obsoleto el RFC 2543.

    Protocolo de Iniciación de Sesión (SIP): Localizando Servidores SIP por J. Rosenberg y H. Schulzrinne.

    Detalla cómo SIP usa registros NAPTR y SRV para localizar servidores SIP.

    Junio-2002, revisado el 12-Marzo-2004.

  • RFC 3258 (Informativo).

    Servidor de Nombre Autoritativo Distribuido vía Direcciones Unicast Compartidas por T. Hardie.

    Cómo usar una sola dirección IP para varios servidores de nombres, usando ruteo. De uso bastante común en ISPs alrededor del mundo.

    Abril-2002, revisado el 27-Febrero-2004.

  • RFC 3254 (Informativo).

    Definiciones para llamada sobre directorios por H. Alvestrand.

    Define términos y una estructura para clasificar diferentes tipos de servicios de directorios, y explicar cómo existen diferentes directorios (como DNS, el enrutamiento de la información de la base de datos BGP, y SNMP MIB's), atacados en este modelo.

    Abril-2002, revisado el 27-Febrero-2004.

  • RFC 3245 (Informativo).

    Historia y Contexto de Decisiones Operacionales de Mapeo de Números Telefónicos (ENUM): Documentos Informativos Contribuidos al Grupo 2 de Estudio ITU-T (SG2) por J. Klensin.

    Decisiones diseñadas trás el mapeo ENUM de números telefónicos E.164 en el DNS. Ver también RFC 2916.

    Marzo-2002, revisado el 27-Febrero-2004.

  • RFC 3226 (Estándar propuesto) actualiza los RFC 2535 y RFC 2874.

    DNSSEC e IPv6 A6 conscientes de los requerimientos del tamaño del mensaje servidor/resolver por O. Gudmundsson.

    Soporte requerido para extensiones EDNS0 para conformidad de DNSSEC, y también si los registros A6 son usados (ver RFC 3363).

    Diciembre-2001, revisado el 27-Febrero-2004.

  • RFC 3225 (Estándar propuesto).

    Indicando soporte resolver de DNSSEC por D. Conrad.

    Propone usar un bit en la cabecera extendida EDNS0 en resolvers para indicar explícitamente que soportan DNSSEC.

    Diciembre-2001, revisado el 27-Febrero-2004.

  • RFC 3197 (Informativo).

    Declaración de Aplicabilidad para Extensiones DNS MIB por R. Austein.

    Explica por qué la interfaz SNMP para servidores DNS y resolvers nunca fue implementada, y refiere los RFC 1611 y RFC 1612.

    Noviembre-2001, revisado el 27-Febrero-2004.

  • RFC 3152 (BCP 49) actualiza los RFC 1886 y RFC 2874; obsoleto por el RFC 3596; también actualiza los RFC 2553, RFC 2766 y RFC 2772, no relacionados al DNS.

    Agoto-2001, revisado el 27-Febrero-2004.

  • RFC 3123 (Experimental).

    Un tipo de RR DNS para Listas de Direcciones Prefijas (APL RR) por P. Koch.

    Define registros tipo APL, para listas de rangos de IP en notación prefija/larga. Puede ser útil cuando se especifican listas de control de acceso, pero no son usadas ampliamente.

    Junio-2001, revisado el 27-Febrero-2004.

  • RFC 3110 (Estándar propuesto) hace obsoleto el RFC 2537.

    RSA/SHA-1 SIG's y RSA KEY's en el Sistema de Nombres de Dominio (DNS) por D. Eastlake 3rd.

    Formatos para registros RSA/SHA-1 SIG y RSA KEY. EL cambio principal desde RFC 2537 es el remplazo de MD5 con hashes SHA-1.

    Mayo-2001, revisado el 27-Febrero-2004.

  • RFC 3090 (Estándar propuesto) actualiza el RFC 2535; actualizado por el RFC 3658.

    Clarificación de la Extensión de Seguridad DNS en Estados de Zonas por E. Lewis.

    Clarifica los recursos para que una zona sea asegurada, en el contexto DNSSEC.

    Marzo-2001. revisado el 27-Febrero-2004.

  • RFC 3071 (Informativo).

    Reflexiones en el DNS, RFC 1591, y Categorías de Dominios por Klensin.

    Una lamentación para la pérdida de cordura en la delegación DNS próxima a la raíz del nombre de espacio IN. Parece ser dirigido a ICANN y tratamiento a menudo inexplicable de TLD's. Ver también RFC 1591.

    Febrero-2001, revisado el 27-Febrero-2004.

  • RFC 3008 (Estándar propuesto) actualiza el RFC 2535: actualizado por el RFC 3658.

    Firma Autoritativa en la Seguridad del Sistema de Nombres de Dominios (DNSSEC) por B. Wellington.

    Requiere datos de la zona en zonas seguras para ser firmadas por la zona llave, y restringe la forma en cómo los registros SIG puede ser aplicados por un resolver seguro.

    Noviembre-2000, revisado el 27-Febrero-2004.

  • RFC 3007 (Estándar propuesto) actualiza los RFC 2136 y RFC 2535; hace obsoleto el RFC 2137.

    Asegurando Actualizaciones Dinámicas del Sistema de Nombres de Dominio (DNS) por B. Wellington.

    Cambia la forma en cómo asegura las actualizaciones dinámicas para ser desempeñadas en la estructura DNSSEC.

    Noviembre-2000, revisado el 27-Febrero-2004.

  • RFC 2972 (Informativo).

    Contexto y Objetivos para una Resolución de Nombre Común por N. Popp, M. Mealling, L. Masinter y K. Sollins.

    La filosofía de CNRP; parece sana, pero hay reservaciones respecto a la adopción práctica del protocolo. Ver también RFC 3367.

    Octubre-2000, revisado 27-Febrero-2004.

  • RFC 2937 (Estándar propuesto).

    Opción de Búsqueda de Nombre de Servicio para DHCP por C. Smith.

    Una opción de DHCP para especificar el orden de búsqueda del nombre de servicio del resolver. Similar a la forma en que trabaja nsswitch.conf para especificar el orden en el que los archivos del equipo local son consultados.

    Septiembre-2000, revisado el 27-Febrero-2004.

  • RFC 2931 (Estándar propuesto) actualiza el RFC 2535.

    Petición DNS y Firmas de Transacción (SIG(0)s) por D. Eastlake 3rd.

    Toma el tipo de registro SIG(0) extendido usado por DNSSEC.

    Septiembre-2000, revisado el 27-Febrero-2004.

  • RFC 2930 (Estándar propuesto).

    Establecimiento de la Llave Secreta para DNS (RR TKEY) por D. Eastlake 3rd.

    Una forma de distribuir llaves para registros TSIG.

    Septiembre-2000, revisado el 27-Febrero-2004.

  • RFC 2929 (BCP 42).

    Consideraciones IANA del Sistema de Nombres de Dominio (DNS) por D. Eastlake 3rd, E. Brunner-Williams y B. Manning.

    Define cuáles códigos, banderas y clases tienen que ser almacenadas, y cómo IANAnúmeros oficiales de IANA.
    almacenará nuevos números. Ver también los

    Septiembre-2000, revisado el 27-Febrero-2004.

  • RFC 2916 (Estándar propuesto).

    Número E.164 y DNS por P. Faltstrom.

    Especifica un mapeo de números telefónicos en URI's usando registros NAPTR y nombres de dominio en el dominio .E164.ARPA, similar a la forma en que los registros PTR son usados en .IN-ADDR.ARPA. No son usados ampliamente, y probablemente serán obsoletos por el Draft-Internet draft-ietf-enum-rfc2916bit. Ver también RFC 3245.

    Septiembre-2000, revisado el 06-Marzo-2004.

  • RFC 2915 (Estándar propuesto) actuliza el RFC 2168; obsoleto por RFC 3401, RFC 3402, RFC 3403, y RFC 3404.

    Septiembre-2000.

  • RFC 2874 (Experimental) actualizado por los RFC 3152, RFC 3226, RFC 3363 y RFC 3364.

    Extensiones DNS para Soporte de Agregación y Renumeración de Direcciones IPv6 por M. Crawford y C. Huitema.

    Introduce registros A6 y el dominio IP6.ARPA. Ver también RFC 3363.

    Julio-2000.

  • RFC 2870 (BCP 40) hace obsoleto el RFC 2010.

    Requerimientos Operacionales del Servidor de Nombres Raíz por R. Bush, D. Karrenberg, M. Kosters y R. Plzak.

    Cómo ejecutar un servidor de nombres raíz. Elimina algunos debates en la lista de correo dnsop durante el bosquejo.

    Junio-2000.

  • RFC 2845 (Estándar propuesto) actualiza el RFC 1035; actualizado por RFC 3645.

    Autenticación de Llave secreta de la Transacción para DNS (TSIG) por P. Vixie, O. Gudmundsson, D. Eastlake 3rd y B. Wellington.

    Protocolo hash para la autenticación de datos DNS, asumiendo que las llaves secretas son compartidas al final de los puntos. Estas llaves secretas necesitan ser distribuidas usando algún otro mecanismo, por ejemplo en RFC 3645 o RFC 2930.

    Mayo-2000, revisado el 27-Febrero-2004.

  • RFC 2832 (Informativo).

    Protocolo Registry Registrar (RRP) NSI Versión 1.1.0 por S. Hollenbeck y M. Srivastava.

    Protocolo para compartir información de registro del dominio entre registrers y registrars.

    Mayo-2000.

  • RFC 2826 (Informativo).

    Comentario Técnico IAB en el Único DNS Raíz por la Arquitectura de Internet.

    Reitera que el DNS está construido en la suposición técnica de que cada espacio de nombres tiene una raíz única. Desafortunadamente estos argumentos no son bastante persuasivos para detener la brigada anti-ICANN.

    Mayo-2000.

  • RFC 2825 (Informativo).

    Un Web enredoso: Problemas de IDN, Nombres de Dominio, y otros Protocolos de Internet por la Arquitectura de Internet (L. Daigle, Editor).

    Una advertencia de que los nombres de dominios internacionalizados tiene muchas trampas. Ver también RFC 3467.

    Mayo-2000.

  • RFC 2782 (Estándar propuesto) hace obsoleto el RFC 2052; actualiza el RFC 1035.

    Un RR DNS para especificar la localización de servicios (DNS SRV) por A. Gulbrandsen, P. Vixie y L. Esibov.

    Introduce registros generalizados SRV para ausencia de direcciones, similar a los registros MX, para otros servicios de correo. También cambia el espacio de nombres SRV para usar caracteres principales subrayados: "_TCP.ejemplo" en lugar de "TCP.ejemplo".

    Febrero-2000.

  • RFC 2694 (Informativo).

    Extensiones DNS para Direcciones de Red Transladadas (DNS_ALG) por P. Srisuresh, G. Tsirtsis, P. Akkiraju y A. Heffernan.

    Propone una aplicaión a nivel gateway para DNS que modifica el payload DNS para alterar direcciones mapeadas de equipos. Esto progresa sin entrada de la comunidad DNSEXT, de manera que no interopera con protocolos como DNSSEC. El despliegue de este protocolo probablemente puede causar una gran cantidad de problemas.

    Septiembre-1999.

  • RFC 2673 (Experimental) actualiza los RFC 3363 y RFC 3364.

    Etiquetas Binarias en el Sistema de Nombre de Dominios por M. Crawford.

    Define una etiqueta Bit-cadena, que representa una secuencia de etiquetas de simples bits para almacenar registros en cualquier bit-final en el árbol de nombres. Ver tanbién RFC 3363.

    Agosto-1999.

  • RFC 2672 (Estándar propuesto).

    Redirección de Nombre DNS no Terminal por M. Crawford.

    Define registros DNAME, con mapas en suárboles del DNS para otro dominio: así como una forma general de CNAME.

    Agosto-1999.

  • RFC 2671(Estándar propuesto).

    Mecanismos de Extensión para DNS (EDNSO) por P. Vixie.

    Mecanismos compatibles para incrementar el protocolo DNS, para evitar agotamiento de los campos fijos limitados. Note que estos estándares requieren que las implementaciones de características más nuevas también soporten todas las características de las versiones anteriores. Después de discusiones extendidas, una propuesta para extensiones basadas en este mecanismo nunca fue publicado. En general, EDNSO no es usado ampliamente.

    Agosto-1999.

  • RFC 2606(BCP 32).

    Nombres DNS Reservados en el nivel más alto por D. Eastlake 3rd y A. Panitz.

    Nuevos nombres de dominio reservados en el nivel más alto y en el segundo nivel para prueba y documentación: .EJEMPLO, .INVALIDO, .PRUEBA, .LOCALHOST y EJEMPLO.{COM, NET, ORG}.

    Junio-1999.

  • RFC 2541 (Informativo).

    Consideraciones Operacionales de Seguridad DNS por D. Eastlake 3rd.

    Recomendaciones de cómo administrar extensiones DNSSEC, en cuanto a los aspectos operacionales de llaves y generación de firmas, tiempo de vida, y almacenamiento, así como la seguridad en la zonas cerca de raíz. Una versión en HTML está disponible aquí.

    Marzo-1999.

  • RFC 2540 (Experimental).

    Información Separada del Sistema de Nombres de Dominio (DNS) por D. Eastlake 3rd.

    Formato para archivar y almacenar información de DNS. No usado ampliamente, desde formatos de paquetes capturados parecidos para hacer el mismo trabajo, por ejemplo libcap. Una versión en HTML está disponible aquí.

    Marzo-1999, revisado el 27-Febrero-2004.

  • RFC 2539 (Estándar propuesto).

    Almacenando llaves de Diffie-Hellman en el Sistema de Nombres de Dominio (DNS) por D. Eastlake 3rd.

    Registros KEYS para almacenamiento de llaves Diffiee-Hellman. Una versión en HTML está disponible aquí.

    Marzo-1999.

  • RFC 2538 (Estándar propuesto).

    Almacenando Certificados en el Sistema de Nombres de Dominio (DNS) por D. Eastlake 3rd y O. Gudmundsson.

    Registros CERT para almacenamiento de certificados y listas de revocación de certificados relacionadas. Una versión en HTML está disponible aquí.

    Marzo-1999.

  • RFC 2537 (Estándar propuesto) obsoleto por RFC 3110.

    Una versión en HTML está disponible aquí.

    Marzo-1999.

  • RFC 2536 (Estándar propuesto).

    Llaves DSA y SIG en el Sistema de Nombres de Dominio (DNS) por D. Eastlake 3rd.

    Almacenamiento de Algoritmos de Llaves de Firma Digital del Gobierno de U.S. y Uso de Firmas de Registros de Recursos KEY y TSIG. Una versión en HTML está disponible aquí.

    Marzo-1999.

  • RFC 2535 (Estándar propuesto) hace obsoleto el RFC 2065; actualiza los RFC 1034, RFC 1035 y RFC 2181; actualizado por los RFC 2931, RFC 3007, RFC 3008, RFC 3090, RFC 3226, RFC 3445, RFC 3597, RFC 3655 y RFC 3658.

    Extensiones de Seguridad del Sistema de Nombres de Dominio por D. Eastlake 3rd.

    Actualiza firmas digitales para la integridad y autenticación de datos en el DNS, incorporando implementaciones de realimentación. Firmas digitales son incluidas en zonas aseguradas como registros de recursos. Una versión en HTML está disponible aquí.

    Marzo-1999.

  • RFC 2517 (Informativo).

    Construyendo Directorios desde DNS: Esperiencias desde WWWSeeker por R. Moats y R. Huber.

    Experiencia de implementación desde WWWSeeker y Netfind, para los que consideran un directorio de palabra clave para descubrir nombres de dominio. Una versión en HTML está disponible aquí.

    Febrero-1999.

  • RFC 2377 (Informativo).

    Plan de Nombramiento para Aplicaciones de Internet de Directorio Habilitado por A. Grimstad, R. Huber, S. Sataluri y M. Wahl.

    Parte 2 de la tentativa LDAP para tomar DNS. Un esquema de nombramiento sensible para directorios LDAP, basados en las partes altas del espacio de nombres DNS. Ver también RFC 2247. Una versión en HTML está disponible aquí.

    Septiembre-1998.

  • RFC 2352 (Informativo) hace obsoleto el RFC 2240.

    Una Convención para el Uso Legal de Nombres como Nombres de Dominio por O. Vaughan.

    Propone la creación de nombres de dominio de segundo-nivel para organizaciones comerciales, dentro del TLD de países específicos. Sin embargo, el prefacio precisa, que este documento (y la versión anterior que sustituye) es bastante insustancial debido a los apremios del mundo verdadero (en comparación con el mundo que describe el documento).

    Mayo-1998.

  • RFC 2345 (Experimental).

    Recuperación de Nombres de Dominio y Nombres de Compañías por J. Klensin, T. Wolf y G. Oglesby.

    Propone agregar un paso extra loockup WHOIS a los navegadores para recuperar URL's en lugar de depender de nombres de dominio intuitivos. Similar a la característica clave agregada por Netscape y Microsoft para sus navegadores a mediados de 1998.

    Mayo-1998.

  • RFC 2317 (BCP 20).

    Delegación de Clases IN-ADDR.ARPA por H. Eidnes, G. de Groot y P. Vixie.

    Como hacer delegaciones IN-ADDR.ARPA en límites arbitrarios, en una forma compatible con software existente, usando registros CNAME y nuevas zonas. Una versión en HTML está disponible aquí.

    Marzo-1998.

  • RFC 2308 (Estándar propuesto) actualiza los RFC 1034 y RFC 1035.

    Almacenamiento Negativo de Consultas DNS (DNS NCACHE) por M. Andrews.

    Recomienda que los almacenamientos negativos (almacenamiento de información sobre registros de recursos no existentes) son obligatorios en resolvers. También redefine el uso del campo TTL en registros SOA para ser usados por almacenamientos negativos, y agregar una directiva $TTL para remplazar su antiguo uso. Una versión en HTML está disponible aquí.

    Marzo-1998.

  • RFC 2307 (Experimental).

    Una Aproximación para el uso de LDAP como un Servicio de Información de la Red por L. Howard.

    Mapeo de información tipo NIS en LDAP: alias, usuarios, protocolos, etc. No estrictamente relevante para DNS.

    Marzo-1998.

  • RFC 2276 (Informativo) actualizado por el RFC 3401.

    Principales Arquitecturas de Resolución de Nombres Recursivo Uniforme por K. Sollins.

    Las URN son significado de persistente, globalmente identificadores únicos para documentos en internet, como ISBN para libros o UPC's para productos en venta. Este define la arquitectura teórica de mapeo de URN a URL.

    Enero-1998.

  • RFC 2247 (Estándar propuesto).

    Usando Dominios en Nombres Distinguidos LDAP/X.500 por S. Kille, M. Wahl, A. Grimstad, R. Huber y S. Sataluri.

    Representación de nombres de dominio como nombres distinguidos (usando un nuevo atributo X.500 llamado DC) de modo que LDSP pueda contener información DNS. Ver también RFC 2377. Una versión en HTML está disponible aquí.

    Enero-1998.

  • RFC 2240 (Informativo) obsoleto por RFC 2352.

    Noviembre-1997.

  • RFC 2230 (Informativo).

    Delegación de registro Llave Exchange para el DNS por R. Atkinson.

    Registros KX para asegurar la IP, asumiendo un DNS seguro. KX define un equipo dispuesto a actuar como una llave exchange para un nombre de dominio dado. Una versión en HTML está disponible aquí.

    Noviembre-1997.

  • RFC 2219 (BCP 17).

    Uso de Alias DNS para Servicios de Red por M. Hamilton y R. Wright.

    El nombre IANA para un protocolo debe ser usado como un nombre de dominio para la máquina que soporta el protocolo en un sitio. Una versión en HTML está disponible aquí.

    Octubre-1997.

  • RFC 2182 (BCP 16).

    Selección y Operación de Servidores Secundarios DNS por R. Elz, R. Bush, S. Bradner y M. Patton.

    Cómo seleccionar servidores secundarios (esclavos). Una versión en HTML está disponible aquí.

    Julio-1997.

  • RFC 2181 (Estándar propuesto) actualiza los RFC 1034, RFC 1035 y RFC 1123; actualizado por el RFC 2535.

    Especificación de Clarificaciones para el DNS por R. Elz y R. Bush.

    Con respecto a servidores multi-patria, TTL's, zonas reducidas, registros SOA, la bandera TC (truncada), nombres autoritativos/canónicos, y etiquetas válidas. Una versión en HTML está disponible aquí.

    Julio-1997.

  • RFC 2168 (Experimental) actualizado por el RFC 2915; obsoleto por los RFC 3401, RFC 3402, RFC 3403 y RFC 3404.

    Junio-1997.

  • RFC 2163 (Estándar propuesto) hace obsoleto el RFC 1664; actualizado por el RFC 3597.

    Usando el DNS de Internet para Distribuir Direcciones Mapeadas con Formato Global MIXER (MCGAM) por C. Allocchio.

    Actualizado a RFC 1664, almacenando información en el DNS para mapear entre X.400 y direcciones de correo del RFC 822. Define un nuevo registro PX y nombres de dominio de segundo nivel del .X42D.xx para cada TLD específico de cada país xx.

    Enero-1998.

  • RFC 2146 (Informativo) hace obsoleto el RFC 1816.

    Nombres de Dominio de Internet del Gobierno de U.S. por el Consejo de Red Federal.

    Procedimientos de registros en el dominio de nivel más alto .GOV, y los primeros pasos en la migración a .FED.US.

    Mayo-1997.

  • RFC 2142 (Estándar propuesto).

    Nombres de Mailbox para Servicios Comúnes, Roles y Funciones por D. Crocker.

    Direcciones tales como ABUSE@dominio para reclamaciones a ISP's, HOTMASTER@dominio como un contacto estándar para problemas de DNS, y LIST-REQUEST@dominio para todas las listas de correo. Una versión en HTML está disponible aquí.

    Mayo-1997.

  • RFC 2137 (Estándar propuesto) actualiza el RFC 1035; obsoleto por el RFC 3007.

    Direcciones tales como ABUSE@dominio para reclamaciones a ISP's, HOTMASTER@dominio como un contacto estándar para problemas de DNS, y LIST-REQUEST@dominio para todas las listas de correo. Una versión en HTML está disponible aquí.

    Abril-1997, revisado el 27-Febrero-2004.

  • RFC 2136 (Estándar propuesto) actualiza el RFC 1035; actualizado por el RFC 3007.

    Actualizaciones Dinámicas en el Sistema de Nombres de Dominios (DNS UPDATE) por P. Vixie (editor), S. Thomson, Y. Rekhter y J. Bound.

    Adición de registro de nivel atómico y supresión de información DNS: realizado apropiadamente. Una versión en HTML está disponible aquí.

    Abril-1997.

  • RFC 2100 (Informativo).

    Nombramiento de Equipos por J. Ashworth.

    Un poema divertido de Eliot T. S. "Nombramiento de gatos", pero también hace algunas aclaraciones sobre el nombramiento de equipos. Ver también RFC 1178 para un trato más serio.

    01-Abril-1997, revisado el 27-Febrero-2004.

  • RFC 2065 (Estándar propuesto) actualiza los RFC 1034 y RFC 1035; obsoleto por el RFC 2535.

    Una versión en HTML está disponible aquí

    Enero-1997.

  • RFC 2053 (Informativo).

    El Dominio AM (Armenia) por E. Der-Danieliantz.

    Procedimientos para registrarse en el TLD AM.

    Octubre-1996.

  • RFC 2052 (Experimental) actualiza los RFC 1035 y RFC 1183; obsoleto por el RFC 2782.

    Octubre-1996.

  • RFC 2010 (Informativo).

    Una versión en HTML está disponible aquí.

    Octubre-1996.

  • RFC 1996 (Estándar propuesto) actualiza el RFC 1035.

    Notificación: mecanismo para notificación puntual de cambios en la zona autoritativa por P. Vixie.

    Describe código NOTIFY para avisar a los servidores esclavos que los datos del maestro han sido cambiados. Una versión en HTML está disponible aquí.

    Agosto-1996.

  • RFC 1995 (Estándar propuesto) actualiza el RFC 1035.

    Transferencia de Zona Incremental en DNS por M. Ohta.

    Mecanismo para usar con NOTIFY que permite transferir solamente partes de la zona que han sido modificadas. Una versión en HTML está disponible aquí.

    Agosto-1996.

  • RFC 1982 (Estándar propuesto) actualiza los RFC 1034 y RFC 1035.

    Número de Serie Aritmético por R. Elz y R. Bush.

    Define cómo los números seriales son comparados para determinar si una zona ha sido actualizada. Una versión en HTML está disponible aquí.

    Agosto-1996.

  • RFC 1956 (Informativo).

    Registro en el Dominio MIL por D. Engebretson y R. Plaz.

    Describe las políticas de registro del Dominio del Departamento de Defensa de E.U.

    Junio-1996.

  • RFC 1912 (Informativo) hace obsoleto el RFC 1537.

    Operaciones Comúnes DNS y Errores de Configuración por D. Barr.

    Errores y prácticas comunes en la operación de servidores y formatos de información. Una versión en HTML está disponible aquí.

    Febrero-1996.

  • RFC 1886 actualizado por el RFC 3152; obsoleto por el RFC 3596.

    Diciembre-1995.

  • RFC 1876 (Experimental) actualiza los RFC 1034 y RFC 1035; hace obsoleto el RFC 1712.

    Medios para Expresar Localización de Información en el sistema de Nombres de Dominios por C. Davis, P. Vixie, T. Goodwin y I. Dickinson.

    Registros de Localización Geográfica LOC.

    Enero-1996.

  • RFC 1816 (Informativo) hace obsoleto el RFC 1811, obsoleto por RFC 2146.

    Agosto-1995.

  • RFC 1811 (Informativo) obsoleto por RFC 1816.

    Junio-1995.

  • RFC 1794 (Informativo).

    Soporte DNS para Balanceo de Carga por T. Brisco.

    Soporte DNS para carga balanceada de muchos tipos.

    Abril-1995.

  • RFC 1713 (Informativo: FYI 27).

    Herramientas para depurar el DNS por A. Romao.

    Información general de algunas herramientas DNS. Ahora demasiado anticuado; un esfuerzo de IETF por ponerlo al día. Una versión en HTML está disponible aquí.

    Noviembre-1994.

  • RFC 1712 (Experimental) obsoleto por el RFC 1876.

    Codificación DNS de Localizaciones Geográficas por C. Farrel, M. Schulze, S. Pleitner y D. Baldoni.

    Paul Vixie escribe: "despreciado y retractado por sus autores pero los editores RFC accidentalmente lo publicaron".

    Noviembre-1994.

  • RFC 1706 (Informativo) actualiza los RFC 1034 y RFC 1035; hace obsoletos los RFC 1348 y RFC 1637.

    Registros de Recurso DNS NSAP por B. Manning y R. Colella.

    Cómo agregar NSAP estilo OSI al DNS usando registros PTR.

    Octubre-1994.

  • RFC 1664 (Experimental) obsoleto por el RFC 2163.

    Agosto-1994.

  • RFC 1637 (Experimental) hace obsoleto el RFC 1348; obsoleto por el RFC 1706.

    Junio-1994.

  • RFC 1612 (Histórico).

    Extensiones MIB del resolver DNS por R. Austein y J. Saperia.

    Interfaz SNMP del lado del cliente del DNS, esperando a ser implementada. Ver también el RFC 3197.

    Mayo-1994.

  • RFC 1611 (Histórico).

    Extensiones MIB del Servidor DNS por R. Austein y J. Saperia.

    Interfaz SNMP del lado del servidor del DNS, esperando a ser implementado. Ver también el RFC 3197.

    Mayo-1994.

  • RFC 1591 (Informativo).

    Estructura del Sistema de Nombre de Dominio y Delegación por J. Postel.

    Detalles administrativos y de administración sobre el espacio de nombres DNS. Ver también el RFC 3071.

    Marzo-1994, revisado el 27-Febrero-2004.

  • RFC 1537 (Informativo) obsoleto por RFC 1912.

    Octubre-1993.

  • RFC 1536 (Informativo).

    Errores Comúnes de Implementación DNS y Sugerencias a Soluciones por A. Kumar, J. Postel, C. Neuman, P. Danzig y S. Miller.

    Qué soluciona y cómo lo soluciona, para desarrolladores.

    Octubre-1993.

  • RFC 1535 (Informativo).

    Un Problema de Seguridad y Correcciones Propuestas con Software DNS Desarrollado Ampliamente por E. Gavron.

    Grandes posibilidades de subversión del resolver con listas de búsqueda estándar. En general, las listas de búsqueda de resolver nunca agregan nombres de dominios a una cadena básica de búsqueda a menos que los nombres de dominio sean administrados por uno compartido. Este medio que comúnmente es usado para buscar miembros de cadenas como .COM es peligroso y no debe ser usado. Años después, compañías serias de software aú n no entienden ésto.

    Octubre-1993.

  • RFC 1480 (Informativo) hace obsoleto el RFC 1386.

    El Dominio US por A. Cooper y J. Postel.

    Políticas y Procedimientos relacionados al dominio de alto nivel .US.

    Junio-1993.

  • RFC 1464 (Experimental).

    Usando el Sistema de Nombres de Dominio para Almacenar Atributos de Cadenas Arbitrarias por R. Rosenbaum.

    Uso de registros TXT para almacenar cadenas arbitrarias en el DNS.

    Mayo-1993.

  • RFC 1386 (Informativo) obsoleto por RFC 1480.

    Junio-1993.

  • RFC 1348 (Experimental) actualiza los RFC 1034 y RFC 1035; obsoleto por el RFC 1706.

    Julio-1992.

  • RFC 1183 (Experimental) actualiza los RFC 1034 y RFC 1035; actualizado por el RFC 2052.

    Nuevas definiciones RR DNS por C. Everhart, L. Mamakos y R. Ullmann y editado por P. Mockapetris.

    Nuevos registros de recursos, no usado ampliamente.

    Octubre-1990.

  • RFC 1178 (Informativo: FYI 5).

    Escogiendo un Nombre para su Computadora por D. Libes.

    Buenos consejos a tener en mente cuando se nombran computadoras, especialmente como qué nombres evitar. Ver también RFC 2100 para un trato menos serio.

    Agosto-1990.

  • RFC 1123 (Estándar: STD 3) actualizado por el RFC 2181.

    Requerimietos para Equipos de Internet, Aplicaciones y Soporte editado por R. Braden.

    Incluye el capítulo 6, sobre DNS.

    Octubre-1989.

  • RFC 1122 (Estándar: STD 3) actualizado por los RFC 1034 y RFC 1035.

    Requiremientos para Equipos de Internet, Capas de Comunicación editado por R. Braden.

    Sección 4 que discute problemas UDP y TCP que tienen efectos importantes en la capa baja del DNS.

    Octubre-1989.

  • RFC 1101 (Desconocido, ¿Estándar propuesto?) actualiza los RFC 1034 y RFC 1035.

    Codificación DNS de Nombres de Dominio y Otros Tipos por P. Mockapetris.

    Almacenamiento de nombres de redes y mascaras de red en el árbol inverso, usando registros PTR y A. Desafortunadamente, éste esquema solamente trabaja para redes clásicas, y por lo tanto es una curiosidad histórica. En lugar de ello, ver RFC 2317 para diferentes redes.

    Abril-1989.

  • RFC 1035 (Etándar: STD 13) actualizado por los RFC 1101, RFC 1122, RFC 1183, RFC 1706, RFC 1876, RFC 1982, RFC 1995, RFC 1996, RFC 2136, RFC 2137, RFC 2181, RFC 2308, RFC 2535, RFC 2782, RFC 2845, RFC 3425 y RFC 3658; hace obsoletos los RFC 882, RFC 883 y RFC 973.

    Implementación y Especificación de Nombres de Dominios por P. Mockapetris.

    Mecanismos del DNS. Una versión en HTML con ilustraciones gráficas está disponible aquí (gracias a Russ Nelson).

    Noviembre-1987.

  • RFC 1034 (Estándar: STD 13) actualizado por los RFC 1101, RFC 1122, RFC 1183, RFC 1706, RFC 1876, RFC 1982, RFC 2181, RFC 2308 y RFC 2535; hace obsoletos los RFC 882, RFC 883 y RFC 973.

    Conceptos y Facilidades de Nombres de Dominios por P. Mockapetris.

    Guía de referencia.

    Noviembre-1987.

  • RFC 1033 actualizado por el RFC 1912.

    Guía de Operaciones del Administrador de Dominio por M. Lottor.

    Guía de funcionamiento, algo anticuada.

    Noviembre-1987.

  • RFC 1032.

    Guía del Administrador de Dominios por M. Stahl.

    Explica los roles del administrador de dominio.

    Noviembre-1987.

  • RFC 974 (Estándar: STD 14).

    Enrutamiento de Correo y el Sistema de Dominio por Craig Partridge.

    Describe el procesamiento del registro MX.

    Enero-1986.

  • RFC 973 actualiza los RFC 882 y RFC 883; obsoleto por los RFC 1034 y RFC 1035.

    Enero-1986.

  • RFC 921 actualiza los RFC 897 y RFC 881.

    Implementación programada del Sistema de Nombre de Dominio revisada por J. Postel.

    Documenta el plan 1983-4 para cambiar sobre el DNS.

    Octubre-1984.

  • RFC 920.

    Requerimiento del Dominio por J. Postel y J. Reynolds.

    Documento administrativo sobre dominios. Covertido rápidamente en histórico.

    Octubre-1984.

  • RFC 897 actualiza el RFC 881; actualizado por el RFC 921.

    Implementación programada del Sistema de Nombres de Dominio por J. Postel.

    Documenta el plan 1983-4 para cambiar sobre el DNS.

    Febrero-1984.

  • RFC 883 actualizado por el RFC 973; obsoleto por los RFC 1034 y RFC 1035.

    Noviembre-1983.

  • RFC 882 actualizado por el RFC 973; obsoleto por los RFC 1034 y RFC 1035.

    Noviembre-1983.

  • RFC 881 actualizado por los RFC 897 y RFC 921.

    Plan y Programación de los Nombres de Dominio por J. Postel.

    Documenta el plan 1983-4 para cambiar sobre el DNS.

    Noviembre-1983.

  • RFC 819.

    Acuerdo del Nombramiento del Dominio para el Uso de Aplicaciones de Internet por Z. Su y J. Postel.

    Documenta las ideas de la estructura originaldel DNS.

    Agosto-1982.

  • RFC 811.

    Servidor de Nombres de Equipos por K. Harrenstien, V. White y E. Feinler.

    El servidor original centralizado de nombres de equipo loockup.

    Marzo-1982.

  • RFC 805.

    Notas de Reunión de Correo Electrónico por J. Postel.

    La decisión para introducir nombres tipo DNS para direcciones de correo.

    Febrero-1982.

Fuente: seguridad.unam.mx
Se produjo un error en este gadget.

Etiquetas

INTERNET (457) newsweek (305) SEGURIDAD (225) software (136) HACK (86) Hacker (46) GOOGLE (44) Geek (41) hardware (36) WINDOWS (34) Hackers (31) CRACK (29) video (28) DESCARGA (27) facebook (27) videos (26) Celulares (25) MICROSOFT (22) Informatica (21) apple (19) GRATIS (18) technology (18) virus (18) exploit (17) computación (16) informatico (16) web (15) cracker (14) INALAMBRICO (13) WINDOWS 7 (13) noticias (11) MSN (10) termino (10) ACTUALIZACION (9) Gamer (9) LapTops (9) Mac (9) PASSWORD (9) WINDOWS XP (9) dns (9) firefox (9) juegos (9) FOTOS (8) cientifico (8) iphone (8) WEP (7) antivirus (7) bibliografia (7) Desencriptar (6) INFINITUM (6) wifi (6) youtube (6) Craker (5) Culiacan (5) DESMOSTRACION (5) TELEFONIA (5) messenger (5) DIRECTA (4) DOWNLOAD (4) ESPAÑOL (4) XBOX (4) gmail (4) xss (4) Glosario (3) HTML (3) WPA (3) anuncios (3) hosting (3) hotmail (3) Guru (2) ajax (2) ataques (2) wpa2 (2)