RFC 8482

Con las opciones de servicio en la nube «bombeando» frenéticamente para casi todo lo que tenemos en TI y otros servicios, es fácil elegir cualquier servicio y simplemente hacer clic en INICIAR y comenzar a usarlo.

Como buenos profesionales, sabemos que detrás de este «INICIO» hay muchas cosas para que esta implementación simple comience a funcionar, pero un recurso que se usa ampliamente, aún más hoy en día, termina quedando fuera porque es tan simple que algunos se olvidan, el servicio de resolución de nombres, también conocido como DNS.

Probablemente el 99% de lo que usa tanto en Internet como «en casa» se resuelve por nombre, este blog, por ejemplo, llegó aquí por dirección de nombre, no puede acceder a él a través de IP, su servicio de correo electrónico, ningún sitio web, esa dirección en el oyente de SQL, etc.

A pesar de que se trata de una simple solicitud UDP en el puerto 53, esta solicitud genera tráfico de Internet, ya que cada vez que alguien revisa una dirección, tiene que suceder toda una magia, básicamente es así:

La solicitud de aplicación se reenvía al SoThis solicitud pasa al mini-controlador de red y busca en la memoria caché para averiguar si hay algo en la memoria caché para avanzar en el servicio, si no lo tiene... obtener la lista de direcciones DNS registradas en la interfazsolicita al DNS registrado que resuelva el nombre de la dirección solicitadaSi los servidores registrados tienen la dirección en caché, la devuelve al solicitante si no,, Vaya a la raíz registrada para iniciar la consulta pública, todo comienza con el «.» luego el sufijo que puede ser «com», «net», «br», «ca», etc... Luego, busque el nombre intermedio del dominio, que es el nombre en sí, y resuelve el DNS maestro y esclavo y se conecta al DNS maestro y esclavo y resuelve el SOASPregunta sobre el RR de la dirección en cuestión y luego la respuesta puede variar a una A, MX, AAA, TXT, CNAME, etc.regresa con el resultado al DNS registrado allí en la interfaz, lo almacena en caché por TTL y devuelve la resolución de nombres a la interfaz solicitante con el TTL del registro

Básicamente, debido a que es un poco más complejo que eso, este es el proceso que se realiza para cada vez que se solicita una resolución de nombre, todo en UDP y lo más rápido posible.

¿Y qué tiene que ver el RFC 8482 con esto?

De forma predeterminada, cuando se realiza una consulta DNS, este método es directo, un RR para un dominio y eso es todo, pero hay un método de consulta que es CUALQUIERA que básicamente significa traer toda la información disponible del dominio solicitado.

Esta «información completa» consiste en:

Nombres de servidor: DNSSerialRefresh de la expiración de TTL de Retryzone Nombre de correo electrónico del respondedor del servidor de respuesta principal mxEnvíe la IP de respuesta a la raíz

Vale, pero ¿cuál es el problema?

El volumen recorrido es mayor, el tiempo de conexión DNS es más largo y el volumen de solicitudes puede afectar el rendimiento de la experiencia. Para dar tiempo de espera a la solicitud de DNS, el servicio puede tardar hasta 2 segundos en resolver la dirección, imagine esto para una aplicación en la que el tiempo total dedicado 2 segundos fue solo para resolver el nombre, donde tendrá que intentarlo de nuevo porque hubo un tiempo de espera.

Existe un método de ataque que es la amplificación de DNS, donde una ola de CUALQUIER solicitud sobrecarga el servicio causando un DDoS y sin DNS sin aplicación.

En la punta del lápiz, estamos hablando de una solicitud directa que solicita algo de alrededor de 44 bytes, mientras que una solicitud ANY (puede variar) pero para una propina promedio de 890 bytes.

No parece mucho, ¿verdad? ahora imagine que para un servidor DNS que responde no solo a sus solicitudes sino a todos los dominios registrados en él, replicando más a uno secundario, más actualizaciones provenientes de las aplicaciones.

¿Cómo evitar CUALQUIER solicitud?

Básicamente, agregue un RR al DNS de tipo HINFO con algo de información.

Por ejemplo, HINFO RFC8482

¿quién hace eso?

Wikipedia, CloudFront