Beneficios de seguridad

Introducción: Amenazas y mitigaciones de seguridad de DNS

Debido al diseño abierto y distribuido del sistema de nombres de dominio y a su uso del protocolo de datagramas de usuario (UDP), el DNS es vulnerable a varias formas de ataque. Los agentes de resolución de DNS públicos o "abiertos" recurrentes están especialmente en riesgo, ya que no restringen los paquetes entrantes a un conjunto de direcciones IP de origen permitidas. Nos preocupan principalmente dos tipos de ataques comunes:

  • Ataques de falsificación de identidad que provocan envenenamiento por caché de DNS Abundan varios tipos de falsificación de identidad y falsificación de identidad de DNS, cuyo objetivo es redireccionar a los usuarios de sitios legítimos a sitios web maliciosos. Estos incluyen los ataques de Kaminsky, en los que los atacantes toman el control autorizado de toda una zona de DNS.
  • Ataques de denegación del servicio (DoS). Los atacantes pueden iniciar ataques de DSD contra los agentes de resolución o apropiarse de ellos para lanzar ataques de DoS en otros sistemas. Los ataques que usan servidores DNS para iniciar ataques de DoS en otros sistemas mediante la explotación de un gran tamaño de registro o respuesta de DNS se conocen como ataques de amplificación.

Cada clase de ataque se detalla más adelante.

Ataques a la caché

Existen muchas variantes de ataques de falsificación de identidad de DNS que pueden envenenar la caché, pero la situación general es la siguiente:

  1. El atacante envía al agente de resolución de DNS objetivo varias consultas de un nombre de dominio para el cual sabe que el servidor no está autorizado y que es poco probable que esté en la caché del servidor.
  2. El agente de resolución envía solicitudes a otros servidores de nombres (cuyas direcciones IP también pueden predecir el atacante).
  3. Mientras tanto, el atacante inunda el servidor víctima con respuestas falsificadas que parecen provenir del servidor de nombres delegado. Las respuestas contienen registros que, en última instancia, resuelven el dominio solicitado a direcciones IP que controla el atacante. Pueden contener registros de respuesta para el nombre resuelto o, lo que es peor, pueden delegar autoridad a un servidor de nombres que es propiedad del atacante, por lo que toman el control de toda una zona.
  4. Si una de las respuestas falsificadas coincide con la solicitud del agente de resolución (por ejemplo, por nombre de consulta, tipo, ID y puerto de origen del agente de resolución) y se recibe antes de una respuesta del servidor de nombres genuino, el agente de resolución acepta la respuesta falsificada y la almacena en caché, y descarta la respuesta genuina.
  5. Las consultas futuras para el dominio o la zona vulneradas se responden con las resoluciones de DNS falsificadas de la caché. Si el atacante especificó un tiempo de actividad muy largo en la respuesta falsificada, los registros falsificados permanecen en la caché el mayor tiempo posible sin actualizarse.

Para obtener una excelente introducción a los ataques de Kaminsky, consulta Una guía ilustrada sobre la vulnerabilidad de Kaminsky.

Ataques de DoS y amplificación

Los agentes de resolución de DNS están sujetos a las amenazas de DoS habituales que afectan a cualquier sistema conectado a la red. Sin embargo, los ataques de amplificación son de particular preocupación porque los agentes de resolución de DNS son objetivos atractivos para los atacantes que explotan los agentes de resolución (una gran proporción de respuesta a solicitud para obtener ancho de banda adicional adicional). Los agentes de resolución que admiten EDNS0 (mecanismos de extensión para DNS) son especialmente vulnerables debido al tamaño de paquete sustancialmente más grande que pueden mostrar.

En una situación de amplificación, el ataque procede de la siguiente manera:

  1. El atacante envía consultas a un servidor DNS víctima con una dirección IP de origen falsificada. Las consultas se pueden enviar desde un solo sistema o una red de sistemas, todas con la misma dirección IP falsificada. Las consultas son para registros que el atacante sabe que generarán respuestas mucho más grandes, hasta varias docenas de veces1 el tamaño de las consultas originales (de ahí el nombre "ataque de amplificación").
  2. El servidor víctima envía las respuestas grandes a la dirección IP de origen que se pasa en las solicitudes falsificadas, lo que sobrecarga el sistema y genera una situación de DoS.

Mitigaciones

La solución estándar en todo el sistema para las vulnerabilidades de DNS es DNSSEC. Sin embargo, hasta que se implemente de forma universal, los agentes de resolución de DNS abiertos deben tomar algunas medidas de forma independiente para mitigar las amenazas conocidas. Se propusieron muchas técnicas; consulta IETF RFC 5452: Medidas para hacer que el DNS sea más resistente contra las respuestas falsificadas a fin de obtener una descripción general de la mayoría de ellas. En el DNS público de Google, implementamos y recomendamos los siguientes enfoques:

  • Proteger tu código contra desbordamientos del búfer, en particular el código responsable de analizar y serializar mensajes DNS
  • Aprovisiona en exceso los recursos de la máquina para brindar protección contra ataques directos de DoS a los agentes de resolución. Debido a que las direcciones IP son triviales para los atacantes, es imposible bloquear las consultas basadas en direcciones IP o subredes. La única forma efectiva de manejar esos ataques es simplemente absorber la carga.
  • Implementa una verificación de validez básica de los paquetes de respuesta y una mayor credibilidad del servidor de nombres para protegerse de la intoxicación por caché simple. Estos son mecanismos estándar y verificaciones de estado que cualquier agente de resolución de almacenamiento en caché que cumpla con los estándares debe realizar.
  • Agregar entropía para solicitar mensajes a fin de reducir la probabilidad de ataques más peligrosos de falsificación de identidad o envenenamiento de caché, como los ataques de Kaminsky Existen muchas técnicas recomendadas para agregar entropía. A continuación, presentamos una descripción general de los beneficios, las limitaciones y los desafíos de cada una de estas técnicas, y analizamos cómo las implementamos en el DNS público de Google.
  • Quitar las consultas duplicadas, para combatir la probabilidad de los “ataques de cumpleaños”
  • Solicitudes de límite de frecuencia, para evitar ataques de DoS y amplificación
  • Supervisar el servicio para las IP de cliente mediante el mayor ancho de banda y experimentar la proporción de tamaño de respuesta a solicitud más alta

DNSSEC

El estándar de las extensiones de seguridad de nombres de dominio (DNSSEC) se especifica en varias RFC de IETF: 4033, 4034, 4035 y 5155.

Los agentes de resolución que implementan ataques contra el envenenamiento de caché de DNSSEC verifican la autenticidad de las respuestas recibidas de los servidores de nombres. Cada zona de DNS mantiene un conjunto de pares de claves públicas/privadas y, para cada registro DNS, se genera y encripta una firma digital única con la clave privada. La clave pública correspondiente se autentica mediante una cadena de confianza mediante claves que pertenecen a zonas superiores. Los agentes de resolución compatibles con DNSSEC rechazan las respuestas que no contienen las firmas correctas. Las DNSSEC evitan que se manipule las respuestas, ya que en la práctica es casi imposible falsificar firmas sin acceso a claves privadas.

A partir de enero de 2013, el DNS público de Google es totalmente compatible con las DNSSEC. Aceptamos y reenvíamos mensajes con formato DNSSEC y validamos las respuestas para la autenticación correcta. Recomendamos a otros agentes de resolución que hagan lo mismo.

También almacenamos en caché las respuestas de NSEC como se especifica en IETF RFC 8198: Uso agresivo de caché validada por DNSSEC. Esto puede reducir las consultas de NXDOMAIN a los servidores de nombres que implementan DNSSEC y usan NSEC para respuestas negativas.

Transportes encriptados del cliente

El DNS público de Google ofrece compatibilidad con los protocolos de transporte encriptados, DNS por HTTPS y DNS por TLS. Estos protocolos evitan la manipulación, el espionaje y la falsificación de identidad, lo que mejora en gran medida la privacidad y la seguridad entre un cliente y el DNS público de Google. Complementan las DNSSEC para proporcionar búsquedas de DNS autenticadas de extremo a extremo.

Implementa la verificación de validez básica

Parte de la corrupción de caché de DNS puede deberse a discrepancias no intencionales y no necesariamente maliciosas, entre solicitudes y respuestas (p.ej., tal vez debido a un servidor de nombres mal configurado, un error en el software DNS, etcétera). Como mínimo, los agentes de resolución del DNS deben verificar la credibilidad y la relevancia de los servidores de nombres. Recomendamos e implementamos las siguientes defensas:

  • No configures el bit recursivo en las solicitudes salientes y siempre sigue las cadenas de delegación de manera explícita. Inhabilitar el bit recursivo garantiza que tu agente de resolución funcione en modo iterativo para que consultes cada servidor de nombres en la cadena de delegación de manera explícita, en lugar de permitir que otro servidor de nombres realice estas consultas en tu nombre.
  • Rechazar los mensajes de respuesta sospechosos. Consulta a continuación los detalles de lo que consideramos "sospechoso".
  • No muestres registros A a clientes basados en registros glue almacenados en caché de solicitudes anteriores. Por ejemplo, si recibes una consulta de cliente para ns1.example.com, debes resolver la dirección en lugar de enviar un registro A basado en registros glue en caché que muestra un servidor de nombres TLD .com.

Rechazar respuestas que no cumplen con los criterios requeridos

El DNS público de Google rechaza todo lo siguiente:

  • Respuestas no analizables o con formato incorrecto.
  • Respuestas en las que los campos clave no coinciden con los campos correspondientes en la solicitud Esto incluye el ID de la consulta, la IP de origen, el puerto de origen, la IP de destino o el nombre de la consulta. Consulta RFC 5452, sección 3 para obtener la descripción completa del comportamiento de la falsificación de identidad de DNS.
  • Registros que no son relevantes para la solicitud
  • Registros de respuesta para los que no podemos reconstruir la cadena CNAME.
  • Registros (en la respuesta, la autoridad o las secciones adicionales) en los que el servidor de nombres que responde no es creíble. Determinamos la credibilidad de un servidor de nombres según su lugar en la cadena de delegación para un dominio determinado. El DNS público de Google almacena en caché la información de la cadena de delegación y verificamos cada respuesta entrante con la información almacenada en caché a fin de determinar la credibilidad del servidor de nombres que responde para responder a una solicitud en particular.

Agrega entropía a las solicitudes

Una vez que un agente de resolución aplica verificaciones de estado básicas, un atacante tiene que inundar el agente de resolución vítmico con respuestas en un esfuerzo por hacer coincidir el ID de la consulta, el puerto UDP (de la solicitud), la dirección IP (de la respuesta) y el nombre de la consulta original antes de que lo haga el servidor de nombres legítimo.

Lamentablemente, esto no es difícil de lograr, ya que el único campo de identificación, el ID de la consulta, solo tiene 16 bits (es decir, para una probabilidad de 1/65,536 de hacerlo bien). Los otros campos también están limitados en el rango, lo que hace que la cantidad total de combinaciones únicas sea un número relativamente bajo. Consulta la RFC 5452, sección 7 para ver un cálculo de las combinaciones.

Por lo tanto, el desafío es agregar la mayor entropía al paquete de solicitud como sea posible, dentro del formato estándar del mensaje DNS, para que a los atacantes les resulte más difícil hacer coincidir correctamente una combinación de campos válida dentro del período de oportunidad. Recomendamos e implementamos todas las técnicas que se analizan en las siguientes secciones.

Presentamos una revisión actualizada de las técnicas mencionadas aquí en la conferencia DNS OARC 38 en julio de 2022. La presentación también incluye recomendaciones para los operadores del servidor de nombres.

Aleatorización de puertos de origen

Como paso básico, nunca permitas que los paquetes de solicitudes salientes usen el puerto UDP 53 predeterminado o que usen un algoritmo predecible para asignar varios puertos (p.ej., un incremento simple). Usa un rango de puertos tan amplio como 1024 a 65535 en tu sistema y usa un generador de números aleatorios confiable para asignar puertos. Por ejemplo, el DNS público de Google usa aproximadamente 15 bits para permitir aproximadamente 32,000 números de puerto diferentes.

Ten en cuenta que si tus servidores se implementan detrás de firewalls, balanceadores de cargas y otros dispositivos que realizan traducciones de direcciones de red (NAT), esos dispositivos pueden desaleatorizar puertos en paquetes salientes. Asegúrate de configurar los dispositivos NAT para inhabilitar la desaleatorización de puertos.

Elección aleatoria de servidores de nombres

Algunos agentes de resolución, cuando envías solicitudes al usuario raíz, al TLD o a otros servidores de nombres, selecciona la dirección IP del servidor de nombres según la distancia más corta (latencia). Te recomendamos que aleatorices las direcciones IP de destino para agregar entropía a las solicitudes salientes. En el DNS público de Google, simplemente elegimos un servidor de nombres al azar entre los servidores de nombres configurados para cada zona, lo que favorece un poco a los servidores de nombres rápidos y confiables.

Si te preocupa la latencia, puedes usar las bandas de tiempo de ida y vuelta (RTT), que consisten en la aleatorización dentro de un rango de direcciones que están por debajo de un cierto umbral de latencia (p. ej., 30 ms, 300 ms, etcétera).

Cookies de DNS

RFC 7873 define una opción EDNS0 para agregar cookies de 64 bits a los mensajes DNS. Una cookie de DNS compatible con el cliente incluye una cookie aleatoria de 64 bits y, opcionalmente, una cookie de servidor (si se conoce) en una solicitud. Si un servidor de asistencia encuentra la opción de cookie válida en una solicitud, refleja la cookie cliente y la cookie del servidor correcta en la respuesta. Luego, el cliente de asistencia puede verificar la cookie del cliente en la respuesta para verificar que la respuesta provenga del servidor esperado.

Si un servidor de nombres no admite cookies de DNS, puedes usar las siguientes dos opciones para agregar entropía.

Aleatorizar mayúsculas y minúsculas en nombres de consultas

Los estándares de DNS requieren que los servidores de nombres traten los nombres con distinción entre mayúsculas y minúsculas. Por ejemplo, los nombres example.com y EXAMPLE.COM deben resolverse en la misma dirección IP2. Además, todos los servidores de nombres, excepto una pequeña minoría, repiten el nombre en la respuesta, como apareció en la solicitud, y conservan el caso original.

Por lo tanto, otra forma de agregar entropía a las solicitudes es variar el caso de las letras en los nombres de dominio consultados de manera aleatoria. Esta técnica, también conocida como “0x20” porque el bit 0x20 se usa para establecer el uso de las letras US-ASCII, se propuso por primera vez en el borrador de Internet IETF Uso del bit 0x20 en etiquetas DNS para mejorar la identidad de la transacción. Con esta técnica, la respuesta del servidor de nombres debe coincidir con el nombre de la consulta y con cada letra en la string del nombre; por ejemplo, wWw.eXaMpLe.CoM o WwW.ExamPLe.COm. Esto puede agregar poca o ninguna entropía a las consultas de los dominios de nivel superior y raíz, pero es eficaz para la mayoría de los nombres de host.

Un desafío importante que descubrimos cuando implementamos esta técnica es que algunos servidores de nombres no siguen el comportamiento de respuesta esperado:

  • Algunos servidores de nombres responden con una distinción total entre mayúsculas y minúsculas: muestran de manera correcta los mismos resultados, sin importar el caso en la solicitud, pero la respuesta no coincide con el caso exacto del nombre en la solicitud.
  • Otros servidores de nombres responden con distinción entre mayúsculas y minúsculas (en incumplimiento de los estándares de DNS): manejan nombres equivalentes de manera diferente según el caso en la solicitud, ya sea porque no responden en absoluto o muestran respuestas incorrectas de NXDOMAIN que coinciden con el caso exacto del nombre de la solicitud.
  • Algunos servidores de nombres funcionan correctamente, excepto las consultas PTR en la zona arpa.

En ambos tipos de servidores de nombres, la alteración del caso del nombre de la consulta produciría resultados no deseados: para el primer grupo, la respuesta sería indistinguible de una respuesta falsificada; para el segundo grupo, la respuesta (si hubiera) podría ser totalmente incorrecta.

Nuestra solución actual para este problema es usar la aleatorización de casos solo para los servidores de nombres que sabemos que aplican los estándares correctamente. También enumeramos los subdominios de excepciones adecuados para cada uno de ellos, según el análisis de nuestros registros. Si una respuesta que parece provenir de esos servidores no contiene el caso correcto, la rechazamos. Los servidores de nombres habilitados manejan más del 70% de nuestro tráfico saliente.

Anteponer etiquetas de nonce a nombres de consulta

Si un agente de resolución no puede resolver directamente un nombre de la caché o no puede consultar directamente un servidor de nombres autorizado, debe seguir las referencias de un servidor de nombres raíz o de TLD. En la mayoría de los casos, las solicitudes a los servidores de nombres raíz o TLD darán como resultado una referencia a otro servidor de nombres, en lugar de un intento de resolver el nombre en una dirección IP. Por lo tanto, para esas solicitudes, debería ser seguro adjuntar una etiqueta aleatoria a un nombre de consulta a fin de aumentar la entropía de la solicitud, sin correr el riesgo de no resolver un nombre inexistente. Es decir, el envío de una solicitud a un servidor de nombres de referencia para un nombre con el prefijo de una etiqueta de instancia, como entriih-f10r3.www.google.com, debe mostrar el mismo resultado que una solicitud para www.google.com.

Aunque en la práctica estas solicitudes representan menos del 3% de las solicitudes salientes, si se tiene en cuenta el tráfico normal (ya que la mayoría de las consultas se pueden responder directamente desde la caché o mediante una sola consulta), estos son precisamente los tipos de solicitudes que un atacante intenta forzar a un agente de resolución para que emita. Por lo tanto, esta técnica puede ser muy eficaz para prevenir vulnerabilidades de estilo Kaminsky.

La implementación de esta técnica requiere que las etiquetas de nonce solo se usen para solicitudes que den como resultado referencias, es decir, respuestas que no contienen registros en la sección de respuestas. Sin embargo, encontramos varios desafíos cuando intentábamos definir el conjunto de esas solicitudes:

  • Algunos servidores de nombres TLD con código de país (ccTLD) en realidad son autorizados para otros TLD de segundo nivel (2LD). Aunque tienen dos etiquetas, los 2LD se comportan como los TLD, por lo que a menudo los administran los servidores de nombres de ccTLD. Por ejemplo, los servidores de nombres .uk también son autorizados para las zonas mod.uk y nic.uk y, por lo tanto, los nombres de host contenidos en esas zonas, como www.nic.uk, www.mod.uk, etcétera. En otras palabras, las solicitudes a servidores de nombres ccTLD para la resolución de esos nombres de host no darán como resultado referencias, pero sí respuestas autorizadas. Agregar etiquetas de nonce a esos nombres de host hará que los nombres no se puedan resolver.
  • A veces, los servidores de nombres de TLD genéricos (gTLD) muestran respuestas no autorizadas para servidores de nombres. Es decir, algunos nombres de host del servidor de nombres residen en una zona de gTLD en lugar de en la zona de su dominio. Un gTLD mostrará una respuesta no autorizada para estos nombres de host, mediante cualquier registro glue que tenga en su base de datos, en lugar de mostrar una referencia. Por ejemplo, el servidor de nombres ns3.indexonlineserver.com solía estar en la zona .COM del gTLD en lugar de en la zona indexonlineserver.com. Cuando emitimos una solicitud a un servidor de gTLD para n3.indexonlineserver.com, obtuvimos una dirección IP para ella, en lugar de una referencia. Sin embargo, si se antepuso una etiqueta de nonce, obtuvimos una referencia a indexonlineserver.com, que luego no pudo resolver el nombre de host. Por lo tanto, no podemos agregar etiquetas de nonce para servidores de nombres que requieran una resolución desde un servidor de gTLD.
  • Las autoridades para las zonas y los nombres de host cambian con el tiempo. Esto puede hacer que un nombre de host con nonce antepuesto que alguna vez se podía resolver se pueda resolver si la cadena de delegación cambia.

A fin de abordar estos desafíos, configuramos excepciones para los nombres de host para los que no podemos agregar etiquetas de nonce. Estos son nombres de host para los que los servidores de nombres de TLD muestran respuestas sin referencia, según nuestros registros del servidor. Revisamos continuamente la lista de excepciones para asegurarnos de que siga siendo válida con el tiempo.

Quita las consultas duplicadas

Los agentes de resolución de DNS son vulnerables a ataques de "cumpleaños", denominados porque explotan la "paradoja" matemática de cumpleaños, en la que la probabilidad de una coincidencia no requiere una gran cantidad de entradas. Los ataques de cumpleaños implican inundar el servidor de la víctima no solo con las respuestas falsificadas, sino también con las consultas iniciales y se cuenta con el agente de resolución a fin de emitir varias solicitudes para una única resolución de nombre. Cuanto mayor sea la cantidad de solicitudes salientes emitidas, mayor será la probabilidad de que el atacante coincida con una de esas solicitudes con una respuesta falsificada: un atacante solo necesita el orden de 300 solicitudes en curso para una probabilidad de éxito del 50% en la coincidencia con una respuesta falsificada y 700 solicitudes para tener casi el 100% de éxito.

Para protegerte contra esta estrategia de ataque, debes asegurarte de descartar todas las consultas duplicadas de la cola de salida. Por ejemplo, el DNS público de Google nunca permite más de una solicitud pendiente para el mismo nombre, tipo de consulta y dirección IP de destino.

Consultas de límite de frecuencia

La prevención de ataques de denegación del servicio plantea varios desafíos particulares para los agentes de resolución de DNS recurrentes y abiertos:

  • Los agentes de resolución recurrentes recurrentes son destinos atractivos para lanzar ataques de amplificación. Son servidores de alta capacidad y confiabilidad que pueden producir respuestas más grandes que un servidor de nombres autorizado típico, en especial si un atacante puede insertar una respuesta grande en su caché. Depende de cualquier desarrollador de un servicio de DNS abierto evitar que sus servidores se usen para lanzar ataques en otros sistemas.
  • Los ataques de amplificación pueden ser difíciles de detectar mientras ocurren. Los atacantes pueden iniciar un ataque a través de miles de agentes de resolución abiertos, de modo que cada agente de resolución solo vea una pequeña fracción del volumen total de consultas y no pueda extraer un indicador claro de que se comprometió.
  • El tráfico malicioso se debe bloquear sin interrupciones ni interrupciones del servicio de DNS para los usuarios normales. El DNS es un servicio de red esencial, por lo que apagar los servidores para cortar un ataque no es una opción ni negar el servicio a cualquier IP de cliente por mucho tiempo. Los agentes de resolución deben poder bloquear rápidamente un ataque en cuanto se inicia y restablecer el servicio operativo en cuanto este finaliza.

El mejor enfoque para combatir los ataques de DoS es imponer un mecanismo de limitación de frecuencia o de regulación. El DNS público de Google implementa dos tipos de control de frecuencia:

  • Control de tarifa de las solicitudes salientes a otros servidores de nombres A fin de proteger otros servidores de nombres de DNS contra ataques de DoS que podrían iniciarse desde nuestros servidores de resolución, el DNS público de Google aplica límites de QPS a las solicitudes salientes de cada clúster de entrega para cada dirección IP del servidor de nombres.

  • Control de la tasa de respuestas salientes a los clientes Para proteger cualquier otro sistema contra la amplificación y los ataques de DoS (botnet) distribuidos y tradicionales que podrían iniciarse desde nuestros servidores de resolución, el DNS público de Google realiza dos tipos de límites de frecuencia en las consultas de los clientes:

    • Para brindar protección contra ataques tradicionales basados en volúmenes, cada servidor impone límites de ancho de banda promedio y QPS por cliente-IP.
    • Para brindar protección contra ataques de amplificación, en los que se explotan las respuestas grandes a consultas pequeñas, cada servidor aplica un factor de amplificación promedio máximo por IP de cliente. El factor de amplificación promedio es una proporción configurable del tamaño de respuesta a consulta, determinada a partir de patrones de tráfico históricos observados en nuestros registros del servidor.

    Si las consultas de DNS desde una dirección IP de origen superan la tasa máxima de QPS, se descartarán las consultas excesivas. Si las consultas de DNS a través de UDP desde una dirección IP de origen exceden el ancho de banda promedio o el límite de amplificación de manera coherente (es posible que se apruebe una respuesta grande de vez en cuando), las consultas pueden descartarse o solo se puede enviar una respuesta pequeña. Las respuestas pequeñas pueden ser una respuesta de error o una respuesta vacía con el bit de truncamiento configurado (para que las consultas más legítimas se vuelvan a intentar mediante TCP y se realicen de forma correcta). No todos los sistemas o programas volverán a intentarlo a través de TCP, y los firewalls del cliente podrían bloquear el DNS a través de TCP, por lo que es posible que algunas aplicaciones no funcionen correctamente cuando se truncan las respuestas. Sin embargo, el truncamiento permite que los clientes que cumplen con RFC funcionen de forma correcta en la mayoría de los casos.

  1. Consulta el artículo sobre ataques de amplificación de DNS para ver ejemplos y una buena discusión del problema en general. ↩

  2. En la RFC 1034, sección 3.5, se indica lo siguiente: ↩

    Ten en cuenta que, aunque se permiten letras mayúsculas y minúsculas en los nombres de dominio, no se adjunta ningún significado. Es decir, dos nombres con la misma ortografía, pero diferente caso, deben tratarse como idénticos.