Here's an article I wrote some months ago, about a DNS phenomenon we've seen in the wild since we start using IPv6 connectivity. The study was presented in last LACNIC meeting in Buenos Aires, Argentina. Here's the video of the talk (in spanish)
And here's the article with more detailed analysis:
In a previous post I wrote about my experience setting up a DNS signed zone using OpenDNSSEC with an USB "Aladdin eToken Pro 64k" HSM.
This time I run some tests in the eToken to try the storage capacity with keys.
Executive summary: 21 keys of 2048 bits, or 25 keys of 1024 bits.
The eToken can be formatted with a special option "Load 2048-bit RSA key support" (in Advanced Settings while initializing eToken). But also you need to manually set the number of reserved RSA keys in the same option screen, with a number more than 21 of 2048-bit keys (otherwise it only allows you to create 4 keys!)
With this options, the eToken is created with 31,155 bytes of card free space, out of 65,536 bytes of total memory capacity. Every 2048 bit RSA key takes 1,352 bytes of capacity, giving a maximum of 21 keys.
The test suite that comes with OpenDNSSEC (ods-hsmutil) gives OK creating keys with 512, 768, 1024, 1536 and 2048 bits. All these keys works with RSA/SHA1 and RSA/SHA256 signatures, and the 1024, 1536 and 2048 keys also work with RSA/SHA512 signatures. The tests are also OK with random bits generation in 1024 bytes, 32-bit and 64-bit.
There's no support for 4096 bits keys.
If you format the eToken without 2048 bits support, you can create up to 25 keys, taking care of "manually reserve the number of keys" at initialization time.
(English translation from Spanish of a previous post)
There is an important news website in Chile that takes long to load on my browser. An analysis revealed there is a problem with the DNS records for IPv6.
The problem is the DNS servers for the domain of this website does not answer anything for an AAAA query (record type for IPv6 addresses), resulting in a "timeout" from customer's viewpoint. This is an incorrect behavior. If a zone doesn't have an AAAA record for a name, it must answer an empty response immediately (return code NOERROR, with answer count = 0). Or if it is an old name server, with no knowledge of AAAA records, with an RCODE indicating it doesn't understand the query. But in both cases is an immediate response, which allows to take proper action. This "no response" behavior may be caused by a firewall in front of the DNS servers that is allowing packets for certain known query types , and is discarding anything else, forbidding the name server from handling the query.
As a consequence of "chained timeouts" is that my browser takes FORTY-FIVE seconds to load the main page. This because I have IPv6 connectivity, so the browser sends both A and AAAA queries to my local resolver. Queries for A records respond immediately, but for AAAA times out after 5 seconds. The failed query is retried 3 times, making a total of 15 seconds only to resolve the name of the site. After that starts loading the page, which contains scripts in another web site from the same domain, again taking 15 seconds to resolve, and finally images on other subdomain, which adds the last 15 seconds.
The latter behavior could also be a browser error, which unnecessarily delays the display of a page with an image, but the scripts must be loaded before the rest.
Moreover, there is unfortunately a very short TTL, which requires a new query every 30 seconds, and even worse, one of the NS records in the zone has a private address, making 1 / 3 of the queries to fail.
The recommendation is to check all name servers about how they respond to AAAA queries, even if they don't have IPv6 connectivity, because customers connected via IPv6 will query for those records and they will perceive the site as slow or down.
Existe un sitio web de noticias importante en Chile que es muy lento de cargar en mi navegador. Un análisis reveló que hay un problema con los registros DNS para IPv6.
El problema es que los servidores DNS de los dominios de este sitio web no responden nada por una consulta de registro "AAAA" (que son las direcciones IPv6), resultando en un "timeout" del punto de vista del cliente. Este es un comportamiento incorrecto. Si las zonas no tienen registros AAAA, deberían enviar una respuesta vacía en forma inmediata (NOERROR, con answers=0). O por último si se trata de un servidor de nombres muy antiguo, que no tiene conocimiento de los AAAA, con un RCODE que indica que no entiende la consulta. Pero en ambos casos se trata de una respuesta inmediata, que permite tomar las acciones correspondientes. Este comportamiento de "no respuesta" puede deberse a un firewall en frente del DNS que está filtrando los paquetes con ciertas consultas "conocidas", y quizás descarta cualquier cosa que no entiende, sin permitir que sea el propio servidor de nombres el que lo haga.Producto de un "timeouts encadenados" es que en mi navegador el sitio demora CUARENTA Y CINCO segundos en cargar. Esto porque yo tengo conectividad IPv6, y entonces el navegador envía tanto consultas A como AAAA a su resolver local. Las consultas A responden de inmediato, pero las AAAA se cancelan a los 5 segundos al no obtener respuesta. Este comportamiento se repite 3 veces, con lo que da un total de 15 segundos solo en resolver el nombre principal del sitio. Luego de esto comienza la carga de la página, el que contiene scripts en otro sitio web del mismo dominio, que nuevamente demora 15 segundos en resolver, y finalmente imágenes en otro subdominio, que suma los últimos 15 segundos.Este último comportamiento podría tratarse además de un error del navegador, que demora innecesariamente el despliegue de una página por una imagen, pero los scripts deben ser cargados antes que el resto.A esto se suma lamentablemente un TTL muy pequeño del registro final, que obliga a una resolución nueva cada 30 segundos; y peor aún, uno de los NS para el balanceador de carga posee una dirección privada, con lo que 1/3 de las consultas falla.La recomendación es la revisión de todos los servidores de nombre en su comportamiento frente a consultas AAAA, incluso aunque aún no se utilicen servicios en IPv6, porque serán los clientes quienes lo comenzarán a utilizar, y enviarán consultas DNS por estos registros en todos los sitios web que visiten.Well, an ascii pie meanwhile.
I'm a fan of the DNSSEC blog of SURFNET, a non-profit 'task organisation' forming part of SURF, the Dutch higher education and research partnership for ICT-driven innovation.
From almost 5 months they're publishing in their blog all the steps they're taken in implementing DNSSEC in their networks, where they provide recursive DNS service to their clients. I think there's a lack of information yet for the validation side of the dnssec infraestructure, so blogs like this are much needed.
Some weeks ago they posted a quiz. A graph of the validation rate they were seeing in their resolvers. The curve shows a great drop in one week, and there was no clear reason for that. I realized that besides that drop, was a spike one month or so before. If you follow the curve was steadily growing, but in one month was a huge hill, and then it continues with the normal grow. So I thought that something had to be over counting in that weeks. I remembered that .SE and .GOV were in that weeks adding their keys to the root, and they had the keys also in the ITAR before, so in those weeks their keys were in both places at the same time. As surfnet are using the root and ISC's DLV as trust anchors (who use ITAR), so maybe the spike was for a double counting.
The theory sounded plausible, but there was a confirmation step with the people from Unbound (the server software they use), and it was confirmed. There's a double validation because the DLV lookups are done using recursion.
There was an attempt to give me a real pie, but sadly I couldn't find any store in my country who accepted orders from outside. But an ascii pie is enough and I'm happy to have helped the guys from surfnet!
I'm successfully signing my own domain name with DNSSEC for months. At first I started with manual signing with the Bind tools, then I tried the dnssec-tools software, and finally ended up with OpenDNSSEC; just for playing around for trying different tools. Maybe in a future post I could write a comparison between them.
Thanks to the integration of OpenDNSSEC with any PKCS-11 HSM, I tested with one I already had for digital certificates: an Aladdin USB eToken.
My domain name (vulcano.cl) is served by an external server which I don't have physical access (impossible to attach an HSM to it) and I don't manage (no trust to leave the keys in the server). That said, I'm using a local machine (my own laptop, actually) to do the signing, and then transfering automatically the signed zone to the primary dns server every time there's a resign.
