Cliente SSH dura varios segundos para conectarse

Otro post sumamente rápido (pero útil):

Caso:
  Cuando intento conectarme a un servidor SSH (Linux server) el mismo dura varios segundos antes de pedir login/password.
  Esto es muy comun en servidores que no tienen acceso a Internet o DNSs mal configurados.

  Ocurre que cuando intentamos conectarnos al SSH Server intenta hacer una solicitud de DNS reverso para IP origen (de donde nos intentamos conectar).

  Por ejemplo, si quiero conectarme desde el equipo 192.168.1.2 al servidor SSH ubicado en el IP 10.1.1.21, este último, durante la conexión intentará buscar el reverso del IP 192.168.1.2.  El tiempo que vemos antes de obtener "Login" es precisamente el timeout del SSH Server durante la operación DNS.

Solución:
  La solución es sumamente sencilla, existen dos manera:

1) Si siempre nos vamos a conectar desde la misma dirección IP (o muy pocas diferentes):
  En el servidor editar el archivo /etc/hosts y colocar los IPs de origen desde donde me conectaré. ejemplo:

192.168.1.2  blog.acostasite.com  aacostaPC
192.168.1.3  www.lomejordelemail.com miPC

2) La solución alternativa es colocar al final del archivo /etc/ssh/sshd_config 


UseDNS no

Más información:

SSH Manual page
Getting started with SSH

Espero haya sido útil.

Como instalar un root server local (DNS).

Hola,
  Recientemente en algunas listas de discusión que sigo se hablaba sobre instalar un servidor DNS root server local, en fin, me llamó la curiosidad y lo hice solo por razones académicas.
  He escuchado que esto de alguna manera puede mejorar el performance de alguna red, sobre todo en el mundo de los ISPs, sin embargo, en lo personal no lo veo necesario, lo dejo al criterio de cada uno de ustedes.
 
Laboratorio:
  - Dos servidores y un cliente: Un servidor con Ubuntu, otro con Mandriva, el cliente también fue Mandriva. Donde:
    * Servidor Mandriva como Root Server (Nombre Z, IP=192.168.127.68)
    * Servidor Ubuntu como Servidor DNS recursivo (IP=192.168.127.86)

Primero:
    1) Logicamente probar que el servidor recursivo funcione correctamente
    2) Posteriormente, editar el archivo db.root de Ubuntu y dejar algo similar a:


;
.                        3600000  IN  NS    Z.ROOT-SERVERS.NET.
Z.ROOT-SERVERS.NET.      3600000      A     192.168.127.68
; End of File

  Notese que realmente lo que hice fue eliminar los root servers tradicionales y agregar las lineas correspondientes a Z.ROOT-SERVERS.NET (Z es el nombre del mi root server y 192.168.127.68 es la dirección). 

  Logicamente sin haber más hints de root server, el servidor recursivo se verá forzado a utilizar Z como root server.

Nota:

  En /var/log/syslog luego de reiniciar BIND puedes conseguir una línea similar a la siguiente:

May 25 19:05:16 ubuntu named[4953]: checkhints: extra NS 'Z.ROOT-SERVERS.NET' in hints

Segundo:

  Aqui es donde realmente instalamos el root server en el servidor Mandriva (que realmente es muy sencillo).

  1) Bajar el archivo root.zone de: http://www.iana.org/about/popular-links/

  2) En el archivo /etc/named.conf del root server hay que modificar el siguiente renglón:

  zone "." {

        type hint;

        file "/etc/bind/db.root";

};

  Por:

zone "." {

        type master;

        file "/etc/bind/root.zone";

};

 El archivo root.zone debe estar ubicado en el directorio correspondiente, en mi caso fue en /var/lib/named/var/named/, posteriormente hay que reiniciar y ya. En el root server ni siquiera hay que estar pendiente de recursividad y esas cosas porque este tipo de servidor tradionalmente no debe ni necesita hacer esta operación.

Tercero:

  Probar desde el cliente:

[root@localhost ~]# dig blog.acostasite.com

; <<>> DiG 9.8.0-P4 <<>> blog.acostasite.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26771

;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, 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. 300 IN A      108.162.198.198

cf-protected-blog.acostasite.com. 300 IN A      108.162.195.100

;; AUTHORITY SECTION:

acostasite.com.         172800  IN      NS      bob.ns.cloudflare.com.

acostasite.com.         172800  IN      NS      leah.ns.cloudflare.com.

;; Query time: 199 msec

;; SERVER: 192.168.127.86#53(192.168.127.86)

;; WHEN: Fri May 25 19:34:24 2012

;; MSG SIZE  rcvd: 152

Mas información:

- http://www.iana.org/about/popular-links/

- http://serverfault.com/questions/178931/is-it-possible-to-create-your-own-root-dns-server

  Espero haya sigo útil.

   

Completar el nombre de dominio en Linux

Introduccion:

  Este es un post muy corto, sencillo pero muy útil.

  El dia de hoy un amigo mio me preguntó como hacía para que su estación Linux completara el FQDN al momento de resolver un nombre, por ejemplo el quería escribir www y que su estación con linux buscara www.acostasite.com

Solución:
  La solución es sumamente sencilla, lo unico que hay que hacer es editar el archivo /etc/resolv.conf y colocar el parametro domain dentro del mismo. Recordemos que este archivo es donde se especifican los servidores DNS que utilizará Linux
  Por ejemplo, supongamos que yo deseo hacer ping a host blog dentro de blog.acostasite.com:

1) En /etc/resolv.conf debe haber algo como:


nameserver 8.8.8.8
domain acostasite.com

2) Posteriormente con solo hacer referencia a blog dentro un shell o en cualquier sitio del OS el mismo OS intentará ubicar el host blog, sino lo consigue colocará de manera automatica el sufijo acostasite.com

Ejemplo de la salida:

[root@localhost ~]# ping blog -n
PING cf-protected-blog.acostasite.com (173.245.61.138) 56(84) bytes of data.
64 bytes from 173.245.61.138: icmp_req=1 ttl=57 time=135 ms
64 bytes from 173.245.61.138: icmp_req=2 ttl=57 time=136 ms
64 bytes from 173.245.61.138: icmp_req=3 ttl=57 time=135 ms
64 bytes from 173.245.61.138: icmp_req=4 ttl=57 time=135 ms

Notese que en el ping yo solo escribí "blog" y el OS completó automaticamente acostasite.com (la opción "-n" solo evita el rdns de la respuesta)

Eso es todo!, espero sea útil,

Implementar DNSSEC sobre Linux. Solo resolver. Version 2

Este documento es una actualizacion de "Implementar DNSSEC sobre Linux. Solo resolver" fechado 25 de Noviembre de 2009.

Historia:
Luego de la firma de los root servers a mediados del año 2010 (ver http://www.root-dnssec.org/) habilitar DNSSEC en el resolver es mucho más sencillo debido a que solo hay que validar "." dentro de nuestro archivo de configuración. Anteriormente necesitabamos trust anchors para cada dominio (TLD, ccTLD, zonas) que queriamos validar. Este trabajo era insoportable de manejar y no era escalable.
Ahora con la firma de los root-servers todo es más sencillo.

Software:
Bind 9.7.2-P3
Linux Mandriva 2010.2

Procedimiento:
1) Primero es necesario colocar el trust-anchor para el root zone. Para obtenerlo:

#dig . dnssec

La salida anterior te entregará varios resultados:

root@localhost ~]# dig . dnskey
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.7.2-P3 <<>> . dnskey
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60029
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;. IN DNSKEY

;; ANSWER SECTION:
. 136089 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=
. 136089 IN DNSKEY 256 3 8 AwEAAb5gVAzK59YHDxf/DnswfO1RmbRZ6W16JfhFecfI+EUHRXPWlXDi 47t2FHaKyMMEROapL5SZ8HiCzl05lORZGGdN37WY7fkv55rs+kwHdVRS rQdl81fUnEspt67IIgaj3SrGyZqgzyixNk/8oT3yEfKDycTeJy4chKPt 0JegWrjL
. 136089 IN DNSKEY 256 3 8 AwEAAcaGQEA+OJmOzfzVfoYN249JId7gx+OZMbxy69HfUyuGBbRN0+Hu TOpBxxBCkNOL+EJB9qJxt+0FEY6ZUVjEg58sRr4ZQ6Iu6b1xTBKgc193 zUARk4mmQ/PPGxn7Cn5VEGJ/1h6dNaiXuRHwR+7oWh7DnzkIJChcTqlF rXDW3tjt

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Apr 2 10:00:49 2011
;; MSG SIZE rcvd: 586

Nos interesa la sección correspondiente a la 257, este valor corresponde a SEP o Secure Entry Point, también conocido como los KSK o Key Signing Key. Como dato adicional el valor 256 corresponde a los Zone Signing Key (ZSK)

2) Del resultado anterior, vamos a copiar la llave (despues del "257 3 8") y vamos a crear la siguiente seccion managed-keys dentro de named.conf. Quedando así:

managed-keys {
"." initial-key 257 3 8 "AwEAAagAIKlVZrp...";
};

3) Dentro de la sección de opciones de named.conf vamos a colocar lo siguiente:

dnssec-enable yes;
dnssec-validation yes;

Reinicia BIND y debe estar funcionando.

Revisar que DNSSEC este operando bien:

La mejor opción es utilizar el famoso comando dig y chequear el flag AD en al respuesta. Por ejemplo:

RESPUESTA SIN DNSSEC

[root@localhost etc]# dig +dnssec registro.br

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43771
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5


RESPUESTA CON DNSSEC

[root@localhost etc]# dig +dnssec registro.br

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1063
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1


Nótese que que el flag ad no esta encendido en la respuesta sin DNSSEC

Otra forma más sencilla de revisar si esta funcionando DNSSEC es entrar a la página: "DNSSEC test tool" de SIDN y correr la prueba.


Más información:

- El concepto de managed-keys fue introducido en Bind 9.7 en adelante. Ver
- Articulo excelente que indica como hacer que Bind se convierta en un DNSSEC validator

Cambiar los DNSs se Windows via Command Prompt

Situacion:
Por diversas razones usted puede querer cambiar los DNSs de alguna conexion dentro de su computadora via comando (desde una ventana de DOS). En mi caso queria cambiar los DNSs de una conexion dentro de mi Windows Vista y me di cuenta que era mas facil por comandos
Problema:
Deseo cambiar los DNSs de Windows via comandos.

Solucion:
La solucion es utilizar netsh.
netsh viene de dos maneras: 1) modo interactivo y 2) modo directo. En el primero uno entra en un nuevo shell (ejecuta netsh sin argumentos) y en el segundos los comandos se envian directos.
En el presente ejemplo haremos todo por la segunda via. Los pasos en general son:

1) Ubicar el nombre exacto de la conexion a la cual queremos cambiar los DNS:
netsh interface ip show config

2) Cambiar los DNS con el comando netsh:netsh interface ip set dns "Nokia GSM Phone USB Modem #5 (NPCIA)" static 8.8.8.8

Screenshots:




Mas informacion:
http://support.microsoft.com/kb/242468
http://es.kioskea.net/faq/535-cambiar-la-direccion-ip-desde-la-linea-de-comandos-con-netsh

Descripción del log bind

Situación:
Leyendo el log de bind tengo algunas dudas

Solución:
Luego de una ardua busqueda en Google conseguí el siguiente link donde Jeremy Reed responde que significan los flag dentro del log de Bind.

Ejemplo:

05-Jan-2011 09:54:36.620 client 210.19.118.16#32784: view everyone: query: www.whatismyipv6.co IN A -EDC

Del log anterior se entiende:
Fecha
Hora
Direccion IP del cliente
Puerto utilizado por el cliente
Vista utilizado segun configuracion del cliente
Tipo de solicitud
Descripcion del objeto solicitado
- significa que no hubo solicitud de recursividad
S=Query signed
E=EDNS
D=DNSSEC Ok
C=Checking Disabled

Bind / Syslog / Logrotate

Situacion:
Deseo que Bind envie los logs a traves de Syslog y luego rotarlos diariamente con logrotate.

Solucion:
Para lograr que Bind envie sus logs a traves de Syslog recomiendo seguir los siguientes pasos:

1) Definir un nuevo facility en /etc/syslog.conf el cual utilizaremos como "canal" dentro de Bind. Esto es muy conveniente para tener un unico archivo con solo informacion relevante sobre DNS y Bind. Para definir el facility coloca lo siguiente dentro de /etc/syslog.conf

local7.* -/var/log/bind.log

NOTA: Recuerda que puedes definir desde local0 hasta local7 facities segun tu necesidad

2) Luego en Bind se le va a indicar que utilice el facity local7 y guarde los logs de query (en mi caso es lo unico que necesito, se puede almacenar gran cantidad de logs referentes a otros temas como: lame servers, dnssec, xfer y mucho mas). Ademas de almacenar el query deseo que se escriba la fecha y hora del query DNS. En /etc/named.conf (seccion de options) agrega:

logging {
channel query.log {
severity debug 3;
print-time yes;
syslog local7;
};
category queries { query.log; };
};

3) Debido al tamano del logs, posteriormente tuve la necesidad de rotarlo de manera diaria pero antes deseo realizar la rotacion deseaba ejecutar un script para un proceso puntual. Para ello hice la siguiente configuracion en logrotate. Para este punto editar el archivo /etc/logrotate.d/bind y anadir:

/var/log/bind.log {
daily
prerotate
/root/SCRIPTS/dnsqueries.sh
endscript
missingok
rotate 4
compress
create
}

Con este paso, el archivo /var/log/bind.log se rotara automaticamente de manera diaria pero antes se ejecutara el script /root/SCRIPTS/dnsqueries.sh.

Mas informacion:
http://zytrax.com/books/dns/ch7/logging.html (DNS Bind Logging)
http://doc.novsu.ac.ru/oreilly/tcpip/puis/ch10_05.htm (The Unix system log)

Suerte, espero haya sido util,

Herramienta en linea gratis para configurar reversos de IPv6

Situacion:
El dia de ayer tuve la necesidad de configurar los reversos de un prefijo IPv6 en mis servidores Bind; honestamente era la primera vez que tenia que hacer dicha tarea y por ello recurri a nuestro buen amigo google

Solucion:
En fin, luego de realizar una pequena busqueda consegui la siguiente herramienta en linea y gratuita que decidi compartirla con ustedes debido a que es excelente: http://www.fpsn.net/tools&tool=ipv6-inaddr. La herramienta es un "constructor de reversos IPv6"
La herramienta es muy sencilla de utilizar, la misma te hace las preguntas de: a) prefijo IPv6, b) email del responsable de la zona, c) servidor DNS primario y secundario y d) las direcciones IPv6 a las cuales deseas crearle el nombre.
Lo interesante de la herramienta es que te genera tanto el codigo a colocar dentro del named.conf como el del archivo de zona. Luego solo tienes que hacer copy/paste.
Les dejo otra vez el link: http://www.fpsn.net/tools&tool=ipv6-inaddr
Probar conexiones IPv6: http://acostanetwork.blogspot.com/2009/04/probar-ipv6.html y http://www.whatismyipv6.co

Luego de utilizar la herramienta todo funciono perfecto!!

Como capturar el bit recursion desired con tcpdump en un query DNS

Problema: El día de hoy escuchando el Podcast de Mr DNS escuché la idea de tomar el Bit de recursividad (recursion desired) en un paquete DNS. En ese momento me pareció buena idea intentarlo y por ello el presente post. Solución: Lo primero que hice fue hacer una captura y analizarla con Tcpdump y adicionalmente averiguar especificamente como es un paquete de pregunta DNS. Para esto último conseguí el siguiente paquete el cual tomé de: An Illustrated Guide to the Kaminsky DNS Vulnerability En este sentido, me interesa tomar el bit RD cuando se encuentre encendido. Debido a que tcpdump permite obtener el encendido/apagado de los bits pero en octetos hay que darse cuenta que el bit RD es el bit menos significativo del octeto numero 10 dentro del paquete UDP. En otras palabras, en el gráfico anterior cada "linea" tiene 4 octetos (32 bits). Si comenzamos a contar desde el Campo Source Port de UDP hasta el campo Query ID (incluyendo) existen 9 octetos. Por ello los próximos 8 bits son los flags del paquete DNS y el último de estos 8 (de izquierda a derecha) es el RD. En un query standard DNS estos 8 bits generalmente vienen de la manera: 00000001, por ello el comando tcpdump que necesitamos es el siguiente: #tcpdump -i eth0 udp[10] == 1 and port 53 Captura del wireshark: Links importantes: http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html Mr DNS Podcast
check out this page
LEAF DOMICILE Buy Marijuana Online, CBD Oil,Vape Store, Weed For Sale – Leaf Domicile Delivery Buy Weed Online at Leaf Domicile A wide collection of Weed Buds, Isolates, Hash, Vape Pens, Wax, Cartridges,Seeds, Concentrates, Edibles, CBD Oil for sale Buy Marijuana Online,Buy Weed Online,Weed For Sale,Buy kush online,- https://leafdomicile.com/ THC edibles for sale, order edibles, where can I buy edibles, mail order weed, buy wax online, buy cbd vape oil, pre rolled joints for sale, pre rolled joints for sale, buy kush online, where to buy dabs online, weed dabs for sale, wax for sale,

Utilizando DNSTOP

Objetivo:
Utilizar correctamente DNSTOP

Software utilizado:
Distribución Mandriva
DNSTOP (http://www.rpmfind.net/linux/rpm2html/search.php?query=dnstop&submit=Search+...)

Ejecutando dnstop:
La manera de ejecutar dnstop es: comando interface. Por ejemplo

# dnstop {interface-name}
# dnstop eth0
# dnstop wlan0

Una salida tipica es:

Queries: 53 new, 391 total Thu Mar 25 13:04:37 2010

Sources Count %
--------------- --------- ------
200.xx.xx.5 137 35.0
200.xx.xx.2 46 11.8
200.xx.xx.253 24 6.1
190.xx.xx.2 21 5.4
200.xx.xx.140 18 4.6
200.xx.xx.30 12 3.1
200.xx.xx.141 11 2.8
200.xx.xx.118 10 2.6
200.xx.xx.186 10 2.6
10.xx.xx.162 8 2.0
200.xx.xx.138 8 2.0
200.xx.xx.6 6 1.5

Ahora bien, dnstop no solo genera la salida anterior sino que puede generar MUCHA más información, todo es cuestión de saberlo utilizar.
Por ejemplo, puedes ejecutar dnstop con el siguiente comando:
#dnstop -l 3 eth1

Durante la ejecución presiona el numero "1" o "2" o "3". Podrás ver hasta 3 niveles de resolución de nombres y así saber que nombres generalmente resuelven tus clientes.

Otra opción muy interesante es el tipo de query sobre el DNS Server (A, AAAA, PTR, etc). Para ello durante la ejecución presiona "t".

Opciones típicas de dnstop:

 s - Sources list
d - Destinations list
t - Query types
o - Opcodes
r - Rcodes
1 - 1st level Query Names      ! - with Sources
2 - 2nd level Query Names      @ - with Sources
3 - 3rd level Query Names      # - with Sources
4 - 4th level Query Names      $ - with Sources
5 - 5th level Query Names      % - with Sources
6 - 6th level Query Names      ^ - with Sources
7 - 7th level Query Names      & - with Sources
8 - 8th level Query Names      * - with Sources
9 - 9th level Query Names      ( - with Sources
^R - Reset counters
^X - Exit

? - this

Links:
Este articulo es una traducción y adaptación de experiencia propia de: http://www.cyberciti.biz/faq/dnstop-monitor-bind-dns-server-dns-network-traffic-from-a-shell-prompt/

Realizar estudios de performance sobre un DNS Server

INTRODUCCION:

Recientemente tuve la necesidad de realizar algún estudio sobre el funcionamiento de dos servidores DNS los cuales soy responsable por su administración. Mis dudas
eran relacionadas al performance de los servidores.
En el mundo de los DNS el performance se mide de dos maneras:
* Throughput (numero de queries por segundo que el DNS Server es capaz de manejar)
* Latencia (tiempo de resolución de los queries)

En base a lo anterior uno mismo puede contruir unos scripts y apoyandonos en el comando DIG obtener gran información. Sin embargo durante mi investigación y
a través de una lista conseguí dos herramientas que pueden realizar un excelente estudio: dnsperf y resperf (http://www.nominum.com/services/measurement_tools.php)

OBJETIVO
Realizar y evaluar el performance de un DNS Server

SOFTWARE NECESARIO:
En mi caso hice todas las pruebas sobre un DNS Server en mandriva las herramientas sobre mandriva.
Software adicional: dnsperf y resperf. Se puede conseguir: http://www.nominum.com/services/measurement_tools.php
GNUplot

INSTALACION
wget ftp://ftp.nominum.com/pub/nominum/dnsperf/1.0.1.0/dnsperf-1.0.1.0-1-rhel-5-i386.tar.gz
tar -zxvf dnsperf-1.0.1.0-1-rhel-5-i386.tar.gz
cd dnsperf-1.0.1.0-1
rpm -ivh dnsperf-1.0.1.0-1.i386.rpm
urpmi gnuplot (MUY RECOMENDADO para generar unas gráficas más adelantes)

Los archivos binarios quedaran instalados en:
/usr/local/nom/bin

DOCUMENTACION:
Luego de la instalación del paquete existe una excelente documentación en formato pdf ubicada en:

/usr/local/nom/doc/dnsperf


FUNCIONAMIENTO:
En fin, basicamente lo que ambos programas hacen es tomar una enorme lista (un archivo de texto) donde existen miles de dominios separados por el tipo de query (A, AAAA, PTR, TXT, etc), lo envia a un servidor DNS (indicado por linea de comando) y luego empieza a recabar información para finalmente ofrecer un resumen de los resultados.
El archivo de texto puede ser editado, cambiado, modificado, etc por uno mismo sin inconveniente (archivo original: queryfile-example-100thousand).

EJEMPLOS:
Vamos a nombrar dos diferentes comandos con los cuales podemos hacer una evaluación. Recomiendo ampliamente leer la documentación oficial antes de proseguir. Estas herramientas consumen alto procesamiento de CPU, consumo de memoria y ancho de banda. Es muy sencillo saturar un servidor y dejarlo fuera de linea con estas herramientas. Adicionalmente hay que tener mucho cuidado con diversos firewalls que pueden encontrarse
en el medio entre el DNS Server y el cliente que ejecuta la aplicación.
Aquí van los ejemplos:

Comando 1: resperf

• Ejemplo 1-1:

Query de 100000 consultas al DNS Server de localhost con un máximo de 100 consultas por segundo:

./resperf -s 127.0.0.1 -d queryfile-example-100thousand.orig -m 100

Ejemplo de la salida:

DNS Resolution Performance Testing Tool

Nominum Version 1.0.1.0

[Status] Sending
[Status] Waiting for more responses
^C
[root@localhost bin]# ./resperf -s 127.0.0.1 -d queryfile-example-100thousand -m 100

DNS Resolution Performance Testing Tool

Nominum Version 1.0.1.0

[Status] Sending
[Status] Waiting for more responses
[Status] Testing complete

Statistics:

Queries sent: 2999
Queries completed: 2985
Queries lost: 14
Ran for: 100.000002 seconds
Maximum throughput: 98.000000 qps
Lost at that point: 2.00%

• Ejemplo 1-2:

Query de 100000 consultas al DNS Server de localhost con un máximo de 10 consultas por segundo pero con un reporte en una página Web:

./resperf-report -s 127.0.0.1 -d queryfile-example-100thousand.orig -m 10
Ejemplo de la página Web:

• Ejemplo 1-3:

Query de 100000 consultas al DNS Server de localhost con un máximo de 100000 consultas por segundo pero con un reporte en una página Web:
./resperf-report -s 127.0.0.1 -d queryfile-example-100thousand.orig


Comando 2: dnsperf

Ejemplo 2-1:
Ejecutar 3 queries maximos al servidor localhost con un histograma de 20 por 10 segundos:

./dnsperf -d ../examples/dnsperf/queryfile-example-100thousand -q 3 -H 20 -l 10 -s 127.0.0.1

Salida del comando anterior:

[root@localhost bin]# ./dnsperf -d queryfile-example-100thousand -q 10 -H20 -l 10

DNS Performance Testing Tool

Nominum Version 1.0.1.0

[Status] Processing input data
[Status] Sending queries (to 127.0.0.1)
[Status] Testing complete


Statistics:

Parse input file: multiple times
Run time limit: 10 seconds
Ran through file: 144 times

Queries sent: 870 queries
Queries completed: 870 queries
Queries lost: 0 queries

Avg request size: 37 bytes
Avg response size: 161 bytes

Percentage completed: 100.00%
Percentage lost: 0.00%

Started at: Mon Feb 22 18:17:43 2010
Finished at: Mon Feb 22 18:17:53 2010
Ran for: 10.105866 seconds

Queries per second: 86.088614 qps

Latency: Min: 0.000284 s; Max: 1.121552 s; Avg: 0.111007 s; StdDev: 0.169328

Response latency distribution (total 870 responses):

Latency Success Fail |
<>= 1.000s 8 0 |#

Legend:

##### = success responses (RCODE was NOERROR or NXDOMAIN)
----- = failure responses (any other RCODE)


Ejemplo 2-2:

Ejecutar 20 queries maximos al servidor localhost con un histograma de 4 por 20 segundos con una cantidad máxima de 25 queries por segundo:
./dnsperf -d queryfile-example-100thousand -q 20 -H4 -l 20 -Q 25

Suerte, espero sea de tu utilidad

Implementar DNSSEC sobre Linux. Solo resolver

*** POST OBSOLETO ****
*** FAVOR LEER LA VERSION 2 ***

Problema:
Montar un servidor DNS solo como resolver, es decir, sin funcionar como servidor autorizado para ciertas zonas


Que se necesita:
- Servidor Linux
- Bind 9.3 o superior (en mi caso utilicé 9.6)


Alcance
- Vamos a validar todo lo que sea .br
- Vamos a validar todo lo que sea udp53.org

Procedimiento:
1) Instalar bind en un servidor Linux. En mi caso utilizo Mandriva y con un sencillo urpmi bind fue suficiente. Es importante destacar que para que DNSSEC ande se necesita tener instalado openssl y sus librerias. Actualmente la inmensa mayoría de las distribuciones ya viene con openssl

2) En /var/named.conf se necesita:
options {
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside "." trust-anchor dlv.isc.org.;
};

La primera opción permite dnssec para las zonas autorizadas y la segunda opción para realizar recursividad utilizando DNSSEC. La tercera opción la veremos con detalle más adelante.


3) Es necesario obtener las llaves públicas de los registros .br y udp53.org (que son los dominios que queremos verificar en este momento). Para ello:

[root@localhost etc]# dig br DNSKEY

{...}

br. 21502 IN DNSKEY 257 3 5 AwEAAdDoVnG9CyHbPUL2rTnE22uN66gQCrUW5W0NTXJBNmpZXP27w7PM Npyw3XCFQWP/XsT0pdzeEGJ400kdbbPqXr2lnmEtWMjj3Z/ejR8mZbJ/ 6OWJQ0k/2YOyo6Tiab1NGbGfs513y6dy1hOFpz+peZzGsCmcaCsTAv+D P/wmm+hNx94QqhVx0bmFUiCVUFKU3TS1GP415eykXvYDjNpy6AM=

{...}


[root@localhost etc]# dig udp53.org DNSKEY

{...}

udp53.org. 5882 IN DNSKEY 257 3 5 BEAAAAMKj6IGc8E/bBW7i6zDGgnKUXwamtR9PlFiuTg0/oa4i1okCg4J vLEq7EVpxdDi4yc1Ym9kGTUngZ59iVleoL8O5Zq+oPAPCYSbtn+ASsL6 0iCp4PJ6LV0A9d2NE/BetXO/Re/NRsSG18yFZCWGfX8mBnb2zG7Mb+0t pUuRsu9dBN31ljsbTUGmkDbqEw2xaDAUXqDGD5+pgN0NGqcPg0/HzFv9

{...}

4) Necesitamos las llaves DLV que pueden ser conseguidas en la pagina de la ISC en:
http://ftp.isc.org/www/dlv/dlv.isc.org.key.
Las llaves DLV ((DNSSEC Look-aside Validation) son un recurso adicional utilizado en aquellos servidores DNSSEC con recursividad. La idea es apoyar al conglomerado de internet en las primeras etapas de DNSSEC en el mundo

5) Vamos a copiar esas llaves obtenidas en el archivo named.conf bajo la sección trusted-keys (si no existe dicha sección en el archivo la crearemos). Por ejemplo

trusted-keys {
"br." 257 3 5
"AwEAAdDoVnG9CyHbPUL2rTnE22uN66gQCrUW5W0NTXJB
NmpZXP27w7PMNpyw3XCFQWP/XsT0pdzeEGJ400kdbbPq
Xr2lnmEtWMjj3Z/ejR8mZbJ/6OWJQ0k/2YOyo6Tiab1N
GbGfs513y6dy1hOFpz+peZzGsCmcaCsTAv+DP/wmm+hN
x94QqhVx0bmFUiCVUFKU3TS1GP415eykXvYDjNpy6AM=";

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

"udp53.org." 257 3 5 "BEAAAAMKj6IGc8E/bBW7i6zDGgnKUXwamtR9PlFiuTg0/oa4i1okCg4J vLEq7EVpxdDi4yc1Ym9kGTUngZ59iVleoL8O5Zq+oPAPCYSbtn+ASsL6 0iCp4PJ6LV0A9d2NE/BetXO/Re/NRsSG18yFZCWGfX8mBnb2zG7Mb+0t pUuRsu9dBN31ljsbTUGmkDbqEw2xaDAUXqDGD5+pgN0NGqcPg0/HzFv9";

};

6) Listo!!., reiniciar el servidor named. Por ejmplo:
/etc/init.d/named restart (o con rndc, como tu desees)

Revisar que se encuentre funcionando bien

La mejor opción es utilizar el famoso comando dig y chequear el flag AD en al respuesta. Por ejemplo:

RESPUESTA SIN DNSSEC

[root@localhost etc]# dig +dnssec registro.br

; <<>> DiG 9.6.0-P1 <<>> +dnssec registro.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43771 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5



RESPUESTA CON DNSSEC

[root@localhost etc]# dig +dnssec registro.br

; <<>> DiG 9.6.0-P1 <<>> +dnssec registro.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1063 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1


Más información:
* www.isc.org/files/DNSSEC_in_6_minutes.pdf
* http://registro.br/info/dnssec.html

Problemas con Postfix dsn= 4.4.2

En el dia de ayer, una empresa a la que a veces le presto servicios me llamo porque estaban teniendo fallas con su servicio de correo.

El primer paso que hice, fue revisar los logs, y al hacerlo me encontre con estos errores que ocurrian con varios Dominios:

dsn=4.4.2, status=deferred (lost connection with alt1.gmail-smtp-in.l.google.com[209.85.222.27] while sending message body)

dsn=4.4.2, status=deferred (lost connection with f.mx.mail.yahoo.com[98.137.54.237] while sending end of data -- message may be sent more than once)

Estos errores tienden a ser por problemas de latencia, que la transmision del correo se cierra debido al delay que se presenta, pero para mi sorpresa, el enlace estaba bien, no habia latencia en la red de la empresa.

Intente disminuir el MTU de la interfaz eth0:

debian:/home/xxxx# ifconfig eth0 mtu 1000
debian:/home/xxxx# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1a:4b:5e:10:c8
inet addr:10.10.10.10 Bcast:192.168.127.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1000 Metric:1

Pense que esto iba a solucionarlo, pero no fue asi, despues de correr "mailq -q" para forzar la salida de los correos en cola, los mismos se mantenian en las mismas condiciones.

Capaz era problema se relacionaba con el MTU discovery

"debian:/home/xxxx#echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc"

Luego de volver a correr "mailq -q", seguia dando el mismo error.


Por lo que procedi a instalar tcpdump "debian:/home/xxxx# aptitude install tcpdump" y sniffear el trafico del puerto 25.

"debian:/home/xxxx# tcpdump -i eth0 port 25"

Y lo deje corriendo un rato, mientras enviaba correos a la empresa y de la empresa enviaba correos a otros dominios. Luego de obtener bastante informacion procedi a analizarla con Wireshark (esta herramienta es lo mejor creado por el ser Humano, junto con nmap :P).

Comparte con ustedes lo que vi en Wireshark


Al ver el error que estaba teniendo en cuanto al "TCP checksum offload", procedi a deshabilitarlo en la interfaz eth0.

Esto se puede hacer con una herramienta que se llama ethtool, que te permite manipular las propiedades de la interfaz.


debian:/home/xxxx# ethtool --show-offload eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device flags: Operation not supported
rx-checksumming: off
tx-checksumming: on <============
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off

debian:/home/xxxx# ethtool --offload eth0 tx off

y luego

debian:/home/xxxx# ethtool --show-offload eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device flags: Operation not supported
rx-checksumming: off
tx-checksumming: off <============ :)
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off


Al hacer esto, los correos empezaron a salir :)....

Para quienes no tengan muy claro que es esto, les dejo una pequenha nota;

"If you are experiencing network problems and while trying to figure
it out with Wireshark you found these checksum errors, you may have a
network card with TCP checksum offload enabled and for some reason the
packet is not being fixed by the adapter (NAT, bridge or route
redirection is sending the packet to another interface). In this case,
you may want to check and disable checksum offload for the adapter, if
possible."

Mas detallado:

"tcp checksum offloading will not offer you very much performance wise
since it is so cheap to calculate it with the CPU. tcp checksum
offloading is dangerous for data however since it means that you will
send your packets across the least reliable component of your computer
(the pci bus) and without tcp checksum calculated by the stack you
will not detect bits being flipped/corrupted by the pci bus and thus
data might be corrupted. tcp checksum offloading is not as good as it
initially might be thought."