1.1.1.1 Las nuevas DNS de las que todo el mundo habla.

DNS 1.1.1.1
DNS

Recientemente Cloudflare ha sacado sus propios servidores DNS los ya famosos 1.1.1.1, para ello ha usado una dirección IP fácil de recordar como ya hiciera en su día Google con su 8.8.8.8 o el 9.9.9.9 de Quad9/IBM.

¿Qué es un servidor DNS?

Cuando has accedido a esta web, has tecleado www.alferez.es mucho más cómodo y fácil de recordar que 104.27.148.187 que es realmente la dirección IP que está detrás del nombre de dominio.

Esta conversión es lo que hace el servidor DNS, traduce los nombres en direcciones IP para que le navegador sea capaz de encontrar la web.

¿Qué tiene este de nuevo 1.1.1.1?

Según ellos mismos publicitan en su web son modernos, rápidos y seguros, pero eso no es nuevo, es prácticamente lo mismo que publicitan el resto.

¿Y cual es mejor?

Pienso que no es correcto decir que un servidor DNS u otro es mejor, y para decir eso me baso en que un servidor DNS tiene que hacer el trabajo que hace, y si eso lo hace correctamente es bueno.

Luego podemos escoger según la red que usemos uno sea más o menos rápido que otros o más efectivos basándonos en la latencia que tengamos desde nuestra red o lo rápido que nos respondan a las preguntas.

 

Mi router ya tiene los de operadora, ¿los cambio?

SI.

Y la respuesta está basada en el histórico de las operadoras, histórico que van desde «secuestrar las peticiones» para llevarte a una u otra web, o para saber que visitas y tenerte «rastreado».

Por este motivo Sí es recomendable cambiar las DNS en tu router al igual que en tus dispositivos, incluso hay operadoras que no permiten cambiar las DNS en el router o que pongas las que pongas te siguen redireccionando a las suyas aunque no lo veas.

Entonces ¿Cloudflare? ¿Google? ¿Quad9?

Estas son las pruebas que yo he realizado y sobre las que me apoyo para elegir un servidor u otro:

Latencia

A que distancia estamos de esos servidores:

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=8.85 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=9.26 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=55 time=8.91 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=55 time=8.90 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=55 time=8.76 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 8.766/8.940/9.264/0.207 ms
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=8.93 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=53 time=8.56 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=53 time=8.92 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=53 time=8.88 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=53 time=8.60 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 8.565/8.783/8.938/0.184 ms
AñadirPING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=8.93 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=53 time=8.56 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=53 time=8.92 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=53 time=8.88 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=53 time=8.60 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 8.565/8.783/8.938/0.184 ms
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
64 bytes from 9.9.9.9: icmp_seq=1 ttl=54 time=38.7 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=54 time=38.8 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=54 time=39.3 ms
64 bytes from 9.9.9.9: icmp_seq=4 ttl=54 time=38.8 ms
64 bytes from 9.9.9.9: icmp_seq=5 ttl=54 time=38.9 ms

--- 9.9.9.9 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 38.788/38.968/39.381/0.248 ms

Esto depende no solo del estado de nuestra red, sino también del peering que tenga nuestro operador. Con esto ya podríamos descartar los de Quad9

Tiempo de respuesta

No sólo de distancia vivimos, no por estar más cerca vamos a obtener antes nuestro objetivo. No nos vale de nada tener un tiempo de 8 milisegundos y que tarde 3 segundos en darnos la IP que necesitamos.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.alferez.es @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38343
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1536
;; QUESTION SECTION:
;www.alferez.es.			IN	A

;; ANSWER SECTION:
www.alferez.es.		296	IN	A	104.27.148.187
www.alferez.es.		296	IN	A	104.27.149.187

;; Query time: 9 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Apr 02 13:34:08 CEST 2018
;; MSG SIZE  rcvd: 75
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.alferez.es @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15900
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
www.alferez.es.		299	IN	A	104.27.148.187
www.alferez.es.		299	IN	A	104.27.149.187

;; Query time: 36 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Apr 02 13:28:25 CEST 2018
;; MSG SIZE  rcvd: 75
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.alferez.es @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23425
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
www.alferez.es.		300	IN	A	104.27.149.187
www.alferez.es.		300	IN	A	104.27.148.187

;; Query time: 50 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Mon Apr 02 13:28:30 CEST 2018
;; MSG SIZE  rcvd: 75

Lo que nos interesa es el «Query time», que es el tiempo que ha tardado en resolver la pregunta, y parece que volvemos descartar.

Promesas

Esto es lo que no podemos medir, lo que no podemos ver, lo que nos tenemos que creer aunque desconfiemos de ello.

En este apartado por ejemplo los de Cloudflare con su 1.1.1.1 nos dice esto:

We will never log your IP address (the way other companies identify you). And we’re not just saying that. We’ve retained KPMG to audit our systems annually to ensure that we're doing what we say.

Frankly, we don’t want to know what you do on the Internet—it’s none of our business—and we’ve taken the technical steps to ensure we can’t.

Pero aquí también pueden entrar la picaresca de que pasado un tiempo cambien las políticas y pasen a venderlo, pero en ese caso harán lo que otros (o tu propia operadora) ya pueden estar haciendo, por lo que no va a cambiar mucho la cosa.

Conclusión personal.

Hay algo a tener en cuenta sobre la velocidad de respuesta y es el número de peticiones que tiene el mundialmente famoso 8.8.8.8 que lleva tiempo en la red y tiene muchos usuarios. El nuevo 1.1.1.1 es un servidor DNS que acaba de salir y que va cogiendo usuarios poco a poco, por lo que pienso que pasado un tiempo y repartido los usuarios. Los tiempos de uno bajarán y los del otro subirán, igualándose o por lo menos teniendo menos distancias entre uno y otro.

Yo  como siempre, por novedad, por probar, por ver que tal, usaré los nuevos 1.1.1.1, aunque en mi red uso distintos servidores (obligados) por usuarios, ya que en el caso de los dispositivos que obtienen ip por DHCP usan los de OpenDNS (por ejemplo la tablet de mi hija) para estar un poco más controlado, pero de esto hablaremos en otro post.