Todos los root servers DNS con soporte IPv6 - Un hito que pasó desapercibido

Introducción

En esta oportunidad quiero hablar sobre un detalle que considero pasó en el mundo de Internet desapercibido, tanto así que yo mismo ni me dí cuenta tarde.

Un poco de historia

Recientemente estuve revisando unas presentaciones de hace pocos años (aprox 2015) y noté que en las mismas mencionaban que solo 11 de los 13 root servers tenían direccionamiento IPv6. Por ello quise chequear y para mi sorpresa hoy -Mayo 2018- los 13 Root Servers cuentan con direccionamiento IPv6.

Los últimos nuevos glues IPv6 fueron modificados de la siguiente manera y en la siguiente fecha: 20 octubre 2016: g.root-servers.net . AAAA 2001:500:12::d0d 25 agosto 2016: e.root-servers.net . AAAA 2001:500:a8::e

Y fue anunciado el 2 de diciembre del 2016: http://root-servers.org/news/announcement-of-ipv6-addresses.txt

Actualmente los root servers tienen estas direcciones -Tomado de https://www.internic.net/domain/named.root -

A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4

A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30

B.ROOT-SERVERS.NET. 3600000 A 199.9.14.201

B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:200::b

C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12

C.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2::c

D.ROOT-SERVERS.NET. 3600000 A 199.7.91.13

D.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2d::d

E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10

E.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:a8::e

F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241

F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2f::f

G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4

G.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:12::d0d

H.ROOT-SERVERS.NET. 3600000 A 198.97.190.53

H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::53

I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17

I.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fe::53

J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30

J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:c27::2:30

K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129

K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fd::1

L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42

L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:9f::42

M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33

M.ROOT-SERVERS.NET. 3600000 AAAA 2001:dc3::35

¿Cómo algo tan importante pudo pasar desapercibido?

Desde nuestro punto de vista fue increíble que este hecho no tuviese más difusión, pero las cosas fueron así y no podemos hacer nada al respecto. Se nos ocurren algunas razones por qué hubo esa falta de difusión:

1. IPv6 ya se encuentra tan avanzado y estable que no pasó a ser noticia. Por ejemplo, en el 2008 cuando se colocó la primera dirección IPv6 si existió mucha noticia por muchas listas de correo y otros medios.
2. Algunas noticias pasan sin pena ni gloria sobretodo cuando no hay pena como en esta oportunidad (que viene a ser bueno !!)
   Una comparación que suena exagerada pero cala perfectamente en este contexto es cuando llegó el Apollo 11 a la luna en el año 1969, fue una gran noticia, en los posteriores proyectos Apollo ya la misma novedad no tenía mucho impacto.

¿Qué significa que ahora todos los Root Servers DNS cuenten con IPv6?

Para este renglón existen dos cosas que podemos mencionar que son muy significativas, 1) es un mensaje adicional a la comunidad que IPv6 es un protocolo estable y funcional 2) podemos esperar resoluciones más rápidas y con menores rata de falla.

Un punto adicional, es importante indicar que la ausencia de NAT en IPv6 dentro del mundo DNS tiene particular y mayor relevancia motivado a que los traductores no necesitan Natear las respuestas DNS.

Por último, esto también empuja a crear demanda por IPv6 en todo el mundo. No olvidemos que los root servers utilizan anycast desde hace muchos años, y cada uno de los más de 1.000 nodos tienen requerimiento de servicio IPv6 en las decenas de países y redes en que son hosteados.

El siguiente paso entonces es... ir apagando IPv4 en alguno de los root servers! ;)

Referencias

https://www.iana.org/reports/2008/root-aaaa-announcement.html

https://www.icann.org/news/announcement-2008-02-04-en

https://arstechnica.com/uncategorized/2008/01/icann-to-add-ipv6-addresses-for-root-dns-servers/

http://root-servers.org/

Por

Alejandro Acosta

@ITandNetworking @LACNICLabs

Colaborador: Hugo Salgado

Hugo Salgado

Solucion: "mtr: Failure to start mtr-packet: Invalid argument"

Hola,

  Al ejecutar mtr en MAC (en mi caso Sierra) obtienes:

mtr: Failure to start mtr-packet: Invalid argument

  El problema es que "mtr-packet" no está en tu PATH, debes ubicar donde se encuentra -generalmente en /usr/local/sbin-. Puedes buscarlo con:

#find / -name mtr-packet 

  Luego tienes que agregar el directorio que lo contiene al tu PATH. Para hacerlo:

Solución 1:

  En un terminal:
  PATH="$PATH:/usr/local/sbin"

Solución 2:

  Agregar una linea "/usr/local/sbin" /etc/paths, por ejemplo:

  echo "/usr/local/sbin" >> /etc/paths

  Espero te sirva,

IPv4 e IPv6 en una sola VPN utilizando OpenVPN

Introducción
  Recientemente conversando con un amigo (@TarantinDigital) me indicaba que le gustaría tener una VPN que soportara IPv4 e IPv6, que le parece una solución muy interesante para IoT.
  Igualmente entre otras cosas ofrece la comodidad de tener direccionamiento IPv6 persistente (siempre el mismo bloque IPv6)

Importante
  No voy a indicar los pasos para instalar o configurar OpenVPN.
  Asumo tienes un servidor OpenVPN corriendo y en el servidor tienes direccionamiento IPv4 e IPv6
  Nos enfocaremos en algunas entonaciones en el servidor y en el archivo server.conf
  Este excelente video (en Ingles) ofrece paso a paso como instalar y configurar OpenVPN: https://www.youtube.com/watch?v=XcsQdtsCS1U

Pasos para agregar IPv6 a un servidor OpenVPN que actualmente ofrece solo IPv4 

  1) Tu interfaz tun (o TAP) tiene que tener direccionamiento IPv6, OpenVPN tiene algunas restricciones en cuando a la longitud de prefijo (*máscara*) que puede utilizar en IPv6, para este ejemplo estaré utilizando un /64

  ifconfig tun0 add 2001:db8::1/64

  2) Es necesario (para nuestro ejemplo, si utilizas un /64 global de IPv4 o direccionamiento IPv4 público no sería necesario) realizar NAT44 y NAT66:

  NAT44

  iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to xx.xx.xx.xx

  NAT66

  ip6tables -t nat -A POSTROUTING -o eth0 -s 2001:db8::/32 -j MASQUERADE #noten que en eth0 hay un IPv6 global

  3) Hay que agregar algunas directivas de IPv6 en el archivo /etc/openvpn/server.conf. Las mismas son las siguientes:

  proto udp6 #hará que el server maneje sockets v4 y v6

  server-ipv6 2001:db8::1/64  #dirección IP colocada a la interfaz tun en el server openvpn

  tun-ipv6 #tipo de interfaz tunnel con IPv6 

  push tun-ipv6   #se le pide al cliente crear interfaces tun para el tunel (la VPN)

  ifconfig-ipv6 2001:db8::1 2001:db8::2

  push "route-ipv6 2000::/3" #inyecta esta ruta en el cliente

  4) Finalmente es necesario convertir el servidor VPN en un router IPv6. Para ellos editamos el archivo /etc/sysctl.conf y la linea net.ipv6.conf.all.forwarding=1 le quitamos el #

Del lado del cliente veras una interfaz similar a:

utun1: flags=8051 mtu 1500

inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff 

inet6 fe80::aebc:32ff:fe96:822b%utun1 prefixlen 64 scopeid 0xd 

inet6 2001:db8::1001 prefixlen 64 

Note que recibió una dirección IPv6 del mismo /64 de la interfaz tun del servidor.

Espero sea de tu utilidad


Referencias
  https://www.youtube.com/watch?v=XcsQdtsCS1U
  http://blog.acostasite.com/2014/07/nat66-en-linux.html

Solucion a errores: OpenVPN daemon() failed or unsupported: Resource temporarily unavailable (errno=11)

Introducción: 
    Tengo estos errores en syslog luego de intentar levantar openvpn:

May 7 12:59:47 server ovpn-server[764]: library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
May 7 12:59:47 server ovpn-server[764]: daemon() failed or unsupported: Resource temporarily unavailable (errno=11)
May 7 12:59:47 server ovpn-server[764]: Exiting due to fatal error

Solución: 
   En el archivo:

 /lib/systemd/system/openvpn@.service 

Ubicar la linea:
LimitNPROC=10 
y comentarla, quedaría así:

#LimitNPROC=10 



   Reiniciar el servidor y listo.

 Espero te ayude.

Identificando servidores DNS IPv6 Open Resolvers

Introducción

Como muchos de ustedes saben, tener servidores DNS Open Resolvers es muy negativo, tanto para el que deja el servicio abierto como para la seguridad en Internet en general.
Este tipo de servidores se utilizan como vector de ataques de DDoS por amplificación ya que a partir de un mensaje de consulta de pequeño tamaño, se puede obtener una respuesta mucho mayor. De esta manera, ese servidor DNS se convierte en un amplificador de tráfico muy potente ya que sus consultas amplificadas pueden dirigirse a una IP específica, la cual recibiría todo ese volumen de tráfico, ocasionándole indisponibilidad de sus servicios. Para este ataque ni siquiera es necesario que el hardware esté controlado por el atacante.

Este es un problema que en WARP nos preocupa porque hemos recibido mucho reportes de incidentes relacionados a esta vulnerabilidad. Por esta razón en conjunto con el área de I+D estamos llevando a cabo un proyecto con el objetivo de conocer el estado actual de la región, identificar los open resolvers y de forma proactiva alertar y recomendar una posible corrección de la configuración de este servicio.

Identificando un DNS Open Resolvers en IPv6 (DNS abiertos)

Identificar servidores Open Resolvers o servidores DNS abiertos en el mundo de IPv4 es muy sencillo, debido a la poca longitud del espacio de IPv4 (2**32).
En el mundo de IPv6 es imposible poder verificar cada una de las direcciones IP y ejecutar una prueba de Open Resolver. Dicha prueba puede durar miles de años.

¿Cómo se identifica un DNS Open Resolver?

Un servidor DNS recursivo solo debería responder consultas (queries) a todos los clientes que se encuentren dentro de su misma red y debería rechazar cualquier otra que provenga de fuera. Por ejemplo, los servidores DNS del ISP ACME solo deberían responder a consultas de sus propios clientes, a más nadie.
La identificación se hace realizando una consulta de un nombre de dominio a los servidores DNS. En caso que el servidor DNS responde con una respuesta válida, entonces es considerado Open Resolver. Si por el contrario, devuelve un rechazo (Query refused) o sencillamente hace timed out se encuentra bien configurado, por lo que no es un Open Resolver.

¿Cómo se consiguen los resolvers de IPv6?

LACNIC administra un servidor que puede ser llamado: Root Server Reverso, específicamente la letra “D”, es decir, d.ip6-servers.arpa. Gran cantidad de consultas a direcciones IP reversas de la región de LACNIC pasan a través de este servidor, en líneas generales este servidor SOLO recibe consultas de servidores DNS. Aquí es donde obtienen las direcciones IPv6 de los DNS que realizan consultas.

Procedimiento & Algoritmo

1. 1. En el servidor actualmente se realiza una captura de 2.5 millones de paquetes con el filtro del puerto 53 y destinados únicamente a la dirección IP de dicho equipo.
   2. De la captura anterior se ubican solo direcciones IPv6 origen (se eliminan paquetes mal formados, errores, etc). Se desprecia menos de 1% de los paquetes
   3. De las direcciones IPv6 obtenidas en el paso 2 se crea una lista de direcciones IPs unicast (es decir, se eliminan duplicados)
   4. Un script toma cada dirección IPv6 del listado del punto 3, y realiza una consulta a la dirección www.lacnic.net hacia esa dirección, verifica recursividad y el estado de la respuesta.
   5. En caso de ser un Open Resolver dicha dirección IP quedará registrada para su posterior análisis y notificación a la organización responsable de ese recurso.

Diagrama de bloques

Vista de los Resultados

Conclusiones Primarias

Para esta primera instancia, observamos aproximadamente unos 33,514 registros de consultas realizadas al Root Server Reverso “D” administrado por LACNIC.

Luego de analizar estos primeros datos obtenidos, observamos que la región más afectada por servidores open resolver sería la de APNIC con el 19.23% de los datos obtenidos para esa zona. Para la región de Ripe obtuvimos la mayor cantidad de información, curiosamente el porcentaje de servidores mal configurados es casi insignificante (0.93%).
En lo que respecta a nuestra región detectamos 39 open resolvers (4.56%) de los 817 registros recolectados, donde existen solo 3 casos que la dirección IP se repite más de una vez.

Estudios similares

https://labs.ripe.net/Members/luuk_hendriks/finding-open-dns-resolvers-on-ipv6

Referencias

Para leer sobre Open Resolvers se recomienda este link: https://www.certsi.es/blog/dns

Realizado por:

Dario Gomez & Alejandro Acosta

Solución al error en gns3: "-bash: telnet: command not found"

Intro:
  Al ejecutar GNS3 y quererme conectar por consola a los equipos recibo el error: "-bash: telnet: command not found".  Muy probablemente luego de querer de hacer upgrade a MAC OS Sierra.
 
Solución:
  Hay que instalar telnet, recomiendo los siguientes pasos:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

brew tap theeternalsw0rd/telnet

brew install telnet

Referencias:

https://www.reddit.com/r/osx/comments/6jtxgz/telnet_not_found/

Propuesta de una fuente confiable de enrutamiento para la región de LAC

Introducción

Recientemente fue publicado un artículo por Job Snijders llamado: “A New Source For Authoritative Routing Data”, su traducción viene a ser algo como: “Una nueva fuente de información de enrutamiento autoritativa”. (Snijders 2017)

El documento trata sobre un trabajo donde explica como varios expertos y en contribución con varias instituciones construyeron una manera de proveer a la comunidad información confiable sobre enrutamiento. Para ir entrando en detalles técnicos podemos verlo como algo entre un IRR (“Internet Routing Registry - Wikipedia” n.d.) y RPKI (“Resource Public Key Infrastructure - Wikipedia” n.d.)

En este documento se describe una propuesta de LACNIC a la comunidad, con el fin de proveer una fuente de información autoritativa confiable sobre enrutamiento que pueda utilizarse por parte de los operadores de Internet de la región.

Un poco de historia

En el post de Job Snijder se explica cómo se tomó como fuente de información confiable la base de datos de Whois de ARIN y especificamente un campo llamado Origin el cual especifica cual AS (Sistema Autónomo) es quien anunciará determinado prefijo.

Posteriormente lo que se hace con esa información es construir un archivo JSON (“JSON - Wikipedia, La Enciclopedia Libre” n.d.) el cual puede ser utilizado fácilmente por programadores y diferente software de forma muy similar a lo que hace un IRR actualmente.

¿Qué hicimos en Lacnic?

Luego de analizar el post anterior y nuestras opciones, concluimos que el campo OriginAS prácticamente no es utilizado en el WHOIS de LACNIC, por lo que no estaríamos en condiciones de extraer esa información a partir de esa fuente. Sin embargo, dado el gran porcentaje de ROAs creados en varios países de la región (“Statistics — RIPE Network Coordination Centre” n.d.), creemos conveniente utilizar RPKI como fuente de información.

¿Cómo se tomó la información de RPKI?

Para utilizar la informacion de RPKI de LACNIC trabajamos con el validador RPKI de RIPE (“Tools and Resources” n.d.), con la diferencia que removimos todos los TAL (Trust Anchor Locator) exceptuando el de LACNIC. De esta manera el validador unicamente estaría procesando los ROAs correspondientes a nuestra región. Finalmente lo que hicimos fue exportar los ROAs en formato JSON, una funcionalidad que ofrece el propio validador.

Proceso de la información de RPKI

Finalmente, utilizando un script en python3 y en base al JSON exportado del Validador de RIPE construimos un nuevo archivo de JSON, (“Tools and Resources” n.d., “Website” n.d.) con una similitud sintáctica de 95% al del proyecto previo (“Website” n.d.)(Job Snijders y compañía). En este sentido, la manera como se crea la fecha, las posiciones relativas en el archivo, los nombres de las llaves son identicos, de esta manera facilitamos la interoperatividad con scripts y software ya existente.

Adicionalmente, esta misma información se publica en format RPSL(“Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre” n.d.), un formato que es más habitual para los operadores. De esta forma, se puede elegir entre ambos formatos para procesar o utilizar la información autoritativa.

Avances actuales

En base a todo lo mencionado anteriormente actualmente:

• Se publica diariamente un dump de todos los ROAs en formato JSON
• Se publica en RPSL la información correspondiente al AS de Origen y el prefijo (tanto v4 como v6) Lo anterior viene acompañado de un un hash de comprobación bajo SHA384 URL http://stats.labs.lacnic.net/RPKI/RPKItoJSON/

Espacio para mejoras

Sabemos que existen muchas cosas para mejorar, por el momento debemos mencionar:

1. Publicar los archivos en un server con soporte de https

Conclusiones

Dentro de Lacnic este proyecto aun se encuentra en una etapa Alfa, a lo sumo Beta. Dependeremos 100% de los comentarios recibidos de la comunidad si deseamos llevar esta idea a un ambiente con carácter de producción. Por ello no dude en comunicarse con nosotros, somos muy buenos recibiendo quejas, comentarios y felicitaciones.

Consideraciones adicionales

En los ROAs es posible especificar una longitud máxima y mínima de prefijos a publicar, sin embargo esto no tendría una forma similar de replicarlo en el archivo de salida. Una posibilidad en IPv4 sería generar los prefijos intermedios con el mismo sistema autónomo de origen, pero en IPv6 esto no sería posible por la cantidad de direcciones involucradas. Otra posibilidad es no utilizar las longitudes mínima y máxima en los ROAs, ya que esa es la situación análoga a los IRRs. El formato JSON de salida es fácilmente convertible a RPSL, con lo cual se pueden utilizar las mismas herramientas que se utilizan para procesar la información de un IRR. Un punto a analizar es si resulta necesario poder contar con otros objetos que no están incluidos en esta base de datos auto-generada.

Por:

• Alejandro Acosta alejandro \at lacnic dot net
• Guillermo Cicileo guillermo \at lacnic dot net

https://twitter.com/lacniclabs

Referencias

1. “Internet Routing Registry - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Internet_Routing_Registry.
2. “JSON - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/JSON.
3. “Resource Public Key Infrastructure - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure.
4. “Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/Routing_Policy_Specification_Language.
5. Snijders, Job. 2017. “A New Source For Authoritative Routing Data: ARIN WHOIS.” Medium. Medium. December 19, 2017. https://medium.com/@jobsnijders/a-new-source-for-authoritative-routing-data-arin-whois-5ea6e1f774ed.
6. “Statistics — RIPE Network Coordination Centre.” n.d. Accessed January 19, 2018. https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html.
7. “Tools and Resources.” n.d. RIPE Network Coordination Centre. Accessed January 19, 2018. https://www.ripe.net/manage-ips-and-asns/resource-management/certification/tools-and-resources.
8. “Website.” n.d. Accessed January 19, 2018a. http://stats.labs.lacnic.net/RPKI/RPKItoJSON/.