unbound, dnsmasq, bind9, pdns nscd (Name Service Cache Daemon), varios programas que permiten cachear host lookups para los programas en ejecución y guardar los resultados para la siguiente consulta (query), con esto podemos reducir considerablemente el número de consultas DNS (host lookups).

ejemplo d + 3

Explicación de los parámetros:

domain-needed: Indica al dnsmasq que NO envíe peticiones a los servidores de DNS aquellas peticiones que no tengan un formato de FQDN (Fully Qualified Domain name), es decir que no sean direcciones de Internet, y si es el caso regresará el mensaje “not found”

bogus-priv: Indica al dnsmasq que NO envíe al siguiente servidor DNS las peticiones de reversa(rDNS) que pertenezcan a un segmento de IP privadas(clase A, B, C, E), p. ej. si se solicita «nslookup 10.0.0.1» el dnsmasq en vez de pasar la petición al servidor de DNS usará el archivo «/etc/hosts» para resolver la petición, en caso de no poder resolverlo devolverá un mensaje de «no such domain»

no-resolv: Indica al dnsmasq que no debe de usar archivo “/etc/resolv.conf” para resolver las peticiones DNS, en vez de ello debe de usar los siguientes servidores

server=8.8.8.8: Indica al dnsmasq que debe de usar el servidor 8.8.8.8 de google para resolver las peticiones de DNS

server=208.67.222.222: Indica al dnsmasq que de no poder contactar el servidor o resolver la dirección solicitada usando el servidor 8.8.8.8 intente con 208.67.222.222 el cual es un servicio DNS de google

server=8.8.4.4: Indica al dnsmasq que de no poder contactar el servidor o resolver la dirección solicitada usando el servidor 208.67.222.222 intente con 8.8.4.4 el cual es el servicio secundario de los DNS de google

listen-address=127.0.0.1: Indica al dnsmasq que permita recibir y procesar peticiones DNS que busquen la dirección IP 127.0.0.1

listen-address=10.0.30.200: Indica al dnsmasq que permita recibir y procesar peticiones DNS que busquen la dirección IP local 10.0.30.200

cache-size=9123: Indica la cantidad de dominios que podrá almacenar, el máximo es de 10,000 dominios

min-cache-ttl=900: Indica el tiempo mínimo que la dirección quedará guardada en la memoria caché

interface=eth0: Si el servidor cuenta con más de una interfaz de red, se usa este parámetro para especificar qué interface(s) podrán recibir y responder peticiones de DNS

unbound

Podemos utilizar unbound, un servidor DNS recursivo seguro de código abierto desarrollado principalmente por NLnet Labs, VeriSign Inc, Nominet y Kirei. Es utilizado, por ejemplo, en Pi-Hole.

Un servidor DNS recursivo, es el intermediario entre los clientes y los servidores DNS que contienen la información veraz que relaciona los nombres de dominio con una o varias direcciones IP.

Primero el DNS recursivo consulta en su caché si dispone de la información solicitada, en caso negativo pregunta a un servidor DNS raíz, seguida de una solicitud a un servidor DNS de primer nivel y finalmente a un servidor DNS autoritativo.

Con lo anterior, deducimos que nuestro servidor DNS recursivo se volverá más rápido con el tiempo, al disponer de más información guardada en cache.

La configuración principal se encuentra en /etc/unbound/unbound.conf

Vamos a configurar paso a paso el servidor DNS:

Control de acceso al servidor DNS: se definen tantas reglas como necesitemos para permitir allow o denegar deny el acceso al servidor DNS. En este caso, damos acceso a la red local 192.168.1.0/24 y a la interfaz loopback.

access-control: 127.0.0.0/8 allow

access-control: 192.168.1.0/24 allow

    Definimos el puerto, interfaz y protocolo del servidor DNS. Podemos definir tantas interfaces como queramos, incluso cada una puede escuchar en un puerto distinto. En este caso, el servidor DNS escuchará en la red local y en la red interna, por el puerto 53, para los protocolos tcp y udp pero solo por ipv4.

interface: 127.0.0.1

interface: 192.168.1.1

port: 53

do-ip4: yes

do-udp: yes

do-tcp: yes

El resto de configuraciones son varias mejoras que se especifican en la documentación oficial:

harden-dnssec-stripped: yes     # habilita la verificación DNSSEC

prefetch: yes                   # el servidor actualiza la cache de elementos que van a expirar antes de que suceda,

                                # solo aplica a los dominios más utilizados

num-threads: 1                  # número de hilos a utilizar

so-rcvbuf: 1m                   # más espacio en el buffer para evitar errores bajo alta carga

El resultado será un servidor DNS recursivo funcional, a continuación el fichero de configuración completo:

include: "/etc/unbound/unbound.conf.d/*.conf"

server:

    logfile: "/var/log/unbound/unbound.log"

    verbosity: 1

    access-control: 127.0.0.0/8 allow

    access-control: 192.168.1.0/24 allow

    interface: 127.0.0.1

    interface: 192.168.1.1

    port: 53

    do-ip4: yes

    do-udp: yes

    do-tcp: yes

    harden-dnssec-stripped: yes

    prefetch: yes

    num-threads: 1

    so-rcvbuf: 1m

Por último, queremos añadir al menos una entrada que indique a Unbound a dónde reenviar las peticiones para la recursividad. Ten en cuenta que podríamos reenviar dominios específicos a servidores DNS específicos. En este ejemplo, voy a reenviar todo a un par de servidores DNS en Internet:

    ###########################################################################

    # FORWARD ZONE

    ###########################################################################

    forward-zone:

        # Forward all queries (except those in cache and local zone) to

        # upstream recursive servers

        name: "."

        # Queries to this forward zone use TLS

        forward-tls-upstream: yes

        # https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers

        # Cloudflare

        forward-addr: 1.1.1.1@853#cloudflare-dns.com

        forward-addr: 1.0.0.1@853#cloudflare-dns.com

        #forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com

        #forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com

Ahora, como control de sanidad, queremos ejecutar el  siguiente comando  para comprobar la sintaxis de nuestro archivo de configuración.

 unbound-checkconf,

Para poner en marcha unbound lo habilitamos y reiniciamos:

$ sudo systemctl enable unbound.service

$ sudo systemctl restart unbound.service

Configuración del control remoto en Unbound

pdnsd

bind9 como servidor caché de DNS

Para poder usar bind como servidor caché DNS debe estar configurado como un servidor recursivo. Esto puede ser potencialmente peligroso (DNS poisoning) así que debemos controlar mediante acls quién puede hacer consultas (querys) y quién no.


El servidor DNS recursivo configurado de tal manera que sólo (nosotros) localhost pueda hacer consultas:

options {
[..]
recursion yes;
allow-query { localhost; };
allow-recursion { localhost; };
allow-query-cache { localhost; };
}

O podemos crear una acl

acl "redlocal" {
  127.0.0.1;
  192.168.1.0/24; 
  192.168.2.0/24;
  192.168.3.0/24;
};

 Y dejar sólo a la ip's y rangos de "redlocal" que puedan hacer consultas:

allow-query {
  redlocal;
 };

Añadimos los forwarders que son los que realmente resolverán las peticiones en caso que no sean nuestros propios dominios.

forward only; // solo activar si no tenemos ningún dominio propio en BIND
 forwarders {
213.133.98.98;
213.133.99.99;
213.133.100.100;
8.8.8.8;
8.8.4.4;
208.67.222.222;
208.67.220.220;
209.244.0.3;
209.244.0.4;
74.82.42.42;
   };

 En el caso que seamos un servidor dns de un dominio si nos interesa que cualquiera (any) pueda hacer consultas sobre nuestro dominio. Pero sólo sobre nuestro dominio, por lo tanto el allow-query any debe estar dentro de la zone de elhacker.net

zone "elhacker.net" {
    type master;
    file "/var/named/elhacker.net.hosts";
allow-transfer { none; };
allow-query { any; };
    };

De esta manera los clientes externos no pueden hacer consultas recursivas, pero si pueden consultar nuestro dominio:

nslookup elhacker.net  ns2.elhacker.net
Server:         ns2.elhacker.net
Address:        91.126.217.153#53

Name:   elhacker.net
Address: 91.126.217.153

Pero no los que no son nuestros (gracias allow-query localhost o redlocal de options)

nslookup google.es ns2.elhacker.net
Server:         ns2.elhacker.net
Address:        91.126.217.153#53

** server can't find google.es: REFUSED

Los clientes internos si pueden

nslookup google.es
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   google.es
Address: 173.194.70.94

Si queremos  ver todas las consultas (querys) que está recibiendo el servidor bind, debemos activar el querylog (por defecto desactivado) con el comando:

rndc querylog

Verificar que se ha activado el querylog:

 rndc status
query logging is ON 

 Ver el querylog por defecto en syslog o si los hemos definido en otro lugar:

logging {
channel "querylog" { file "/var/log/querys"; print-time yes; };
category queries { querylog; };
};

En nuestro ejemplo en  /var/log/querys

tail -f /var/log/querys

Para ver todos los resultados caheados (en caché) de BIND en el fichero named_dump.db

rndc dumpdb -cache 

El fichero  named_dump.db se encontrará en el mismo directorio dónde esté indicado con la directiva options directory "/etc"; a no ser que hayamos usado la directiva dump-file con otra ruta

Si tenemos bind chroot:

dump-file "/var/named/data/cache_dump.db";

El fichero estará en /var/named/chroot/var/log

Para ver el contenido:

less  /var/named/chroot/var/log/named_dump.db | grep google.com

Para ver las consultas recursivas:

rndc recursing

Nota importante: aunque tengamos la query-caché activa algunos servidores como google o facebook tienen un valor TTL (Time-To-Live) extremadamente muy bajo (5 minutos o menos), lo que hace que la query caché esté cacheada durante el tiempo que ellos indiquen.

Si queremos aumentar al máximo los valores que se guardan en caché:

options {
// 30 minutos en caché, respuesta dns caheadas no autoritativas, forwarders
 lame-ttl 1800;
 // limpiar caché cada 120 minutos, por defecto es cada 60 minutos
cleaning-interval 120;
// por defecto respuestas negativas son 3 horas
max-ncache-ttl 3600; // 3600 segundos es 1 hora
// caché de resultados positivos
max-cache-ttl 7d; // por defecto es 1 semana 7 días
};

Lista de servidores DNS Públicos (recursivos):

Puedes utilizar como forwarders:

Proveedor	IP DNS Primario	IP DNS Secundario
CloudFlare	1.1.1.1	1.0.0.1
Level3	209.244.0.3	209.244.0.4
Google	8.8.8.8	8.8.4.4
Securly	184.169.143.224	184.169.161.155
Comodo Secure DNS	8.26.56.26	8.20.247.20
OpenDNS Home	208.67.222.222	208.67.220.220
Quad9	9.9.9.9	149.112.112.112
DNS Advantage	156.154.70.1	156.154.71.1
Norton ConnectSafe	198.153.192.40	198.153.194.40
ScrubIT	67.138.54.120	207.225.209.77
SafeDNS	195.46.39.39	195.46.39.40
DNSResolvers.com	205.210.42.205	64.68.200.200
OpenNIC	74.207.247.4	64.0.55.201
Public-Root	199.5.157.131	208.71.35.137
SmartViper	208.76.50.50	208.76.51.51
Dyn	216.146.35.35	216.146.36.36
censurfridns.dk	89.233.43.71	89.104.194.142
Hurricane Electric	74.82.42.42	-
puntCAT	109.69.8.51

http://pcsupport.about.com/od/tipstricks/a/free-public-dns-servers.htm


 y ahora debemos indicar al fichero /etc/resolv.conf que somos nosotros mismos el servidor DNS de nombres:

nameserver 127.0.0.1

 

Vaciar o Limpiar caché de las DNS

•  En Windows desde la línea de comandos (cmd) con el comando ipconfig podemos borrar la caché:

ipconfig /flushdns

Para ver la caché de las DNS de Windows

ipconfig /displaydns

• En Linux si usamos el daemon nscd

/etc/rc.d/init.d/nscd restart 

 

• Con Systemd  resolved
  

sudo systemd-resolve --flush-caches

Si usamos dnsmasq

/etc/init.d/dnsmasq restart

Limpiar caché bind

rndc flush

 Limpiar la cahé de un dominio

rndc flushname elhacker.net

Refrescar caché bind

rndc dumpdb -cache
vi /var/named/data/cache_dump.db

• En MacOS según la versión:

Para limpiar la cache DNS en Mac OS X Leopard:

lookupd -flushcache

Para limpiar la cache DNS en Mac OS X:

dscacheutil -flushcache

Ir > Utilidades y a continuación seleccionamos Terminal. Una vez abierto el Terminal, debemos ejecutar el comando que corresponda en función de la versión de macOS que tengamos instalada:

• macOS El Capitan, Sierra, High Sierra, Mojave y Catalina: sudo killall -HUP mDNSResponder
• macOS Yosemite: sudo discoveryutil udnsflushcaches
• macOS Lion, Mountain Lion y Mavericks: sudo killall -HUP mDNSResponder
• macOS Snow Leopard: sudo dscacheutil -flushcache
• macOS Leopard: sudo lookupd -flushcache

 Limpiar el caché DNS en el navegador Google Chrome 

Pestaña en blanco en el navegador y escribimos en la barra de direcciones del navegador:

chrome://net-internals/#dns

Hacer click en el botón "Clear host caché” para borrar todo el caché DNS que está almacenado.

Para limpiar las conexiones tenemos que abrir en la barra de direcciones:

chrome://net-internals/#sockets

 Limpiar el caché DNS en el navegador Mozilla Firefox

Los pasos a seguir para borrar la caché DNS en el navegador web de Mozilla cambian respecto al navegador de Google. Esto es lo que debemos hacer en Firefox:

• Abrimos una nueva ventana de Mozilla Firefox.
• Escribimos en la barra de direcciones about:config y pulsamos Enter.
• Buscamos la entrada network.dnsCacheExpiration.
• Una vez la hemos encontrado hacemos clic sobre ella y establecemos su valor a 0.
• Esto hará que el propio navegador ignore su propia caché DNS.

 Limpiar el caché DNS en el navegador Microsoft Edge

Con la versión de Microsoft Edge basado en Chromium también es posible vaciar la caché DNS a nivel de navegador siguiendo estos sencillos pasos:

• Abrimos una ventana de Edge Chromium.
• Escribimos edge://net-internals/#dns en la barra de direcciones y pulsamos Enter.
• Ahora de nos mostrará una página donde veremos todas las resoluciones DNS realizadas desde el navegador.
• Pulsamos en el botón Clear host caché y automáticamente se borrará toda la caché DNS almacenada en Edge.