Por defecto servidor bind (named) está configurado para ser recursivo (fichero de configuración named.conf)

options {
         recursion no;
}

Nuestro servidor puede ser recursivo, pero siempre aceptando sólo peticiones de nuestra red local o de nuestros clientes mediante ACL's (Listas de acceso)

recursion yes;
allow-query { localhost; };
allow-recursion { localhost; };
allow-query-cache { localhost; };

Creando una ACL:

acl redlocal {
  127.0.0.1;
  192.168.0.2;
  192.168.0.1/24;
};

Permitiendo al grupo "redlocal"

 recursion yes;
allow-query { localhost; redlocal; };
allow-recursion { localhost; redlocal; };
allow-query-cache { localhost; redlocal; };

O usando las vistas (views):

//Put all your “trusted” IPs in here.
acl "inside" {
127/8; 10.0.10/24; 192.168.1/24; };
//zone declarations go here.
view "inside" {
match-clients { "inside"; };
recursion yes;
};
//Same zone declarations go here too.
view "outside" {
match-clients { any; };
recursion no;
};

Si somos recursivos se pueden producir ataques de varios tipos:

• DNS Cache Poisoning Attacks  (aprovechando el TTL)
• DNS Amplification and Reflection Attacks
• Ataques DDoS

options {
allow-update { none; };
allow-transfer { none; };
}

Logging en named.conf

Configuración avanzada

DNS Security Extensions (DNSSEC)

DNSSEC permite asegurar la autenticidad de la respuesta DNS. Siempre que el navegador envíe una petición, ésta se devuelve con una clave de autentificación, que atestigua que la IP reenviada es correcta.

Para entender el DNSSEC, se debe entender qué es la asymmetric cryptography (criptografía asimétrica). Esta consiste en dos claves: una pública y otra privada.

La clave privada suele generarse en información cifrada, mientras la clave pública solo permite la lectura.
La clave privada es necesaria para generar una clave pública. Por lo tanto, si tu clave pública cifrada o tu información es corrupta, no podrá leer la información.

Actualmente se recomienda cambiar la ZSJ cada 3 meses y la KSK cada año y debe tener presente que ha de validar su zona TLD.

En el caso de DNSSEC, después de que el administrador haya añadido un cifrado a ese área(RRSIG), el DNS de cada campo usa su clave privada y hace disponible una clave pública (DNSKEY), por lo que usted podrá leer. Y nosotros pasamos una huella en el registro clave (DS).

• ZSK : Compuesta de una clave pública y una clave privada, se usan para consignar los campos en el área. Estas claves son desconocidas para el registro.
• KSK : Compuesta de una clave pública y una clave privada, se usan solo para consignar las claves ZSK. Estas claves son consignadas por un campo DS en la zona parental.
• DNSKEY : Campos que contienen la clave pública.
• DS : Esta es un truncamiento de una DNSKEY, es reenviado a la zona parental.

Fichero /etc/named.conf

dnssec-enable yes;
dnssec-validation yes;

Para BIND 9.8 y 9.9

Si elegimos auto se descarga la root key la primera vez que se ejecuta

dnssec-validation auto
dnssec-lookaside auto

Para BIND 9.7, es manual:

/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";

Las llaves DLV ((DNSSEC Look-aside Validation) son un recurso adicional utilizado en aquellos servidores DNSSEC con recursividad.

trusted-keys {
dlv.isc.org. 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh";
};

Disponibles en:

https://www.isc.org/downloads/bind/bind-keys/

zone "elhacker.net" IN {
type master;
file "elhacker.net.zone.signed";
};

Para "firmar" las zonas tenemos varias opciones

•  dnssec-keygen
• dnssec-tools (zonesigner)

Posibles Errores:

25-Dec-2013 12:42:53.427 error (no valid RRSIG) resolving 'd1.whatsapp.net.dlv.isc.org/DS/IN': 8.8.4.4#53

Opciones de seguridad

options {
transfers-per-ns 2;
};

Limitando el número total de las transferencias de zona solicitada

options {
transfers-in 10;
};

Limitando el número total de las transferencias de zona servida

options {
transfers-out 10;
};

Limitando la duración de la transferencia de un dominio en minutos:

options {
max-transfer-time-in 180;
};

Limitar la frecuencia de las transferencias de zona:

options {
max-refresh-time 86400; // refresh should never be more than a day
min-refresh-time 1800; // or less than 30 minutes }; 

Response Rate Limiting (RRL)

 Limitando los recursos

options {
datasize 2g;
};

Máximo de memoria para la caché:

options {
max-cache-size  2g;
};

Errores comunes fichero syslog

Dec 19 22:48:42 ns2 named[31598]: success resolving 'weblist.teamspeak.com/A' (in 'teamspeak.com'?) after disabling EDNS
Dec 19 22:48:44 ns2 named[31598]: success resolving 'www.google.es/A' (in 'google.es'?) after reducing the advertised EDNS UDP packet size to 512 octets
Dec 19 22:48:44 ns2 named[31598]: success resolving 'clients3.google.com/A' (in 'google.com'?) after disabling EDNS

Soluciones: asjutar tamaño udp-size a 512:

edns-udp-size 512;

La variable max-udp-size controla el max que tu envias, edns-udp-size lo que recibes.

Se puede deshabilitar edns (fuera de la clausula options), pero no es una opción recomendada.

server 0.0.0.0/0 {
       edns no;
};

Y en IPv6

server ::/0 {
       edns no;
};

error (unexpected RCODE REFUSED) resolving
20-Dec-2013 10:39:47.838 error (unexpected RCODE REFUSED) resolving '129.230.114.75.in-addr.arpa/PTR/IN': 71.44.33.20#53
20-Dec-2013 10:39:47.981 error (unexpected RCODE REFUSED) resolving '129.230.114.75.in-addr.arpa/PTR/IN': 71.44.37.20#53
20-Dec-2013 10:39:49.716 error (unexpected RCODE REFUSED) resolving '104.16.114.75.in-addr.arpa/PTR/IN': 71.44.37.20#53
20-Dec-2013 10:39:49.856 error (unexpected RCODE REFUSED) resolving '104.16.114.75.in-addr.arpa/PTR/IN': 71.44.33.20#53

Son los servidores "forwarders" que renuncian nuestras consultas, suelen ser como en nuestro caso a querys de reversos ( .in-addr.arpa)

Gestión de Errores y Rendimiento (Tunning)

named[pid]: socket(SOCK_RAW): Too many open files

Añadir el número de ficheros abiertos:

options {
files number;
};

• clients-per-query
• tcp-clients
• recursive-clients

no more recursive clients: quota reached

Permitir más clientes recursivos (por defecto son 100)

options { recursive-clients 2000;};

Errores host unreachable o network unreachable

error (host unreachable) resolving ....
error (host unreachable) resolving 'hotmail.com/AAAA/IN': 209.244.0.4#53
error (host unreachable) resolving 'gmail.com/AAAA/IN': 8.8.8.8#53

En algunos casos puede deberse a utilizar la opción query-source en named.conf

options {

 // no usar

  query-source address * port 53;

} 

Recordemos que el query-soruce sólo se aplica a las consultas salientes, es decir, al tráfico saliente y las entrantes seguirán siendo por el puerto 53, pero puede ser peligroso, concecntrar todo el tráfico (entrante y saliente) por el mismo puerto dando incluso eventuales errores.

error (network unreachable) resolving ...
error (network unreachable) resolving 'e.root-servers.net/AAAA/IN': 2001:500:2f::f#53
error (network unreachable) resolving 'dns.ovh.net/A/IN': 2001:500:2d::d#53
 error (network unreachable) resolving 'ns.ovh.net/A/IN': 2001:41d0:1:1983::1#53

Vemos que hay dirección IPv6

Si los errores son network unreachable es muy probable que las peticiones sean a servidores DNS IPv6 y y si nosotros no tenemos una red dual-stack (IPv4 + IPv6) no somos capaces de leer la respuesta.

Para solucionarlo podemos añadir la opción -4 para arrancar Bind (named) en el fichero /etc/sysconfig/named

OPTIONS="-4

También podemos deshabilitar por completo la red IPv6 en grub.conf con el parámetro:

ipv6.disable=1

O en el fichero sysctl.conf

# disable ipv6
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

O bien en el fichero /etc/sysconfig/network-scripts/ifcfg-eth0

IPV6INIT=no
IPV6_AUTOCONF=no

limit responses to 188.165.235.0/24
stop limiting error responses to 176.221.80.0/24

Por defecto son 100:

clients-per-query increased to 15
clients-per-query decreased to 13

Registros AAAA ipv6

El porcentaje del uso de IPv6 se va extendiendo y en este momento el 90,1% de TLD'S ya aceptan Ipv6

Top Level Domains (TLDs): 362

TLDs with IPv6 nameservers: 326
Percentage of TLDs with IPv6 nameservers: 90.1%  

Añadir al fichero  de configuración named.conf

options {
...
listen-on-v6 {any};
...
}

Los registros Ipv6 se hacen con AAAA (cuatro A's) que es el equivalente al registro A de ipv4

www.elhacker.net.    IN    A     2001:4860:4860:0:0:0:0:8888
foro.elhacker.net.    IN    A     2001:4860:4860:0:0:0:0:8888

Por supuesto se puede mezclar registros ipv4 con registros ipv6 (siempre y cuando tengamos la pila dual) (dual (IPv4/IPv6) IP stacks)

www.elhacker.net.    IN    A    91.126.217.153
foro.elhacker.net.    IN    A    91.126.217.153
www.elhacker.net.    IN    AAAA     2001:4860:4860:0:0:0:0:8888
foro.elhacker.net.    IN    AAAA     2001:4860:4860:0:0:0:0:8888

El orden por defecto de prioridad IPv4-IPv6 es cíclico o basado en round-robin.

O de una manera más simple y organizada:

www    IN    A    91.126.217.153
       .    IN    AAAA    2001:4860:4860:0:0:0:0:8888
foro      IN    A     91.126.217.153
            IN    AAAA     2001:4860:4860:0:0:0:0:8888

Ejemplo de configuración: 

$TTL 1h ; Default TTL
@ IN SOA ns.elhacker.net. webmaster.elhacker.net. (
 2013122001 ; serial
 1h  ; slave refresh interval
 15m  ; slave retry interval
 1w  ; slave copy expire time
 1h  ; NXDOMAIN cache time
 )

;
; domain name servers
;
@ IN NS ns.elhacker.net.

 O muchos servicios usan el subodminio (Google, Facebook, Youtube) o previfo ipv6 para indicarlo:

 ipv6.elhacker.net.    IN    AAAA     2001:4860:4860:0:0:0:0:8888

Para comprobar si funciona correctamente podemos hacer una query (consulta con dig a localhost)

dig -6 +short @::1  www.elhacker.net AAA

O preguntando al servidor público de Google DNS

dig @2001:4860:4860::8888 www.elhacker.net. AAAA +cd

Registros Inversos (Reversos) PTR con IPv6

 Los registros llamados IN-ADDR.ARPA  pasan a ser  IP6.ARPA

; IPv6 PTR entries
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.0.2.0.1.0.2.0.8.f.4.0.1.0.a.2.ip6.arpa. IN PTR ns.elhacker.net.

Y en named.conf

zone "2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.0.2.0.1.0.2.0.8.f.4.0.1.0.a.2.ip6.arpa"
{
 type master;
 file "/etc/bind/2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.0.2.0.1.0.2.0.8.f.4.0.1.0.a.2.ip6.arpa";
};

Servidores públicos DNS en formato IPv6

Servidores DNS Google IPv4

• 8.8.8.8
• 8.8.4.4

Servidores DNS Google IPv6

• 2001:4860:4860::8888
• 2001:4860:4860::8844

Servidores OpenDNS  IPv4

• 208.67.222.222
• 208.67.222.220

Servidores OpenDNS  IPv6

• 2620:0:ccc::2
• 2620:0:ccd::2