tinydns por dominios

  • english
  • spanish

It’s no secret that I really like DJB‘s software. I think that qmail and djbdns are rock-solid pieces of software, something you can really rely on. But some people just don’t get them and bash them for whatever reasons.

Case in point, djbdns. Many a time I’ve heard the argument that having all tinydns’ domains in a single data file is a PITA. Well, that proves those people don’t get the point in DJB configuration files: you can edit them by hand, but their real power is that they’re easily scriptable! You don’t want having all the domains in a single file? Ok, split them and join them before compiling!

You can do this with the following makefile: split the domains, one per file on the “domains” directory, and work with those files, don’t ever touch the original “data” file again. And if you have a backup server put it’s IP address or FQDN on an env/BACKUP file. Then when you run “make” it will join all the files, compile them and sync the results with the backup server. Easy as pie, don’t you think?

all: data.cdb data: domains/*[^bB][^aA][^kK~] cat $+ > data data.cdb: data /usr/bin/tinydns-data [ -f ../env/BACKUP ] && rsync -azv * root@`cat ../env/BACKUP`:`pwd` clean: -rm -f *~ domains/*~

Google, reinventando Internet III: el DNS

Después de dar alternativas a los protocolos SMTP (Wave) y HTTP (SPDY), le ha tocado el turno al otro caballo de batalla de Internet: el DNS. Mucha gente no le da a este protocolo la importancia que se merece, pero muchas páginas que tienen problemas de rendimiento son por culpa de una mala gestión del DNS, suya o del dominio de algún elemento que tengan en la página (publicidad sobre todo).

Google ha anunciado en su blog oficial la disponibilidad de su nuevo servidor de DNS público. Esta vez no han inventado un nuevo protocolo, simplemente han añadido a su servidor una serie de optimizaciones como gestión compartida de caché entre todo el cluster (que a saber lo grande que es, con lo que va a estar cacheado ¿todo?) y pre-fetching, amén de unas cuantas medidas de seguridad para prevenir ataques DoS y de envenenamiento de cachés.

Esta vez no hay código, parece ser que esto es sólo un servicio gestionado. Las IPs de los DNS de Google son:

  • 8.8.8.8
  • 8.8.4.4

Puede ser una buena alternativa al DNS de tu ISP (la mitad hacen aguas) o a OpenDNS, que se granjeó bastantes enemistades cuando empezaron a redirigir el tráfico de dominios que no existían (y curiosamente, el de Google también) a páginas suyas. Por supuesto, esto va a levantar otra oleada de opiniones anti-Gran-Google-Hermano: si usas el servidor de DNS de Google, van a saber todos los dominios que visites. No cada página individual, pero si cada dominio. Y es que como (¿casi?) todo lo que hace Google, parece que tiene la doble intención de conseguir más y más información sobre los hábitos de los usuarios en Internet para afinar aún más su maquinaria de AdWords/AdSense.

Grave problema de seguridad en el protocolo DNS

¡¡Qué bien que a mis servidores no les afecta porque uso djbdns!! :-P

Luego en el trabajo me preguntan si me llevo comisión por estar siempre cantando las alabanzas del djbdns y el qmail, pero coño… años usándolos, cero incidencias, cero problemas de seguridad. Comparad con sendmail y bind…

Más info:

Back $HOME

Ayer volví a casa después de unos días moviditos:

  • miércoles y jueves de viaje de trabajo a Caen, una ciudad al norte de Francia. El viaje bien pero cansado, al no haber vuelo directo hicimos escala en París y luego cogimos un tren (2h) hasta Caen, con lo que nos tiramos más tiempo entre avión y tren que trabajando realmente. Al menos la cosa fue bien, pero me hubiera gustado poder tener algo de tiempo entre tren y tren para ver un poco la ciudad.
  • el viernes de cabeza en el trabajo, líos de última hora. Tenía que haber salido a las 14 y acabé saliendo a las 18:20 o por ahí…
  • …lo que me desbarató los planes de salir tranquilamente para Alicante a las 14 y llegar a media tarde. Acabé llegando sobre las 22, y con las obras del Tram quitando plazas de aparcamiento no conseguí aparcar y llegar a casa hasta casi las 23 (no exagero).

El fin de semana en Alicante de cabeza: sábado por la mañana en Alcoy visitando gente y acabando de recoger cosas en el piso de allí, sábado por la tarde visitando a la familia en Alicante, cena con un colega del instituto que hacía un siglo que no veía, y por la noche de copas con unos compañeros del antiguo trabajo. Y el domingo buceo en La Llosa con el agua a unos soportables 15ºC, comida con mi padre y vuelta para Madrid. No he podido ver a toda la gente que me hubiera gustado (perder la tarde del viernes me hizo polvo) pero el fin de semana ha estado muy bien, he vuelto con las pilas cargadas, que me hacía falta. :) Eso si, hoy me he levantado otra vez con dolor de espalda igual que hace unas semanas. No tanto, la verdad, pero vaya, una molestia constante. Tantas horas de coche, cargar maletas de un sitio a otro y casi una hora bajo el agua bastante fresquita no le han sentado bien a mis riñones. :-/

Y para acabar de arreglarlo, hoy me entero que durante el fin de semana hubo un problema con los DNS de la tienda y éste blog. Ya debería estar resuelto, aunque puede que algún DNS de algún ISP hubiera cacheado la respuesta de error y hasta dentro de unas horas (¿días?) algún servicio no esté visible. :(

¿Por qué interfaz de red sale el tráfico UDP?

  • english
  • spanish

It has happened to me a cuple of times when dealing with UDP-based services that, when a server has more than one network interface (either physical or virtual), all the UDP traffic goes out through the interface on the default gateway’s network segment and with that interface’s IP address, even when the original request came through the other interface and was directed to the other IP address.

Graphically, say you have something similar to this:

esquemaredudp.png

If the server receives a request on IPa, the response goes out through that same interface and with origin IPa. But if the request arrives on IPb through the interface on the right, the response is also sent through the left interface with IPa. And what happens when the client receives a response from an incorrect IP address? Maybe even from a completely different network segment? And if there’s a fw in between doing NAT?

Of course this breaks the service. This week I’ve had this very problem setting up a L2TP VPN, and it was impossible to establish the tunnel. On some other ocasions I’ve had a similar problem with a DNS server, and the outcome depended on the client’s operating system: some OSes accepted the DNS response even when it came from a different address than that of the server originally queried; others would reject it and even raise a security alert.

I guess that this behaviour can be programmatically controlled. I mean, when you receive a packet you can check the IP address it was sent to, and craft the response so that it gets sent with that same address from the right interface. But it seems that this is seldom done.

Yesterday I got around this issue with the help of iptables and a coworker more knowledgeable than me on routing issues:

  • with iptables, you can detect the traffic to “redirect” and mark it
  • depending on this mark and using “ip rule/route”, have a special routing table that sends this traffic to the proper GW/through the right interface.
  • with iptables again and using the previous mark, do a SNAT on the origin IP address

An example for redirecting all UDP traffic from a certain $PORT using IP address $IPb through gateway $GWb would be:

echo 255 local > /etc/iproute2/rt_tables
echo 254 main >> /etc/iproute2/rt_tables
echo 253 default >> /etc/iproute2/rt_tables
echo 0 unspec >> /etc/iproute2/rt_tables
echo 200 udp >> /etc/iproute2/rt_tables
ip rule add fwmark 1 table udp
ip route add default via $GWb dev eth0 table l2tp
iptables -t mangle -A OUTPUT -p udp -m udp –sport $PORT -j MARK –set-mark 0×1
iptables -t nat -A POSTROUTING -m mark –mark 0×1 -j SNAT –to-source $IPb