Configurar servidor DNS caché con tu Raspberry Pi para mejorar la velocidad del Tráfico de tu Red Local

Un de las piezas claves hoy en día de nuestro Internet que permite que funcione, son las Domain Name System o mayormente conocido como DNS. Este sistema de servidores DNS es el encargado de traducir los nombres de dominio que manejamos habitualmente, como mascandobits.es, en la dirección IP del ordenador donde está alojado ese dominio, que en el momento de escribir esta entrada es 31.220.20.199 .

 

Contextualización


Cada ordenador en Internet tiene una dirección IP que es única para ese ordenador (por lo menos en la red que pertenece). La IP está formada por cuatro números enteros de 0 a 255, separados por puntos. 127.0.0.1 es un ejemplo de dirección IP que además es especial porque hace referencia a nuestra propia máquina. Cada vez que te conectas a Internet, a tu ordenador se le asigna una dirección IP, puede ser siempre la misma o puede variar, lo normal es que cada vez que reinicies el router o al cabo de un tiempo obtengas una IP diferente.

Esta IP que tiene tu equipo, y que te proporciona tu router, es privada y solo funciona en el rango de tu red local (dispositivos conectados a tu router). Existe un conjunto de rangos de IP que son usados como IPs privadas:

  • 192.168.0.0 – 192.168.255.255 (65,536 direcciones IP)
  • 172.16.0.0 – 172.31.255.255 (1,048,576 direcciones IP)
  • 10.0.0.0 – 10.255.255.255 (16,777,216 direcciones IP)

El primer grupo de IPs lo puedes ver en la red local de tu casa o empresa (si es pequeña), el segundo grupo en empresas algo más grandes y el último grupo es común verlo para equipos conectados mediante VPN.

A su vez existe una segunda IP denominada pública que es la que tu ISP o proveedor de servicios te asigna al router y que sirve para poder acceder a Internet. Esta IP pública suele ser dinámica en la mayor parte de los casos y tu ISP se la asigna a tu router, normalmente reiniciando el router puede cambiar esta IP.

La conversión de una IP privada a una pública y viceversa se hace gracias a la Network Address Translation o NAT del router. Esto permite hacer peticiones a IPs publicas de servicios de Internet y devolver el tráfico de respuesta a la IP privada de la máquina que hizo las peticiones.

Un vez aclarado esta parte que es básica avancemos….

Los ordenadores donde están alojadas las páginas web o servicios tienen siempre la misma dirección IP, esto permite acceder dichos recursos siempre igual con la misma IP (a no ser que se cambie…). Sin embargo, cuando buscas una determinada página o servicios, en tu navegador no introduces la IP del ordenador donde está alojada, sino algo más sencillo de recordar, introduces un nombre de dominio, como mascandobits.es. Adicionalmente he dicho que normalmente no se cambia la IP de la web o servicio, pero puede darse el caso por ejemplo de que se quiera mover la web o servicio a otra máquina que muy seguramente tenga otra IP pública.  Gracias a las DNS este problema queda cubierto, ya que simplemente basta con asociar el dominio con la nueva IP pública.

Cuando escribes en tu navegador el nombre de una web o servicio, lo que hace tu ordenador es preguntar a tu servidor local DNS (el que te indica tu router por DCHP) por la dirección IP del ordenador donde está alojada esa página o servicio. El servidor DNS es una gran base de datos con infinidad de traducciones de nombres de dominio a dirección IP. Esa base de datos es distribuida y compartida con otros proveedores y sus respectivos servidores DNS. Si el nombre de dominio que estás buscando no está en tu DNS local, éste realizará una petición a otros DNS de la red hasta encontrar la traducción adecuada. Estas bases de datos guardan en caché durante unos días esas traducciones de nombre de dominio a IP, por eso a veces sucede que si una web o servicio cambia de servidor, puede que desde algunos lugares del planeta se acceda a la web o servicio y desde otros no, porque hay ordenadores que cuando preguntan por la página, el servidor DNS los envía a la antigua dirección IP y no a la nueva.

Además de los servidores DNS, nuestro ordenador también guarda un caché de las DNS, y si hemos visitado recientemente una página web, nuestro ordenador ya no preguntará al servidor cuál es la dirección IP de la página, sino que se dirigirá a la que ya tiene almacenada. Esta caché puede borrarse.

Para borrarla desde Windows:

ipconfig /flushdns

Para borrarla desde GNU-Linux:

sudo /etc/init.d/nscd restart  //si usas nscd dns cache
sudo /etc/init.d/dnsmasq restart  //si usas dnsmasq dns cache
sudo /etc/init.d/named restart  //si usas bind dns cache
sudo /etc/init.d/bind9 restart  //(alternativa) si usas bind dns cache

 

Configurar servidor DNS caché


Las DNS constituyen la columna vertebral del funcionamiento de Internet y dado su función constituye un riesgo una mala gestión de los DNS globales que son gestionados por la ICANN, una asociación sin ánimo de lucro. Existen 7 llaves que dan acceso físico a los DNS y que se reparten entre 14 personas, 7 titulares y 7 suplentes. Son los garantes de que los DNS no sean atacadoso o modifcados de manera no deseada:

Como puedes deducir el acceso a la resolución de DNS es algo que puede ser muy crítico. La ICANN sólo constituye el registro de una parte de Internet, aunque habitualmente se suelen usar sus DNS como referencia, ya que a su vez las operadoras que dan acceso a Internet (ISP) tienen sus propio DNS que van configurados en nuestro router y los cuales podemos cambiar por otros que sean de nuestro agrado.

Controlar las DNS y cómo se resuelven es algo que puede ser ventajoso, sobre todo si tenemos dentro de nuestra red local el servidor DNS y la resolución de dominios tiene una menor latencia. Para crear nuestro DNS caché lo podemos hacer con una Raspberry Pi conectada a nuestra red local de casa. Una Raspberry Pi consume como un móvil cargando y puede servirnos perfectamente para este cometido de acelerar las peticiones de resolución de DNS.

Accedemos a nuestra Raspberry Pi por SSH e introducimos el siguiente comando:

sudo apt-get install bind9 dnsutils

Con esto instalamos bind y además instalamos la herramienta dig (con el paquete dnsutil) que más adelante ya veréis para qué sirve.

Un vez instalado vamos a /etc/bind/named.conf.options, puedes configurarlo con el siguiente comando:

sudo nano /etc/bind/named.conf.options

Lo puedes configurar con la siguiente información:

    forwarders {
         208.67.222.222;
         208.67.220.220;
    };

Es posible que tengas que quitar la // para que tenga efecto. Todo lo que va precedido con // se trata como un comentario. Yo he usado como forwarders las DNS de OpenDNS, pero puedes usar las que quieras o añadir otras.

Ahora recargamos las configuraciones con el siguiente comando:

rndc reload

Ya tenemos funcionando nuestro servidor DNS cacche. Para comprobar la diferencia de tiempos de resolución vamos a hacer la siguiente prueba. Vamos a resolver las peticiones contra las DNS de Google (8.8.8.8) (se asume que son de lo mejorcito 😉 ) y contra nuestro nuevo servidor DNS caché en la Raspberry Pi.

Introducimos el siguiente comando para comprobar el tiempo de respuesta para la resolución del dominio mascandobits.es con las DNS de Google:

dig mascandobits.es  @8.8.8.8

; <<>> DiG 9.9.5-9+deb8u13-Raspbian <<>> mascandobits.es @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28184
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mascandobits.es.               IN      A

;; ANSWER SECTION:
mascandobits.es.        2684    IN      A       31.220.20.199

;; Query time: 42 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 26 19:11:51 CEST 2017
;; MSG SIZE  rcvd: 60

Nos devuelve 42 msec, que no está anda mal, pero vamos a ejecutar lo mismo usando nuestro DNS de la Raspberry Pi. Lo haremos dos veces, ya que la primera vez le costará un tiempo similar, o algo mayor, ya que deberá ir a buscar la resolución del dominio a los forwarders que configuramos la primera vez, en mi caso a los DNS de OPenDNS. Para la segunda ejecución os debería salir algo así:

dig mascandobits.es  @127.0.0.1

; <<>> DiG 9.9.5-9+deb8u13-Raspbian <<>> mascandobits.es @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59435
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 14

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mascandobits.es.               IN      A

;; ANSWER SECTION:
mascandobits.es.        2575    IN      A       31.220.20.199

;; AUTHORITY SECTION:
es.                     146250  IN      NS      a.nic.es.
es.                     146250  IN      NS      ns-ext.nic.cl.
es.                     146250  IN      NS      ns1.cesca.es.
es.                     146250  IN      NS      f.nic.es.
es.                     146250  IN      NS      ns3.nic.fr.
es.                     146250  IN      NS      sns-pb.isc.org.
es.                     146250  IN      NS      g.nic.es.

;; ADDITIONAL SECTION:
a.nic.es.               146250  IN      A       194.69.254.1
a.nic.es.               146250  IN      AAAA    2001:67c:21cc:2000::64:41
f.nic.es.               146250  IN      A       130.206.1.7
f.nic.es.               146250  IN      AAAA    2001:720:418:caf1::7
g.nic.es.               146250  IN      A       204.61.217.1
g.nic.es.               146250  IN      AAAA    2001:500:14:7001:ad::1
ns1.cesca.es.           146250  IN      A       84.88.0.3
ns1.cesca.es.           146250  IN      AAAA    2001:40b0:1:1122:ce5c:a000:0:3
ns3.nic.fr.             146250  IN      A       192.134.0.49
ns3.nic.fr.             146250  IN      AAAA    2001:660:3006:1::1:1
ns-ext.nic.cl.          146250  IN      A       200.1.123.14
sns-pb.isc.org.         146250  IN      A       192.5.4.1
sns-pb.isc.org.         146250  IN      AAAA    2001:500:2e::1

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 26 19:11:40 CEST 2017
;; MSG SIZE  rcvd: 495

Hemos bajado a 1 msec, que es bastante mejor que el tiempo de las DNS de Google. Además esto nos demuestra que se consigue bastante velocidad, en mi caso 42 veces más rápido para un dominio cacheado previamente por el servidor DNS de la Raspberry Pi.

Ahora para que todos los dispositivos de tu red usen estas nuevas DNS, lo más fácil es configurarlo en el router. Yo tengo un router de TP-Link, pero la configuración suele ser similar en todos los routers. Lo que nos interesa suele estar en la sección “DCHP”:

En el DNS Server he añadido la IP de la Raspberry Pi donde está el servidor DNS, es recomendable para ello que asignes IP estática a la Raspberry Pi. Hoy en día lo puedes hacer fácil desde el propio router asociando una IP privada a la MAC de la Raspberry Pi. El Secondary DNS Server lo he dejado con 0.0.0.0 para que lo resuelva contra el modem-router de proveedor de servicio a Internet (ISP). Esto hace que si la Raspberry Pi deja de funcionar, la red puede seguir resolviendo los dominios contra las DNS que me proporciona el router de mi ISP. Hay que cubrirse siempre 😉 !.

Con esto ya estaría listo, pero para dejarlo todo bien atado vamos a volver a la consola SSH de la Raspberry Pi para comprobar si bind arrancará al inicio si la apagas y enciendes. Para ello vamos a introducir el siguiente comando:

service bind9 status
● bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled)
  Drop-In: /run/systemd/generator/bind9.service.d
           └─50-insserv.conf-$named.conf
   Active: active (running) since jue 2017-10-26 10:25:49 CEST; 5h 18min ago
     Docs: man:named(8)
 Main PID: 17478 (named)
   CGroup: /system.slice/bind9.service
           └─17478 /usr/sbin/named -f -u bind

Si en la línea de “Loaded” vemos al final “enabled”es que está activado como servicio al arranque. Si no fuera así bastaría con ejecutar el siguiente comando:

sudo systemctl enable bind9

Si quieres ver de manera general todos los servicios que tienes corriendo puedes ejecutar:

service --status-all

Podremos ver los servicios que existen y si están arrancados o no.

Con esto ya queda tu red perfectamente configurada para usar tu propio servidor DNS caché alojado en tu Rapsberry Pi para toda tu red local y mejorar los tiempos de respuesta de la resolución de dominios.

 

Precio – Coste – Valor – Gratuidad

Cada vez más frecuentemente me toca la típica charla del Software Libre y la importancia de la libertad que además tiene que ser a un coste 0, cosa que es imposible porque todo cuesta en la unidad que sea y quieras convertir. Yo estoy de acuerdo con la defensa de las libertades que protege el Software Libre pero no en su modelo de financiación altruista y mediante el formato de voluntariado. Esto hace insostenible el desarrollo del mismo al anteponer los intereses y libertades de colectivos de usuarios sobre los de los profesionales que desarrollan el Software Libre, que necesitan realizar una actividad de la que puedan vivir.

El problema no es la imposición de un modelo de financiación obligado que destruiría la esencia del Software Libre, sino la concienciación de que aquellos que están en condiciones de aportar lo hagan, ya sea con esfuerzo profesional o esfuerzo económico. Sólo difundir y usar no lo veo como un aporte porque es algo implícito sea el servicio o producto que sea, lo vas a hacer igual igual siempre y cuando sea de tu agrado el servicio o producto.

La cuestión de fondo no es la de ninguna libertad, sino la de intercambio de valor y cómo estos mecanismos permiten a un individuo desarrollarse individual y socialmente de manera digna.

Todos estamos de acuerdo más o menos en lo moralmente puro, de si algo es bueno o malo, si obviamos su contexto y las implicaciones particulares de cada uno. El problema viene de la interacción con otros individuos y ese intercambio de valor como comentaba. Para exponerlo comparto una reflexión hecha en una de mis abundantes disertaciones con todo aquel que quiera hacer un ejercicio de mayeútica.

 

Precio – Coste – Valor – Gratuidad

El hecho de que un individuo establezca el valor del trabajo de un tercero a nivel particular de manera unilateral, crea un sistema injusto de valor individual, ya que el uso de criterios de tasación de valor individuales usando elementos de transmisión de valor socialmente aceptados como es el dinero, crea un marco que conlleva un empoderamiento excesivo del consumidor.

Del mismo modo es injusto todo PVP (Precio de Venta al Público) por la misma argumentación llevada al caso opuesto. Es decir, que un tercero con estatus de regulador establezca el precio para categorías de productos. Un caso sencillo de entender es la entrada del cine. Aunque todas las entradas al cine cuestan igual, no todas las producciones tienen el mismo presupuesto y tampoco se ha depositado la misma cantidad de dinero para su realización, por el que en principio se tasa su valor inicial. Esto hace que por ejemplo producciones más modestas que llegan al cine puedan tener un retorno más rápido que otra que tiene un presupuesto más alto en su producción. Si has seguido este argumento, estarás de acuerdo que todas las películas que hay en el cine no debería valer su entrada lo mismo atendiendo al coste de producción, dejando al margen el valor percibido y pagado por el consumidor.

Aquí hay un dilema, en un sistema el individuo y sus circunstancias establecen el precio y en el otro lo establece un PVP que lo pone un tercer organismo que hace de regulador; normalmente el propio estado, dependiente del estado, o una entidad externa negociado con el estado. Ambos suponen extremos opuestos en su planteamiento y pecan de sus bondades y deficiencias en sus extremos a partes iguales. ¿Pero si el valor se estableciera por su uso, dado su carácter implícito como valor?

El sistema de oferta y demanda funciona bien. Una señal del valor de algo con independencia del mecanismo de transmisión del mismo, es la demanda. La demanda inflaciona el precio de un servicio o producto y su opuesto la oferta, lo deflaciona. Constituye un sistema de valor implícito con mecanismos de control completos. Me explico.

Si algo se inflaciona demasiado, tiene un valor para el consumidor y la sociedad haciendo que el precio suba. El estado con mecanismos de articulación, protección y mediación, puede generar deflación de un tipo de producto o servicio generando empleo y favoreciendo la creación de empresas para aumentar la oferta de ese bien o servicio, por la simple razón de que el aumento del mismo baja el precio. Curiosamente este mecanismo propulsado por el ánimo de lucro se autoregula solo y proporciona un valor. El concepto es similar a como los mineros en la criptodivisas, en su afán de minar y conseguir la recompensa, hace que se procesen las transacciones en esa actividad que hace que una criptomoneda funcione. Pero no lo hace directamente por la convicción de que el sistema es bueno, sino por lucro o enriquecimiento. Y además este lucro provoca que otros también quieran hacerlo y eviten monopolios dentro del sistema gracias a la obtención de ganancias, que vuelve a repercutir en la propia red que tiene más velocidad y estabilidad.

Obviamente el precio de salida de bienes y servicios tiene que cubrir costes tanto del producto como del servicio, al igual que la minería en las criptodivisas sólo se realiza si la actividad cubre los costes eléctricos. En este último ejemplo se puede notar como países más pobres con costes de la electricidad más bajos, son los que hacen la actividad de minería, o en los que se hace la minería (atención al matiz). Esto vuelve a ser causa de la falta de referencia real del valor de las divisas fiat, sujetas directamente a la falta de escasez e impulsadas únicamente por la confianza obligada del gobierno o entidad que emite la divisa.

Tras todo esto subyace la idea de la hipocresía de moverse a niveles internacionales usando marcos legales nacionales o comunitarios. Si el comercio y la economía es mundial tienen que ser mundiales, únicos y sostenibles, porque de lo contrario favorece posiciones de poder y de autoridad que aprovechan la singularidad de cada marco legislativo, que es lo que pasa ahora.

Para cerrar entro en el concepto gratis. Tras todo lo expuesto, evidentemente, con un sistema como el planteado de tasación de valor por sistema de mercado (oferta y demanda) basado en blockchain para gestionar la actividad y también como mecanismo de transmisión de valor (divisa), seguiría existiendo el concepto de gratuidad. Existirá por el mero hecho de que simplemente se quiera ejercer un gasto para generar un bien o servicio sin pedir la contraprestación de un ingreso por los mismos que lo compense o genere un beneficio. Pero lo que sí será evidente es quién asume el gasto, siendo un concepto de gratuidad sutilmente distinto al que tenemos ahora, por la simple razón de que existe un sistema de valor real para todo bien y servicio.

Además creo que se quitarían prácticas del tipo, como es gratis lo quiero y hasta lo uso. Pero si algo gratis lo quieres y además lo usas es porque implícitamente tiene valor y por tanto habría que igualar precio con valor. Sólo si el que da el servicio o bien te lo quiere dar gratis, asumiendo costes, lo hará, sino no. Un ejemplo claro es el filántropo Pavel Durov impulsor de Telegram, que es el que paga toda la factura de gastos del servicio para que sea gratis, y no existe una factura oculta que pagas de otra forma, como pueden ser los datos de uso o personales.

Conclusión: Todo debería tener un precio representativo de su valor y coste con independencia de que se pague la contraprestación o que se asuma por parte del individuo o entidad, no generando el debido retorno y siendo en consecuencia un gasto.

 

“Sólo un ignorante confunde precio con valor”

 

Problemas de acceso a una IP o dominio público desde una red LAN

En ocasiones más de uno se habrá encontrado con el problema de que tiene una dirección IP pública (fija o dinámica) o un dominio público (mediante DNS fijo o dinámico) que apunta al router que tenemos dispuesto, permitiendo acceder a un servicio de una máquina que corre en nuestra red de área local (LAN) desde fuera de ella, pero desde la red local es imposible acceder con dicha dirección o dominio. Si alguna vez te ha pasado esto, te explico las causas y las posible soluciones.

La causa de este comportamiento está sujeta habitualmente a medidas de seguridad que evitan las conexiones loopback como característica de seguridad. La dirección lookback es una dirección especial que los host utilizan para dirigir el tráfico hacia ellos mismos. Esta característica suele ser una extensión de la NAT llamada NAT loopback.

NAT loopback es una extensión de NAT que te permite acceder a tu dirección pública de Internet (WAN) desde dentro de tu propia red (LAN). Esto es práctico cuando tenemos algún servidor dentro de nuestra propia red, ya que nos permite acceder a ese servidor usando la misma IP pública (y por lo tanto también dominio) tanto desde dentro de la LAN, como desde el exterior.

Esta característica desgraciadamente no está presente en la mayoría de los routers que nos proporcionan nuestros proveedores de Internet. Con lo cual lo único que puedes hacer es comprobar si es posible activar esta característica en la zona de administración del router o contactando a tu proveedor de acceso a Internet para que te lo solucione.

La ausencia de esta característica provoca que por ejemplo si te haces con un NAS, dispositivos de almacenamiento en la red que últimamente están teniendo una gran aceptación, no se pueda acceder desde el dominio a tu NAS si estás en la misma red local que el NAS. Es decir, terminas usando la IP local de la LAN (ejemplo: 192.168.1.177) cuando estás en la misma red y el dominio (mi_nas.com) para acceder desde fuera de la red LAN. Dos formas de acceder que vuelven complicado configurar aplicaciones, como por ejemplo un cliente de sincronización del estilo Dropbox, debido a que no tienes una única forma de acceder al NAS, la cual debería ser el dominio.

Si el equipo con el que accedes al NAS, es de sobremesa aún puedes solucionarlo editando el archivo “hosts” del sistema, pero en caso contrario tendrás que o bien cambiar el router o funcionar con IP local y dominio dependiendo si estás dentro o fuera de la red local del NAS.

Paso a explicar como solucionar la resolución de dominio tanto para Windows como para GNU/Linux mediante la edición del archivo “hosts” de tu ordenador.

 

Windows


  1. Abrir un editor de texto en “modo administrador
  2. Abrir el fichero ubicado en la siguiente ruta C:\Windows\System32\Drivers\etc\hosts
  3. Añadir el host mediante la adición de una línea al final del fichero. Usando el ejemplo anterior del NAS sería:
    192.168.1.177 mi_nas.com
  4. Guardar y a partir de ahora mi_nas.com resolverá directamente como 192.168.1.177

 

GNU/Linux


  1. Abrir un terminar y poner el siguiente comando en el terminal
    sudo nano /etc/hosts
  2. Añadir el host mediante la adición de una línea al final del fichero. Usando el ejemplo anterior del NAS sería:
    192.168.1.177 mi_nas.com
  3. Guardar y a partir de ahora mi_nas.com resolverá directamente como 192.168.1.177

 

Espero que este artículo sirva para arrojar un poco de luz en toda esta problemática.

Frase Memorable 10


Eric Schmidt dijo, “Internet es el primer invento de la humanidad que la humanidad no entiende. El mayor experimento de anarquía que hemos tenido”.