Este fin de semana casi nos cargamos a un pobre servidor DNS por un exceso de consultas al realizar un envío de varios miles de mails. En algunos servidores Linux, no hay una caché DNS a nivel de sistema operativo, y por tanto, cada envío de mail requiere de su correspondiente resolución DNS, a pesar de que se estén enviando 1.000.000 de mails todos al mismo dominio @miempresa.com. [fuente, otra fuente, y más fuentes].
Ésto lo podemos comprobar, por ejemplo desde mi portátil con Fedora, monitorizando con tcpdump las peticiones DNS y ejecutando en paralelo un «ping google.com»:
[root@AdriPC sh]# tcpdump -vvv -s 0 -l port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:44:09.480324 IP (tos 0x0, ttl 64, id 14684, offset 0, flags [DF], proto UDP (17), length 59)
AdriIPC.36193 > google-public-dns-a.google.com.domain: [udp sum ok] 14321+ A? www.google.es. (31)
16:44:09.509206 IP (tos 0x0, ttl 64, id 14713, offset 0, flags [DF], proto UDP (17), length 66)
AdriIPC.51444 > google-public-dns-a.google.com.domain: [udp sum ok] 64003+ PTR? 8.8.8.8.in-addr.arpa. (38)
16:44:09.520190 IP (tos 0x0, ttl 48, id 61176, offset 0, flags [none], proto UDP (17), length 91)
google-public-dns-a.google.com.domain > AdriIPC.36193: [udp sum ok] 14321 q: A? www.google.es. 2/0/0 www.google.es. [3m28s] A 173.194.34.247, www.google.es. [3m28s] A 173.194.34.248 (63)
16:44:09.533873 IP (tos 0x0, ttl 64, id 14738, offset 0, flags [DF], proto UDP (17), length 73)
AdriIPC.50336 > google-public-dns-a.google.com.domain: [udp sum ok] 27187+ PTR? 247.34.194.173.in-addr.arpa. (45)[…]
Si ejecutamos «ping google.com» una segunda vez, veremos como vuelve a capturarse la consulta DNS mediante tcpdump, confirmando así que no hay ningún tipo de caché DNS.
En la mayoría de escenarios, no necesitaremos una caché DNS, pero si tenemos un servidor que ofrece un servicio que hace un uso intensivo de resolución de nombres, seguramente nos merezca la pena buscar una solución.