VPSs y mas.

Mostrando entradas con la etiqueta dns. Mostrar todas las entradas
Mostrando entradas con la etiqueta dns. Mostrar todas las entradas

lunes, 21 de mayo de 2018

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

Por

Alejandro Acosta
Colaborador: Hugo Salgado

miércoles, 11 de abril de 2018

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. 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

Referencias

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

Realizado por:

Dario Gomez & Alejandro Acosta


jueves, 24 de agosto de 2017

Google DNS --- Averiguando cual Cluster estas utilizando

(this is -almost- a copy / paste of an email sent by Erik Sundberg to nanog mailing list on August 23). 
This post is being posted with his explicit permission.


I sent this out on the outage list, with a lots of good feedback sent to me. So I 
figured it would be useful to share the information on nanog as well.

A couple months ago had to troubleshoot a google DNS issue with Google’s NOC. Below 
is some helpful information on how to determine which DNS Cluster you are going to.

Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 and 8.8.4.4. 
Anycast routes your DNS queries to the closes DNS cluster based on the best route / 
lowest metric to 8.8.8.8/8.8.4.4.   Google has deployed multiple DNS clusters across 
the world and each DNS Cluster has multiple servers.

So a DNS query in Chicago will go to a different DNS clusters than queries from a 
device in Atlanta or New York.


How to get a list of google DNS Cluster’s.
dig -t TXT +short locations.publicdns.goog. @8.8.8.8

How to print this list in a table format. 
Script from: https://developers.google.com/speed/public-dns/faq
---------------
#!/bin/bash
IFS="\"$IFS"
for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8)
do
  case $LOC in
    '') : ;;
    *.*|*:*) printf '%s ' ${LOC} ;;
    *) printf '%s\n' ${LOC} ;;
  esac
done
---------------

Which will give you a list like below. This is all of the IP network’s that google
uses for their DNS Clusters and their associated locations.

74.125.18.0/26 iad
74.125.18.64/26 iad
74.125.18.128/26 syd
74.125.18.192/26 lhr
74.125.19.0/24 mrn
74.125.41.0/24 tpe
74.125.42.0/24 atl
74.125.44.0/24 mrn
74.125.45.0/24 tul
74.125.46.0/24 lpp
74.125.47.0/24 bru
74.125.72.0/24 cbf
74.125.73.0/24 bru
74.125.74.0/24 lpp
74.125.75.0/24 chs
74.125.76.0/24 cbf
74.125.77.0/24 chs
74.125.79.0/24 lpp
74.125.80.0/24 dls
74.125.81.0/24 dub
74.125.92.0/24 mrn
74.125.93.0/24 cbf
74.125.112.0/24 lpp
74.125.113.0/24 cbf
74.125.115.0/24 tul
74.125.176.0/24 mrn
74.125.177.0/24 atl
74.125.179.0/24 cbf
74.125.181.0/24 bru
74.125.182.0/24 cbf
74.125.183.0/24 cbf
74.125.184.0/24 chs
74.125.186.0/24 dls
74.125.187.0/24 dls
74.125.190.0/24 sin
74.125.191.0/24 tul
172.217.32.0/26 lhr
172.217.32.64/26 lhr
172.217.32.128/26 sin
172.217.33.0/26 syd
172.217.33.64/26 syd
172.217.33.128/26 fra
172.217.33.192/26 fra
172.217.34.0/26 fra
172.217.34.64/26 bom
172.217.34.192/26 bom
172.217.35.0/24 gru
172.217.36.0/24 atl
172.217.37.0/24 gru
173.194.90.0/24 cbf
173.194.91.0/24 scl
173.194.93.0/24 tpe
173.194.94.0/24 cbf
173.194.95.0/24 tul
173.194.97.0/24 chs
173.194.98.0/24 lpp
173.194.99.0/24 tul
173.194.100.0/24 mrn
173.194.101.0/24 tul
173.194.102.0/24 atl
173.194.103.0/24 cbf
173.194.168.0/26 nrt
173.194.168.64/26 nrt
173.194.168.128/26 nrt
173.194.168.192/26 iad
173.194.169.0/24 grq
173.194.170.0/24 grq
173.194.171.0/24 tpe
2404:6800:4000::/48 bom
2404:6800:4003::/48 sin
2404:6800:4006::/48 syd
2404:6800:4008::/48 tpe
2404:6800:400b::/48 nrt
2607:f8b0:4001::/48 cbf
2607:f8b0:4002::/48 atl
2607:f8b0:4003::/48 tul
2607:f8b0:4004::/48 iad
2607:f8b0:400c::/48 chs
2607:f8b0:400d::/48 mrn
2607:f8b0:400e::/48 dls
2800:3f0:4001::/48 gru
2800:3f0:4003::/48 scl
2a00:1450:4001::/48 fra
2a00:1450:4009::/48 lhr
2a00:1450:400b::/48 dub
2a00:1450:400c::/48 bru
2a00:1450:4010::/48 lpp
2a00:1450:4013::/48 grq

There are
IPv4 Networks: 68
IPv6 Networks: 20
DNS Cluster’s Identified by POP Code’s: 20

DNS Clusters identified by POP Code to City, State, or Country. Not all of these are 
Google’s Core Datacenters, some of them are Edge Points of Presences (POPs). 
https://peering.google.com/#/infrastructure and 
https://www.google.com/about/datacenters/inside/locations/

Most of these are airport codes, it did my best to get the location correct.
iad          Washington, DC
syd         Sydney, Australia
lhr          London, UK
mrn        Lenoir, NC
tpe         Taiwan
atl          Altanta, GA
tul          Tulsa, OK
lpp          Findland
bru         Brussels, Belgium
cbf         Council Bluffs, IA
chs         Charleston, SC
dls          The Dalles, Oregon
dub        Dublin, Ireland
sin          Singapore
fra          Frankfort, Germany
bom       Mumbai, India
gru         Sao Paulo, Brazil
scl          Santiago, Chile
nrt          Tokyo, Japan
grq         Groningen, Netherlans



Which Google DNS Server Cluster am I using. I am testing this from Chicago, IL

# dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8
"173.194.94.135"                     <<<<<dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8
"74.125.42.138" "173.194.102.132" "74.125.177.5" "74.125.177.74" "74.125.177.71" "74.125.177.4" Which all are Google DNS Networks in Atlanta. 74.125.42.0/24 atl 74.125.177.0/24 atl 172.217.36.0/24 atl 173.194.102.0/24 atl 2607:f8b0:4002::/48 atl

 Just thought it would be helpful when troubleshooting google DNS issues.



(one more time: this is -almost- a copy / paste of an email sent by Erik Sundberg to nanog mailing list on August 23). This post is being posted with his explicit permission.

lunes, 30 de enero de 2017

3 recomendaciones al construir el registro SOA en DNS

Hola, 
  En el presente artículo solo quiero mencionar 3 consejos que al parecer son difíciles de conseguir en Internet pero que son importantes..., hay MUCHOS otros consejos que se pueden dar, repito, voy a mencionar los que quizás no son tan conocidos y a su vez pueden traer problemas operacionales.

Recordando el fomato del registro SOA:
  Un pequeño ejemplo de un registro SOA sería (tomado de una instalación de Bind):
@ IN SOA localhost. root.localhost. (
     1 ; Serial
604800 ; Refresh
 86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
   De manera muy breve y explicándolo de manera muy entendible: 
El serial: se debe incrementar con cada modificación de la zona. Recordemos que este valor será revisado por los servidores DNS secundarios para identificar si existe algún cambio en la zona
Refresh: Cada cuando tiempo el servidor DNS secundario debe ir al servidor primario y revisar si hubo cambios (¿el valor de Serial es mayor? 
Retry: En caso de que el servidor secundario intentó comunicarse al primario y NO pudo (por la razón que fuese), cada cuanto lo vuelvo a intentar
Expire: Supongamos que el servidor secundario tiene N cantidad de tiempo "N=Expire" sin haber contactado al primario debería dejar de responder. Esto sale del principio que hace mucho que el secundario no contacta al servidor primario y la información que tenga ya puede haber cambiado, el servidor DNS secundario prefiere no dar respuesta que dar información errónea y/o desactualizada. Es decir, el servidor DEJA DE RESPONDER A LA ZONA
Negative Cache TTL: Hace referencia a cachear respuestas DNS negativas...., por ejemplo NXDOMAIN
Revisando lo anterior, nótese que los valores son casi exclusivamente utilizados por los servidores DNS Secundarios que desean hacer zone-transfer.

Consejo 1:
  El Serial nunca debería ser 0. El RFC 2136 indica en la sección 7: "Design, Implementation, Operation, and Protocol Notes". 
  7.11. A zone's SOA SERIAL should never be set to zero (0) due to
   interoperability" ...............

Consejo 2: 
  El valor de Retry no debería ser mayor a Refresh. La razón es bastante lógica, es casi como no tener valor de Retry.., primero ocurre el refresh. Adicionalmente Retry significa contactar el servidor primario para hacer el zone transfer SI NO se pudo contactar antes, con el Retry se buscar mantener la zona actualizada. RFC 1912 indica: ...... "Retry: If a secondary was unable to contact the primary at the
          last refresh, wait the retry value before trying again.  This
          value isn't as important as others, unless the secondary is on
          a distant network from the primary or the primary is more
          prone to outages.  It's typically some fraction of the refresh
          interval."

Consejo 3:
   El Expire no debe ser menor al Refresh. Similar al consejo 2 pero incluso este lo considero más importante. Si yo tengo un Expire menor que el Refresh significa que el servidor secundario va a dejar de responder la zona antes de que un intento de actualización (Refresh). Obviamente esto no es lo que se quiere. En el RFC 1912 se lee: "Expire: How long a secondary will still treat its copy of the zone
          data as valid if it can't contact the primary.  This value
          should be greater than how long a major outage would typically
          last, and must be greater than the minimum and retry
          intervals"

Referencias:
- Libro: Cookbook for IPv6 Renumbering in SOHO and
Backbone Networks "https://hal.inria.fr/inria-00000888/file/D3.6.1.pdf"  página 50 indica:  "retry should be smaller than refresh"
- Guia: "Check Point™ Meta IP User’s Guide" pagina 114 indica: "Slave Refresh must be lower than Slave Data Expire and Zone Default TTL"
- Sobre el serial no debería ser 0:  https://mxtoolbox.com/problem/dns/dns-soa-serial-number-format y https://www.digitalocean.com/community/questions/soa-serial-number-format-is-invalid  (sin embargo algunos software de DNS lo aceptan)

martes, 28 de julio de 2015

Contenido www y embriones sobre IPv6. Region Lacnic

Buenas tardes,
  En esta oportunidad les quiero compartir un pequeño análisis sobre estadísticas de penetración de IPv6 en el mundo de contenido. En otras oportunidades (*1) hemos conversado
sobre estadísticas de penetración de IPv6 desde la perspectiva del usuario final. En lo personal me alegra mucho contar con este tipo de mediciones porque es algo que nos faltaba.
¿Qué quiere decir estadísticas de penetración de IPv6 en el mundo de contenido?Básicamente es saber cuánto contenido/servidores existe sobre IPv6, NO cuántos usuarios NI cuánto tráfico sobre IPv6 está siendo cursado. 
ProblemasEl mayor problema que se encuentra es determinar con certeza cuál contenido se encuentra en un país. Recordemos que Internet es una red globalizada, saber que donde se encuentra el "host" de un dominio es algo muy complejo. Ciertamente existen muchas técnicas pero de igual manera no son 100% confiables. Ejemplo: indicar que el dominio www.example.com.ve está en Venezuela puede ser totalmente cierto, parcialmente cierto o totalmente negativo. Para poder llevar a cabo este estudio decidimos tomar únicamente dominios con ccTLD de nuestra región.
¿Cómo se realizó este estudio?Vamos a indicarlos por pasos para visualizarlo mejor:
1) Se toma un archivo con los TOP 1 millón de dominios del mundo (*2)
2) Se toma el ccTLD de los mismos (.ar, .uy, .br, .ve, etc)
3) Del punto 2 se averigua si tienen registros AAAA en su www
4) Del punto 2 se hace un estudio para averiguar si existen "embriones
IPv6", es decir, dominios que no tienen IPv6 en su www pero si tienen host con los nombres w6, www6, ipv6, v6 + dominio
Procesamiento:
- Del archivo Majestic Million con un millón de dominios, aproximadamente 8000 tienen ccTLD de la región de Latinoamérica y Caribe.
- Posteriormente se utiliza el dominio y se buscan registros AAAA para:
www + dominio
ipv6|v6|www.ipv6|www6|ip6|w6 + dominio
Resultados:De puede apreciar lo siguiente:
1.- Para Websites con IPv6 actuales:El top 5 de los países con Websites con AAAA tenemos:


Gráfico #1. Resumen países con sitios con registros AAAA

1.- Brasil cuenta con 180 sitios que representa el 57.3% del total
2.- Colombia con 47 sitios que representa el 15% del total
3.- México con 33 sitios que representa el 10.5% del total
4.- Argentina con 10 sitios que representa el 3.2% del total
5.- Chile con 7 sitios que representa el 2.2 del total

(estadísticas para el 22 de Julio, 7709 dominios estudiados y 314 Websites con AAAA)


Gráfico #2. Resumen sitios actuales con AAAA
2.- Para Websites embriones:El top 5 de los países con Websites embriones tenemos:

Gráfico #3. Resumen países con embriones IPv6


1.- Brasil 25 (con 45.5 %)
2.- Colombia 18 (32.7%)
3.- Mexico (9.1%)
4.- Perú 2 (3.6 %)
5.- Chile 2 (3.6 %)

(estadísticas para el 22 de Julio, 7709 dominios estudiados y 55 Websites embrios encontrados)

Gráfico #4. Resumen sitios embriones IPv6


Es muy interesante apreciar que Brasil, Colombia, México y Chile se encuentran en ambos cuadros mientras que Perú y Argentina se intercambian la 4ta posición.
Los resultados pueden ser obtenidos en el sitio: http://stats.labs.lacnic.net y buscando por “Websites actuales con IPv6” y “Embriones Websites (AAAA)” en la columna de la izquierda.


Conclusión:  Primero, que nada, es una alegría observar que existen más sitios con IPv6 que embriones por nacer ( claro, de alguna manera se entiende que lo anterior tiene sentido y en realidad no quise caer en comparaciones de otras índoles).
  Segundo, se entiende que puede existir un aspecto también de idiosincrasia donde algunos países y administradores sean más cuidadosos -o menos- y no usen un URL de embriones y coloquen su sitio en v6 directamente.
  Tercero, de alguna manera podemos esperar que en un futuro consigamos que los sitios embrionarios se conviertan en sitios formales (www) con IPv6.
¿Posibles próximos pasos?- En el presente estudio se evaluó únicamente dominios listados en el TOP 1 millón de Majestic
filtrados por ccTLD de la nuestra región Latam y Caribe, se puede evaluar la manera de extender este estudio a otros listados
- Identificar si la dirección IPv6 que apunta el AAAA es de Lacnic
- Estudiar cuánto tiempo pasa un sitio embrión a un sitio formal con IPv6.

Margen de error:- Se entiende que puede existir un margen de error, un host embrión no significa que sea
necesariamente movido al www del dominio.
Tecnisismos:- Todos los scripts fueron realizados en python3 sobre Linux Ubuntu 13.04

Por:
Alejandro Acosta
Lacnic
@ITandNetworking
*1. Retrospectiva: Acceso IPv6 en la region Latinoamerica y Caribe (LAC) en: http://portalipv6.lacnic.net/retrospectiva-acceso-ipv6-en-la-region-latinoamerica-y-caribe-lac/
*2. https://majestic.com/reports/majestic-million

lunes, 27 de abril de 2015

Construyendo una topología de red 464XLAT (mecanismo de transicion)

Introducción:
  El siguiente post indica el procedimiento que puedes seguir para tener una topología de red con 464XLAT


Topología:



Que se necesita:
Del lado del cliente:
- Un cliente CLAT, en nuestro ejemplo utilizamos: https://github.com/toreanderson/clatd
- Tayga como NAT64 (http://www.litech.org/tayga/)  En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)


y del lado del servidor:
- Tayga como NAT64 (http://www.litech.org/tayga/)  En este post puedes conseguir el procedimiento de instalación (más abajo dejo todos los archivos de configuración)
- Para nuestro ejemplo un DNS Server pero si tienes otro puedes obviarlo. Es recomendable utilizar DNS64 para facilitar el reconocimiento de red cuando se ejecute el clatd.
- radvd (para hacer los anuncios RA y que el cliente se auto-configure), una vez puedes obviarlo y hacer tus configuraciones manuales


Configuraciones:
Del lado del cliente:
En lineas generales no es necesario configuar nada. El tayga utiliza un archivo de ejemplo construido en el momento y el clatd verifica todo lo necesario. Por favor asegura que el archivo /etc/resolv.conf contenga la línea;

nameserver 2001:13c7:100:f101::1


IMPORTANTE: Del lado del cliente lo unico que hay que hacer es ejecutar el cliente clatd. El procedimiento es el siguiente:
#unzip clatd-master
#cd clatd-master
#./clatd  

Con este último comando el clatd será capaz de reconocer que NO hay direcciones IPv4 en el equipo donde se ejecuta y reconocer como es su conectividad hacia el exterior.

Del lado del servidor (6 pasos):
1) El radvd se configura en el archivo /etc/radvd.conf y debe quedar así:

interface eth0 { 
        AdvSendAdvert on;
        MinRtrAdvInterval 3; 
        MaxRtrAdvInterval 10;
        prefix 2001:13c7:0100:f101::/64 { 
                AdvOnLink on; 
                AdvAutonomous on; 
                AdvRouterAddr on; 
        };
};


2) Tayga: Del lado del servidor si es muy importante realizar una configuración de tayga. Para nuestro ejemplo:

En /usr/local/etc/tayga.conf:
tun-device nat64
ipv4-addr 192.168.64.1
prefix 64:ff9b::/96
dynamic-pool 192.168.64.0/24
data-dir /var/log/tayga
ipv6-addr 2001:13c7:100:f101::1


3) Las interfaces del lado del servidor deben quedar así:
/usr/local/sbin/tayga --mktun
/sbin/ip link set nat64 up
/sbin/ip addr add 10.0.3.15 dev nat64
/sbin/ip addr add 64:ff9b::1 dev nat64
/sbin/ip route add 192.168.64.0/24 dev nat64
/sbin/ip route add 64:ff9b::/96 dev nat64

4) Levantar tayga:
/usr/local/sbin/tayga -d &


5) Hacer NAT de la red IPv4:
/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE


6) El DNS Server debe quedar con la siguiente directiva dentro de /etc/bind/named.conf.options:

        dns64 64:ff9b::/96 {
          clients {
           any; };
        };  // End of DNS64 Section


Un poco mas de como quedas las interfaces. La salida de ifconfig del lado del servidor:

eth10      Link encap:Ethernet  HWaddr 00:0c:29:06:e9:cc
          inet addr:10.0.3.15  Bcast:10.0.3.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe06:e9cc/64 Scope:Link
          inet6 addr: 2001:13c7:7001:500::21/64 Scope:Global   ---> HACIA WAN
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:42282238 errors:0 dropped:307 overruns:0 frame:0
          TX packets:11377224 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5706072894 (5.7 GB)  TX bytes:2226397897 (2.2 GB)

eth9      Link encap:Ethernet  HWaddr 00:0c:29:06:e9:d6
          inet addr:10.64.0.1  Bcast:10.64.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe06:e9d6/64 Scope:Link
          inet6 addr: 2001:13c7:100:f101::1/64 Scope:Global  --- HACIA LAN
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:652093 errors:0 dropped:72 overruns:0 frame:0
          TX packets:2662969 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:84197892 (84.1 MB)  TX bytes:1461857730 (1.4 GB)

nat64     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.0.3.15 P-t-P:10.0.3.15  Mask:255.255.255.255
          inet6 addr: 64:ff9b::1/128 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1135938 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1074859 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:939693414 (939.6 MB)  TX bytes:931853538 (931.8 MB)




Explicando todo lo anterior:

1) Supongamos que el cliente quiere acceder una direcciones IPv6.., no pasa nada extraño  :-). El routing es 100% IPv6, no hay NAT, todo normal.

2) En el supuesto que el cliente quiera acceder a una dirección IPv4:

a) El cliente clatd otorgará un socket IPv4 a la aplicación
b) El paquete que construya el cliente será 100% IPv6. Será su dirección IPv6 origen y el destino será 64:ff9b::/96 + 32 bits de la dirección IPv4 destino. Recordemos que no hay IPv4 en el core de la red.
c) El PLAT (Tayga del lado del servidor)  al recibir un paquete con destino 64:ff9b::/96 lo enruta por la interfaz TUN NAT64 (interfaz lógica) donde tayga remueve los primeros 96 bits del destino dejando unicamente los 32 bits menos significativos (la dirección IPv4). Al origen (IPv6) se le hace una mapeo stateless con una direccion IPv4 (del pool en el archivo de configuración (192.168.64.0/24).
d) Cuando el paquete con el origen 192.168.64.0/24 del servidor desee salir del equipo será nateado con iptables al IPv4 que tenga eth10 (/sbin/iptables -t nat -A POSTROUTING -s 192.168.64.0/24 -o eth10 -j MASQUERADE)




Anexo:
a) ping a un destino IPv4 desde el cliente:




b) Clatd ejecutándose:



c) Captura en Wireshark de un ping desde el cliente (IPv6 only) a un destino IPv4:









lunes, 17 de noviembre de 2014

$GENERATE usando registros A en BIND. Match forward y rDNS

Hola,
  Este post es muy corto pero quizas muy util. Hay menos documentacion en Internet que la esperada.

Objetivo:
  a) Configurar los DNS reversos y los DNS forward de una red /24 en BIND9 utilizando $GENERATE.
 b) Que coincida la resolucion forward a la resolucion reversa

Requisitos:
  - Una red /24 (claro, el ejemplo se puede ajustar a otras redes)
  - BIND9
  - Usaremos registros A y PTR

Ejemplo:
  La red 192.168.30.0/24
  Dominio:  ejemplo.com

  Vamos a hacer que los reversos de 192.168.30.X resuelvan a: X.cliente.ejemplo.com
  De igual manera, X.cliente.ejemplo.com resolvera a 192.168.30.X

  Seria asi:
  192.168.30.1 ---> 1.cliente.ejemplo.com
  192.168.30.2 ---> 2.cliente.ejemplo.com
  192.168.30.3 ---> 3.cliente.ejemplo.com
  1.cliente.ejemplo.com ---> 192.168.30.1
  2.cliente.ejemplo.com ---> 192.168.30.2
  3.cliente.ejemplo.com ---> 192.168.30.3
  (etc)

Pasos:
   Creamos la zona reversa en /etc/bind/named.conf.

a) La zona reversa:

zone "30.168.192.in-addr.arpa" {
     type master;
     file "30.168.192.in-addr.arpa.db";
     allow-query { any; };
};


Luego en el archivo 30.168.192.in-addr.arpa.db  colocamos lo siguiente:

$TTL    86400 ; 24 hours, could have been written as 24h or 1d
@  1D  IN        SOA localhost.     hostmaster.ejemplo.com. (
                              2002022401 ; serial
                              3H ; refresh
                              15 ; retry
                              1w ; expire
                              3h ; minimum
                             )
; Name servers for the zone - both out-of-zone - no A RRs required
                        NS      localhost.

$GENERATE 1-255 $ PTR $.cliente.ejemplo.com.


b) La zona forward, utilizando registros A es:

$TTL    86400 ; 24 hours, could have been written as 24h or 1d
@  1D  IN        SOA localhost.     hostmaster.ejemplo.com. (
                              2002022401 ; serial
                              3H ; refresh
                              15 ; retry
                              1w ; expire
                              3h ; minimum
                             )
; Name servers for the zone - both out-of-zone - no A RRs required
                        NS      localhost.

$GENERATE 1-255.cliente.ejemplo.com $ A 192.168.30.$



Pruebas:
Para probar:
#dig -x 192.168.30.3  (reverso dns)
#dig 3.cliente.ejemplo.com  (forward dns)


Espero haya sido de tu utilidad
 

miércoles, 2 de enero de 2013

DNS64 y NAT64 paso a paso con explicación

Introducción:
DNS64 y NAT64 son dos tecnología diferentes que comunmente trabajan en conjunto.

DNS64 y NAT64 es ideal para colocar en el borde una red donde unicamente existan host con IPv6, algo cada día es más común sobre todo en el mundo de redes celulares y se gran cantidad de sensores.

En Internet hay mucha información sobre como configurar NAT64 y DNS64, la mayoría dice que muy fácil, otros lo colocan más complicado. En lo personal no conseguí ninguna que explicara paso a paso como hacerlo y adicionalmente que explicara la topología de red donde se estaba configurando.

En este post comienzo instalando DNS64 y luego procedemos con NAT64. Se puede instalar en cualquier orden.

Que se necesita antes de comenzar:

- Una subred IPv6 libre (una /96 esta bien) para realizar el mapeo DNS entre IPv4 e IPv6. Esta misma subred la utilizaremos dentro de Tayga para el NAT64

- Logicamente conectividad IPv6 entre los clientes y el servidor DNS64 y NAT64 (no se requiere IPv4)



Topología:
a) Servidor realizando. Solo tiene una interfaz (eth1)

IPv6: 2001:db8:1:1::/64 (eth1).
IPv4: 192.168.124.107

b) IP de un cliente (eth2):

2001:db8:1:1::2/64


c) Subredes IPv6:

Red que "retorna" el DNS64 2001:db8:1:ffff::/96
Pool de NAT en el NAT64: 2001:db8:1:ffff::/96

(si, son el mismo bloque)


d) Interfaz dns64:

192.168.124.107/32
2001:db8:1::1/128


(correcto!, la IPv6 e IPv4 de eth1 se solapan con interfaz dns64)



Procedimiento de DNS64.

Paso 1:

Instalar BIND9:

#aptitude install bind9


Paso 2:

Configurar /etc/bind/named.conf.options:

a) Asegurar que BIND escuche en IPv6 (recordemos que los clientes van a estar en IPv6)

listen-on-v6 { any; };

b) Permitir consultas desde cualquier IP. Si estas utilizando un servidor público o en producción favor restringir las consultas a tus clientes

allow-query { any; };

c) Realizar el DNS64 con la siguiente directiva.

dns64 2001:db8:1:ffff::/96 { 
    clients { 
      any; };
 };

La configuración del punto "c" lo que indica es que aquellas consultas DNS de aquellos registros que SOLO tienen tienen registro A (no tienen registro AAAA) serán entregadas a los clientes añadiendo 2001:db8::1:ffff::/96


d) Reiniciar bind9

#/etc.init.d/bind9 restart


Probar DNS64:

a) En un PC cliente colocar como servidor DNS: 2001:db8:1:1::1


b) Ubicarse en un cliente y realizar consultar DNS de hosts solo con direcciones IPv4 (registros A). Por ejemplo:


root@ubuntu-VirtualBox:~# dig ipv4.google.com aaaa @2001:db8:1:1::1

; <<>> DiG 9.8.0-P4 <<>> ipv4.google.com aaaa @2001:db8:1:1::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 64252="64252" br="br" id:="id:" noerror="noerror" opcode:="opcode:" query="query" status:="status:">;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;ipv4.google.com.               IN      AAAA

;; ANSWER SECTION:
ipv4.google.com.        0       IN      CNAME   ipv4.l.google.com.
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8268
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8269
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:826a
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8293
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8263
ipv4.l.google.com.      300     IN      AAAA    2001:db8:1:ffff::4a7d:8267

;; AUTHORITY SECTION:
google.com.             171975  IN      NS      ns1.google.com.
google.com.             171975  IN      NS      ns4.google.com.
google.com.             171975  IN      NS      ns2.google.com.
google.com.             171975  IN      NS      ns3.google.com.

;; Query time: 219 msec
;; SERVER: 2001:db8:1:1::1#53(2001:db8:1:1::1)
;; WHEN: Wed Jan  2 16:11:57 2013
;; MSG SIZE  rcvd: 294




Nota: La parte a destacar en esta salida son las direcciones IPv6 que comienzan por: 2001:db8:1:ffff..., ya en este momento sabemos que DNS64 esta funcionando.



Ahora NAT64

1) Utilizamos Tayga. El sitio oficial y link para descargarlo se encuentra en: http://www.litech.org/tayga/


2) Lo descomprimimos y desempaquetamos:

#tar -jxvf tayga-0.9.2.tar.bz2
#cd tayga-0.9.2
#./configure
#make
#make install


3) Creamos el directorio donde Tayga guardará los logs:

#mkdir /var/log/tayga

4) Editamos el archivo /usr/local/etc/tayga.conf

y copiamos y pegamos:

tun-device nat64
ipv4-addr 192.168.255.1
prefix 2001:db8:1:ffff::/96
dynamic-pool 192.168.255.0/24
data-dir /var/log/tayga



Tayga es stateless y realiza un nat 1:1 entre IPv6 e IPv4. En la configuración anterior a cada cliente IPv6 se le asignará un IP del pool 192.168.255.0/24; por ello si tenemos más de 255 hosts será necesario utililzar un pool más grande que /24. En caso de que tengas IPv4 públicas suficientes puede ser útil para evitar un doble NAT IPv4.

La directiva prefix indica el prefijo que utilizará Tayga para reconocer los 32 bits de IPv4, es decir, cuando el destino IPv6 sea: 2001:db8:1:ffff::/96, Tayga tomará los ultimos 32 bits para reconocer que ese es el destino IPv4

5) Habilitar routing IPv6 e IPv4 en el servidor.

#echo "1" > /proc/sys/net/ipv6/conf/all/forwarding
#echo "1" > /proc/sys/net/ipv4/ip_forward


6) Creación y configuración de la interfaz nat64:

#tayga --mktun
#ip link set nat64 up
#ip addr add 192.168.124.107 dev nat64
#ip addr add 2001:db8:1::1 dev nat64


(estos comandos crean la interfaz nat64 con las direcciones ip 192.168.0.1/32 y 2001:db8:1::1/128, como dije anteriormente no importa que se solape con los IPs de eth1).

Para revisar:
root@aacosta-ThinkPad-E420:~# ifconfig nat64
nat64     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.0.1  P-t-P:192.168.0.1  Mask:255.255.255.255
          inet6 addr: 2001:db8:1::1/128 Scope:Global
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2393 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2395 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:1615556 (1.6 MB)  TX bytes:1614316 (1.6 MB)


7) Creación de rutas:
#ip route add 192.168.255.0/24 dev nat64

#ip route add 2001:db8:1:ffff::/96 dev nat64

8) Ejecutamos Tayga

#tayga -d

(el -d es opcional, solo es para tener más información)


PROBAR NAT64
a) Probamos que todo este bien (el ping debe ser satisfactorio):

root@aacosta-ThinkPad-E420:~# ping6 2001:db8:1:ffff::192.168.0.1
PING 2001:db8:1:ffff::192.168.0.1(2001:db8:1:ffff::c0a8:1) 56 data bytes
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=109 ttl=63 time=2.18 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=110 ttl=63 time=0.209 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=111 ttl=63 time=0.190 ms
64 bytes from 2001:db8:1:ffff::c0a8:1: icmp_seq=112 ttl=63 time=0.126 ms



b) Realizamos NAT con la interfaz IPv4 saliente (solo si el pool IPv4 en Tayga es privado):

#iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 
#iptables -A FORWARD -i eth0 -o nat64 -m state --state RELATED,ESTABLISHED -j ACCEPT 
#iptables -A FORWARD -i nat64 -o eth0 -j ACCEPT

c) Ahora solo debes dirigirte a la máquina cliente y todo debe estar funcionando. Ejemplos de ping y trace:


[root@localhost ~]# traceroute6 www.algo.com -n
traceroute to algo-com-prod-elb-170663297.us-east-1.elb.amazonaws.com (2001:db8:1:ffff::36f3:7ac3) from 2001:db8:1:1::2, 30 hops max, 16 byte packets
 1  2001:db8:1:1::1  1.224 ms  3.8 ms  0.352 ms
 2  2001:db8:1:ffff::c0a8:ff01  0.787 ms  0.772 ms  0.268 ms
 3  2001:db8:1:ffff::c0a8:1  0.76 ms  0.869 ms  0.278 ms


[root@localhost ~]# ping6 www.parmalat.com.ve -n
PING www.parmalat.com.ve(2001:db8:1:ffff::c82f:4f04) 56 data bytes
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=1 ttl=56 time=7.30 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=2 ttl=56 time=5.82 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=3 ttl=56 time=5.93 ms
64 bytes from 2001:db8:1:ffff::c82f:4f04: icmp_seq=4 ttl=56 time=8.38 ms



  Puedes ver un estado de las asignaciones de Tayga en: /var/log/tayga/dynamic.map



Voila!... todo debe estar funcionado en este momento!


Mas información: 
http://www.litech.org/tayga/
http://www.litech.org/tayga/README-0.9.2

http://kurser.iha.dk/eit/itifn/workshops/vne_workshop_2.html
http://ipvsix.me/?tag=tayga

Notas importantes:
- El DNS64 no funciona cuando la respuesta DNS tenga registros AAAA y A. En realidad no es una eroor porque se asume que el host tiene acceso IPv6 a Internet
- Es importante que el DNS64 y NAT64 compartan el mismo prefijo IPv6 (en el ejemplo de este post 2001:db8:1:ffff::/96. 
- Durante todo el post describo el procedimiento utilizando la subred IPv6 2001:db8::/32. Favor notar que esta subred debe ser sustituida por sus redes respectivas (al igual que la información referente a IPv4).
- Pueden utilizar 2001:db8::/32 y va a funcionar igualmente pero sin acceso a destinos a IPv6
- El servidor DNS64 y NAT64 pueden ser diferentes equipos/máquinas


viernes, 28 de septiembre de 2012

Como forzar una consulta DNS a un determinado servidor

Introducción:
  Este post es sumamente sencillo pero espero sea útil.
  Hoy recibí por correo la pregunta de como forzar o realizar una consulta DNS sobre un determinado servidor.

Situacion:
  Deseo que mi consulta DNS sea dirigida/apuntada/forzada sobre cierto servidor específico, las razones pueden ser variadas, desde curiosidad o troubleshooting. En el caso del día de hoy querían verificar que un DNS secundario estuviese copiando la zona correctamente.

Solución:
  Existen varias soluciones:

1) La más fácil (pero poco elegante):
   Configurar el/los DNS sobre los que se desea hacer la consulta sobre el host con el que voy a trabajar. Ejecutar por ejemplo un ping al nombre y verificar el IP que devuelve

2) Nslookup (funciona sobre windows y linux)
  En el siguiente ejemplo voy a verificar como resuelve blog.acostanetwork.com el servidor 8.8.8.8

aacosta@aacosta:~$ nslookup  --> para entrar en un subshell
> server 8.8.8.8     ---->>> indico el DNS sobre quien va ir dirigida la consulta
Default server: 8.8.8.8
Address: 8.8.8.8#53
> blog.acostasite.com   ----> indico el nombre que deseo consultar
Server:        8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
blog.acostasite.com    canonical name = cf-protected-blog.acostasite.com.
Name:    cf-protected-blog.acostasite.com
Address: 108.162.198.198
Name:    cf-protected-blog.acostasite.com
Address: 108.162.195.100

  En el ejemplo anterior hay que cambiar "8.8.8.8" por la dirección IP a quien deseamos enviar la consulta

3) Dig (Linux)
  En el siguiente ejemplo voy a verificar como resuelve blog.acostanetwork.com el servidor 8.8.4.4

aacosta@aacosta-ThinkPad-E420:~$ dig @8.8.4.4 blog.acostasite.com

; <<>> DiG 9.8.1-P1 <<>> @8.8.4.4 blog.acostasite.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 17584="17584" br="br" id:="id:" noerror="noerror" opcode:="opcode:" query="query" status:="status:">;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;blog.acostasite.com.        IN    A

;; ANSWER SECTION:
blog.acostasite.com.    0    IN    CNAME    cf-protected-blog.acostasite.com.
cf-protected-blog.acostasite.com. 117 IN A    108.162.198.198
cf-protected-blog.acostasite.com. 117 IN A    108.162.195.100

;; Query time: 67 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Fri Sep 28 09:44:34 2012
;; MSG SIZE  rcvd: 101

  En el ejemplo anterior hay que cambiar "8.8.4.4" por la dirección IP a quien deseamos enviar la consulta
  El mismo


Espero sea útil,