Temimbo'e

Cloudflare será el nuevo jefe de los dominios argentinos

Andres Vazquez — Mon, 12 Oct 2026 12:00:00 GMT

Informe de situación a la semana del 12 de octubre de 2026. Miramos los servidores de nombres (DNS) de los 531.224 dominios .ar que tienen DNS delegado y contamos quién los gestiona, semana a semana.

La noticia: Cloudflare está a punto de pasar a DonWeb como el proveedor que más dominios argentinos resuelve.

pp = puntos porcentuales de participación: cuánto del total gana o pierde cada proveedor.

Cloudflare duplicó sus dominios en diez meses

Desde fines de noviembre de 2025 Cloudflare pasó de 44.408 a 94.102 dominios .ar (+112%) y de 10,9% a 17,7% del total. En el mismo período DonWeb creció en cantidad (+21.464) pero perdió participación (de 20,3% a 19,7%).

De los 122.651 dominios netos que se sumaron en ese período, 4 de cada 10 eligieron Cloudflare.

La distancia hoy es de 10.354 dominios (1,95 puntos). En el último mes Cloudflare le descontó a DonWeb unos 1.800 dominios por semana. Si el ritmo sigue, el cruce sería hacia fines de noviembre de 2026.

DonWeb sigue siendo el número uno (en lo que importa para ellos)

Que Cloudflare pase a DonWeb en DNS no quiere decir que se quede con el negocio de los dominios argentinos:

Cloudflare no vende dominios .ar. Los dominios se registran en NIC Argentina, directamente o a través de proveedores como DonWeb. Después, el titular delega el DNS a Cloudflare.
DNS no es hosting. Muchos de esos 94.000 sitios siguen alojados en DonWeb, Hostinger u otro proveedor y usan Cloudflare adelante como DNS, CDN y certificado gratuito. Es coherente con lo que vimos en abril: el 21,5% de los sitios ya respondía con el encabezado server: cloudflare (Tecnología detrás de 600.000 dominios argentinos).
El plan gratuito es la puerta de entrada. DNS rápido, SSL y protección básica sin costo es una oferta difícil de igualar para un hosting local.

Entonces: DonWeb sigue siendo donde la gente compra y aloja, pero cada vez más dominios argentinos le entregan las llaves (quién responde por el dominio) a Cloudflare.

Lo que más nos llama la atención

Concentración. DonWeb y Cloudflare juntos ya resuelven el 37% de los dominios .ar, y los 10 primeros pasaron de 56% a 65% del total. Todos los demás proveedores juntos perdieron 8,4 puntos desde noviembre.

Además de Cloudflare: quiénes crecieron

Vercel se multiplicó por 5: de 2.503 a 13.180 dominios (+1,87 puntos) y ya es el quinto proveedor de DNS de los dominios .ar.
NS1, usado principalmente por Netlify, creció 4,5 veces: de 1.550 a 6.925 dominios (+0,92 puntos) y entró al top 10. NS1 (hoy de IBM) es el servicio sobre el que funciona Netlify DNS y también da DNS a otras empresas, pero en los dominios .ar casi todo es Netlify: en una muestra de 35 dominios con NS1 que responden, 33 estaban alojados en Netlify.
Hostinger sumó 13.936 dominios (+39%, +0,63 puntos) y se consolida tercero.
Amazon AWS sumó 9.946 (+34%, +0,22 puntos).

Vercel y Netlify son plataformas donde se despliegan sitios hechos con frameworks modernos: son proyectos que nacen en la nube y nunca pasan por un hosting tradicional. Junto con Cloudflare, se llevan más de la mitad del crecimiento del período (54%).

Quiénes perdieron

Casi todos los demás proveedores relevantes suman dominios, pero crecen menos que el mercado y pierden participación:

DonWeb es el que más puntos pierde (-0,65), aunque sumó 21.464 dominios (+26%).
Los hostings argentinos medianos retroceden: LatinCloud (-0,52), NutHost (-0,46), WNPower (-0,33) y Towebs (-0,32). Towebs es el único de ellos que además perdió dominios (de 5.171 a 5.030).
GoDaddy, Wiroos y Wix pierden entre 0,23 y 0,27 puntos cada uno.
En cantidad, la caída más fuerte entre los proveedores con más de 2.000 dominios es la de Mercado Libre: de 2.230 a 1.290 dominios (-42%).

Para tener perspectiva: en marzo de 2015 hicimos un relevamiento parecido (DNSs usados en Argentina). Cloudflare ya existía y tenía 918 dominios .ar, el 0,28% de los que tenían DNS. Hoy son más de 94.000.

Cómo medimos

No tenemos el 100% de los dominios argentinos. Relevamos la gran mayoría de los dominios .ar vigentes (NIC declaraba 697.130 en abril de 2026) y volvemos a consultar cada uno periódicamente, así que esto es una muestra muy amplia y representativa, no un censo exacto.
Para cada dominio .ar tomamos su primer servidor de nombres y lo asignamos a una empresa (por ejemplo, *.ns.cloudflare.com es Cloudflare). Los servidores que todavía no identificamos con ninguna empresa se suman en "Otros". Los datos salen de las lecturas whois de whoare.io.
Arrancamos en noviembre de 2025 a propósito: entre mediados de 2022 y septiembre de 2025 nuestras lecturas fueron irregulares, y las series de esos años no son comparables.

¿Tu dominio está en Cloudflare?

Todos los datos de Córdoba en un solo lugar (y sobre un CKAN diferente)

Andres Vazquez — Tue, 29 Sep 2026 12:00:00 GMT

Hay un portal nuevo de datos abiertos de Córdoba: cbadatos.com.ar. No es oficial, es una iniciativa personal. Reúne en un solo lugar lo que publican los portales de la provincia, de algunos municipios, de la Legislatura y de la UNC: hoy son 1.935 conjuntos de datos de once fuentes distintas. En este post van dos historias: cómo se juntaron tan rápido todos esos datos y el experimento técnico que corre por debajo, un CKAN que funciona sin Solr ni Redis.

Parte 1: todos los datos de Córdoba en un solo lugar

Harvesting: la parte fácil

CKAN tiene desde hace años un mecanismo para cosechar (harvest) datos de otros portales. Si el portal de origen también es CKAN, traer todo su catálogo es casi trivial: se configura la URL, se elige cada cuánto actualizar y listo. CKAN habla con CKAN a través de su API y trae datasets, recursos, organizaciones y metadatos.

Eso fue lo que pasó con los dos portales de la provincia que migramos este año, datosgestionabierta.cba.gov.ar y datosestadistica.cba.gov.ar (lo conté en este post), con el portal de datos abiertos de la UNC que también hicimos desde cero y con el portal de Río Tercero. Cuatro portales CKAN, más de mil conjuntos de datos, en muy poco tiempo. Es lo que pasa cuando los portales usan software libre y estándares abiertos: se pueden conectar entre ellos muy facilmente.

Le agregamos al cosechador de CKAN dos cosas que nos parecían importantes:

Copiar los archivos, no solo los enlaces. Cada archivo se descarga una vez, de a uno y con pausas para no molestar al portal de origen. Así el sitio sirve también como respaldo: si un dato desaparece del portal original, acá sigue.
Que cada dato diga de dónde viene. Cada conjunto de datos guarda el portal de origen, el enlace al original y la organización que lo produjo. Las organizaciones de cada portal quedan separadas para que no se mezclen datos de fuentes distintas.

Los portales que no son CKAN

La parte difícil fueron los que no usan CKAN. Para cada uno hubo que escribir un cosechador personalizado:

Gobierno Abierto de la Municipalidad de Córdoba (donde trabajé tres años): tiene una API abierta, así que fue de los más simples.
IDECOR - Mapas Córdoba, el geoportal de la provincia: dos catálogos JSON que hubo que cruzar por nombre de capa. Una capa es un conjunto de datos con su GeoJSON, su simbología, sus metadatos y sus servicios WMS/WFS.
Datos abiertos de Villa María: sin API, leyendo el sitemap y cada página HTML.
Portal de datos abiertos de la Legislatura: páginas de WordPress leídas por su API REST.
Transparencia de Río Cuarto, Transparencia de Villa Allende y el presupuesto de Bell Ville: cada uno con su propia forma de publicar documentos.

Todos se actualizan solos, la mayoría una vez por semana.

El gran portal que falta

Hay uno que todavía no está: el portal de transparencia de la Provincia de Córdoba, el que (entre otras cosas) publica cada comprobante de pago del Estado provincial. Es probablemente el conjunto de datos más valioso de la provincia y también el más difícil de usar. Tenemos esos datos disponible en un portal cerrado hecho con la Red Ruido, todavía no esta listo para compartir, lo conté en este post.

Por qué juntar todo

Los datos de Córdoba existen pero están distribuidos en muchos lugares distintos, cada uno con su buscador, su formato y su forma de organizar las cosas.

Tenerlos en un solo lugar cambia la pregunta: ya no es "¿dónde está este dato?" sino "¿qué hay sobre este tema?". Un buscador sobre todo, filtros por portal de origen, por organización, por formato, 166 grupos temáticos. Y una sola API para todo lo de la provincia, que es algo que ningún organismo por sí solo puede ofrecer.

Además todos los datos tabulares se cargan al datastore de CKAN, así que se pueden consultar por API, ver como tabla y filtrar sin descargar nada. Los datos geográficos de IDECOR (muchos, son 627 conjuntos de datos) se ven en un mapa.

Todo el código del portal es público: parripollo/ckanext-cordoba-portal. Ahí están los cosechadores de cada fuente, por si alguien quiere reutilizarlos en otro lado.

Parte 2: un CKAN sin Solr ni Redis

Si entrás a la página "Sobre este CKAN" vas a ver que este portal no corre sobre el CKAN oficial.

El problema

Un sitio CKAN son tres servicios: PostgreSQL para el catálogo, Apache Solr para las búsquedas y Redis para las tareas en segundo plano. Cada uno hay que instalarlo, monitorearlo y actualizarlo en sintonía con la versión de CKAN. Para un portal chico o mediano (que son casi todos) es mucha infraestructura alrededor de lo que al final es una aplicación Python sobre una base de datos.

Simplificar CKAN no es un problema nuevo, se ha discutido muchas veces pero el desafió es muy grande.

El experimento

Así que lo intentamos. La propuesta está documentada en ckan.cbadatos.com.ar y el código es público en parripollo/ckanito. La idea es que CKAN sea para los datos abiertos lo que Django es para las aplicaciones web: instalar, apuntar a una base de datos y correr.

En resumen:

La búsqueda (texto completo, facetas, filtros y orden) corre sobre el full text search de PostgreSQL.
Las tareas en segundo plano son filas en una tabla que los workers toman con SELECT ... FOR UPDATE SKIP LOCKED.
Las sesiones y un pequeño almacén clave/valor para extensiones también viven en PostgreSQL.
Cada una de esas piezas quedó detrás de una interfaz. Si alguien quiere volver a usar Solr o Redis (vade retro!) puede escribir su implementación en una extensión sin tocar el núcleo. Nosotros (?) solo hicimos la de PostgreSQL. Creo que el error original de CKAN no fue usar Solr y Redis sino hablar con ellos desde todos lados, sin un contrato que se pueda reemplazar.
La API pública, las interfaces de plugins y la línea de comandos son las mismas. Pasan todos los tests de CKAN (unos 3.500), los linters y la construcción de la documentación.
Las extensiones se probaron una por una. La mayoría funcionaron sin cambios o con cambios mínimos. Harvest y spatial necesitaron un backend nuevo.

Todos los cambios están juntos en un solo pull request contra un fork de CKAN, que existe solo para poder leer la diferencia: 107 archivos, unas 4.000 líneas agregadas y otras tantas borradas. La mayor parte de lo que se borra es Solr.

Hay mucho para seguir revisando. El trabajo fue mayormente hecho por IA (Claude, Fable 5). Nosotros dirigimos el trabajo y tomamos las decisiones. Claude (el modelo de Anthropic) hizo el trabajo técnico: leyó el código de CKAN, propuso alternativas, escribió el código, los tests y la documentación. parripollo es la cuenta de GitHub que le dimos para trabajar aislado. Los tests de CKAN fueron el árbitro en cada paso.

Trabajo con CKAN hace años. Aun así, no puedo decir que entiendo al 100% cada una de las miles de líneas que cambiaron. Puedo leerlas, puedo ver que los tests pasan, puedo ver dos portales funcionando con miles de datos reales. Pero no las escribí yo, y entender un cambio así de profundo en CKAN requiere mucho más que leerlo.

Y al mismo tiempo el resultado es real: un portal de datos que se instala con PostgreSQL y un par de comandos. Si esto funciona bien, levantar un portal de datos abiertos para un municipio chico, una universidad o una organización deja de requerir tres servicios y alguien que sepa mantenerlos.

¿Y ahora?

No tengo una respuesta y me gustaría dejar el debate abierto:

¿Tiene sentido proponer esto a la comunidad de CKAN? ¿Alguien va a querer revisar miles de líneas escritas mayormente por una IA?
¿Es razonable usarlo en portales de verdad? Hoy lo usa cbadatos, que es un experimento ciudadano. ¿Lo pondríamos en un portal de gobierno?
¿Quién lo mantiene? CKAN sigue avanzando y cada cambio del CKAN oficial hay que traerlo a esta versión.
¿Cuánto tengo que entender de un código para confiar en él? ¿Alcanza con los tests, con verlo funcionando, con que otras personas lo revisen?

Presupuesto Abierto: seis años de scraping y un portal para periodistas

Andres Vazquez — Sat, 05 Sep 2026 12:00:00 GMT

En mayo de 2020 consolidé una serie de scripts que venían procesando (desde hacía algunos años y con otros investigadores) la ejecución presupuestaria de la Provincia de Córdoba desde su portal de transparencia. Seis años después eso es FreeData: un portal con más de seis millones de comprobantes de pago, de 2016 a 2026, y más de medio millón de proveedores. Esta semana Ruido, la red de periodismo de investigación con la que trabajamos, lo presentó públicamente.

El origen del dato

La Provincia publica cada comprobante que paga. Eso es mucho más de lo que publica la mayoría de los gobiernos argentinos y es bueno reconocerlo. El problema es cómo: un portal donde para llegar a un comprobante hay que elegir el año, después la jurisdicción, después el programa, el subprograma, la partida, y recién ahí aparece una lista paginada de a diez. No hay descarga, no hay API, no hay forma de preguntar "cuánto cobró este CUIT".

Lo que hice fue recorrer ese árbol completo, año por año, nodo por nodo, guardando cada comprobante con sus items. Es scraping paciente: millones de pedidos durante alrededor de una decada, muchos reintentos y una base que crece de a poco. En 2026 la Provincia cambió el portal y hubo que reescribir todo el recolector contra la interfaz nueva.

El portal

Sobre esa base construimos desde cero una aplicación en Django con PostgreSQL. Lo principal:

Búsqueda por proveedor, CUIT, programa o partida, en toda la serie.
Montos originales y actualizados por inflación (gracias Sol Monoldo!), mes a mes, para que una compra de 2017 se pueda comparar con una de 2026.
Tiempos de cobro por proveedor: cuánto tarda el Estado en pagarle a cada uno.
Seguimiento: cualquier usuario puede seguir un proveedor y recibir avisos cuando aparecen comprobantes nuevos.
Notas de usuarios sobre proveedores, para que un periodista le ponga nombre conocido a una razón social.
Descarga en CSV de cualquier búsqueda, con los filtros aplicados.
Graficos, muchos gráficos por todos lados.
Descargas de CSV de tablas a la vista para seguir trabajando en la compu o cruzar datos por fuera.

Portal privado

Este es un portal cerrado. Se entra por invitación y con passkeys. Hoy lo usan periodistas y de a poco se va abriendo a investigadores y organizaciones.

¿Por qué?

La decisión de no abrirlo tiene varias razones (no necesariamente en este orden):

Alojar esta cantidad de datos y todas las posibilidad que da esta plataforma en un servidor require recursos que este proyecto no tiene. Nada de esto genera ingresos de ninguna forma lamentablemente. Hemos postulado a subsidios pero todavía no hemos tenido suerte. Acá podes donar a la Red Ruido
El trabajo realizado es muy grande, requiere validación que todo funcione como se espera. Estamos en etapa de pruebas.
Hay datos que consideramos que no es buena idea que sean públicos. Asumimos que los responsables de este portal son plenamente concientes de lo que publican pero aunque parezca extraño no coincidimos con semejante nivel de apertura. Sin dar ejemplos, hay datos que se refieren a situaciones personales de las personas que si bien como fondos publicos deben ser abiertos no es buena idea que se publiquen de forma indiscriminada. Por eso el portal es privado y con invitación a personas que lo van a usar responsablemente con fines perdiosticos y de investigación.
Porque si, porque despues de tanto trabajo esta bien ser discrecionales con el uso. Queremos que esto se use bien.

Algo de cocina

Django y PostgreSQL, sin frameworks de frontend. HTML plano y algo de JavaScript donde hace falta.
Dos servidores chicos: uno con un webserver y la aplicación detrás de Cloudflare y otro con la base de datos.
Cache, mucho cache en cada lugar que se pudo.
El recolector corre aparte: cada año tiene un porcentaje de cobertura que se controla con un informe de integridad para saber que falta
Autenticación con WebAuthn. Nadie tiene una contraseña que filtrar.
Respeto por el servidor del que obtenemos datos. Corremos muy lento, en general entre 20 y 40 requests por minuto.

Riesgos

En 2026 la Provincia cambió la interfaz gráfica y escondió muchos datos. Saco tambien las Agencias de Gobierno (Cultura, Deportes, etc). Muchos subprogramas ya no son visibles. ¿Que pasa si se apaga el portal? Esta plataforma puede seguir abierta aún si eso pasara y hoy mismo ya muestra más datos que el portal oficial por lo que se escodió en la última actualización.

Migrar dos portales de datos abiertos después de una década sin actualizar

Andres Vazquez — Tue, 25 Aug 2026 12:00:00 GMT

Terminamos la migración de los dos portales de datos abiertos de la Provincia de Córdoba: datosgestionabierta.cba.gov.ar y datosestadistica.cba.gov.ar. Fue un año de trabajo, desde agosto de 2025 hasta agosto de 2026. Lo cuento porque es el tipo de proyecto que casi nunca se cuenta: no hay nada nuevo para inaugurar, hay algo viejo que dejó de ser un riesgo.

El punto de partida

Los dos portales corrían sobre CKAN 2.6.2 con PostgreSQL 9.6, en servidores propios del gobierno. Esa versión de CKAN es de 2017. Nadie la había actualizado en casi diez años. Funcionaban pero cada día que pasaba la brecha con el CKAN actual se hacía más grande y el salto más caro.

Los que trabajamos con CKAN sabemos que una actualización de 2.6 a 2.11 no es una actualización menor. Cambió Python (de 2 a 3), cambió el framework web (de Pylons a Flask), cambió el esquema de la base y cambió la forma de escribir extensiones. Lo que había que hacer era construir portales nuevos y mover los datos.

Dos herramientas libres

Decidimos que todo lo que no fuera específico de Córdoba quedara publicado. Salieron dos repositorios:

ckan-to-aws despliega CKAN completo en AWS con Terraform y Docker: una tarea de ECS Fargate con CKAN, Solr y Redis, una base RDS PostgreSQL, imágenes en ECR, secretos en Secrets Manager y logs en CloudWatch. Un script, un .env y ya tenemos un CKAN andando.

ckan-migrator hace la migración a nivel base de datos. Levanta el dump viejo en un PostgreSQL 9.6 dockerizado, extrae cada tabla a CSV y JSON, y las inserta en el CKAN nuevo respetando el esquema actual. Datasets, recursos, organizaciones, grupos, usuarios y el historial de actividad. Los archivos subidos se mueven aparte.

Lo que sí es específico de Córdoba quedó en repositorios privados, uno por portal: una extensión para la interfaz de cada uno (los dos portales pertenecen a ministerios distintos y tienen identidad propia) y la configuración de cada ambiente. Cada equipo del gobierno tiene su repo y puede gestionar sus diferencias sin tocar la base común.

Lo que queda

Todo el proceso fue documentado exaustivamente para que cualquier equipo técnico pueda actualizar CKAN en el futuro sin depender de un proveedor externo. La migración de datos es reproducible y los portales pueden ser desplegados en cualquier nube o servidor propio.

Un portal de datos abiertos para la Universidad Nacional de Córdoba

Andres Vazquez — Tue, 02 Jun 2026 12:00:00 GMT

La Universidad Nacional de Córdoba tiene portal de datos abiertos: datosabiertos.unc.edu.ar. Lo hicimos desde cero sobre CKAN 2.11 y es de los trabajos que más disfruté en los últimos años, así que va un poco de detalle.

De dónde viene

La idea de un CKAN para universidades la venimos planeando desde 2019 con el equipo de la UNC. De aquella época quedaron en GitHub un cosechador para los sistemas SIU (los que usan casi todas las universidades públicas argentinas), una librería para sacar datos de ahí y otra para conectarse a la API de SIGEVA de CONICET. Eran experimentos. El portal de verdad arrancó a fines de 2024, cuando se redefinió mejor como extraer datos y publicar.

De donde vienen los datos?

La UNC hizo un gran trabajo sobre Apache Superset, que es la herramienta de visualización de datos que usan para sus tableros internos. La idea fue conectar CKAN con Superset y publicar como datasets lo que ya estaba en los tableros. Para eso hicimos la extensión ckanext-superset. No había otra extensión que hiciera esto asi que la dejamos abiertas para poder ser reutilizada por otros.

Qué quedó publicado

Todo lo que no es específico de la UNC vive en la organización UnCKAN en GitHub, pensando en que otra universidad pueda reutilizarlo:

ckanext-superset: conecta CKAN con Apache Superset para publicar como datasets lo que ya está en los tableros de la universidad.
ckanext-dbquery: consultas a la base desde el propio CKAN, para los administradores y solo para casos especiales. En muchos casos los administradores de CKAN no tienen acceso a la base de datos y esta extensión permite hacer consultas SQL desde la interfaz web.
ckanext-push-errors: cuando algo se rompe en producción, el error llega a Slack antes de que alguien lo reporte.
ckan-env: el entorno Docker completo para levantar el portal en cualquier máquina. Esto es solo para entorno de desarrollo local. Hay un repositorio privado con la configuración de producción que gestiona el equipo de la UNC.
ckanext-citeproc: hicimos un fork de esta extensión y la adaptamos para que funcione en nuestro caso. Esta extensión permite citar datasets en formato APA, Chicago y MLA.

Otras universidades

Todo esto fue hecho pensando que otras universidades puedan reutilizarlo. La idea es que cada universidad pueda tener su propio portal de datos abiertos, con su identidad y sus datasets, pero usando la misma base común. Solo sería necesario que cada universidad conecte una instancia de Apache Superset con sus propios datos (usalmente de los sistemas SIU) y haga una extension de interfaz gráfica adaptada a su caso. El resto es común y puede ser reutilizado tal cual.

Tecnología detrás de 600.000 dominios argentinos (2026)

Andres Vazquez — Sun, 10 May 2026 12:00:00 GMT

Originalmente publicado como hilo en Twitter.

Analizamos casi 600.000 dominios Argentinos. Intentamos hacer una peticion a la home page de cada uno. Conseguimos casi 400k respuestas (66%). Miramos tambien los encabezados de las respuestas y algunas partes del contenido HTML.

Analisis del header server. Si bien el servidor puede responder lo que quiera aquí, estos son nuestros resultados. 380k dominios devolvieron ese encabezado (casi todos). ¿Te sorprende ver a Apache todavía primero? En 2015 era 67% (nuestro análisis anterior).

La novedad es Cloudflare. Para sorpresa de nadie Microsoft IIS cae bruscamente. Nginx se mantiene.

Vamos al header X-Powered-By. La principal novedad aqui es que se esta dejando de usar. Solo 84k de los casi 400k de sitios que respondieron lo usan. Para sorpresa de nadie Mumm-Ra sigue vivo. ASP se desploma.

Vamos al HTML. Analizamos el meta generator. Hay que decir que el 68% de los sitios no lo declara. Son otras cosas. Solo 126k sitios usa algun generador de contenido. Aqui WP y sus amigos lideran. Sorprende que el Wordpress a secas no es el 1°.

Finalmente si los agrupamos podemos decir que el 82% de los sitios generados por algún CMS son Wordpress. Posiblemente PHP sigue vivo solo por esto. ¿Vos que pensas?

Registros MX en dominios .AR (2026)

Andres Vazquez — Wed, 29 Apr 2026 12:00:00 GMT

Originalmente publicado como hilo en Twitter.

¿A quién le delegan el correo los dominios argentinos? Para responderlo miramos los registros MX de DNS sobre nuestra base de dominiosAR.

De los ~585.000 dominios que tenemos relevados, 421.000 están delegados a algún DNS y 322.000 tienen al menos un registro MX. A marzo de 2026 NIC declara 692.000 dominios totales, así que la muestra es bastante representativa.

Casi el 60% de esos dominios con MX apunta a su propio dominio*. Cerca del 1% (unos 2.500) son inválidos: apuntan a localhost. Y a un 4,5% nuestra expresión regular no logró clasificarlo.

De los 115.000 dominios que apuntan explícitamente a proveedores externos, Google y Hostinger comparten el primer lugar con cerca del 70% del mercado entre los dos. ¿Se imaginaban a @Hostinger ahí, por encima de @Microsoft?

¿Y los sitios de gobierno (gov.ar + gob.ar)? El 64% apunta a dominio propio*.

De los 328 dominios de gobierno que sí declaran un proveedor externo, el principal —como suponíamos— es Microsoft.

* Con seguridad no existen tantos sitios que gestionen sus propios mails. Ese 60% seguramente esconde cosas por detrás. ¿Cuál te parece que sería la mejor estrategia para descubrir el proveedor real?

Nota extra. El uso de localhost como MX no es un descuido: es política de uno de los proveedores de hosting.

¿Qué más le preguntarían a estos datos?

Outliers en registros de dominios

Andres Vazquez — Sat, 25 Apr 2026 22:57:00 GMT

Originalmente publicado como hilo en Twitter.

Estos son los más de 500.000 dominios que seguimos (casi la totalidad existentes hoy) ordenados por fecha del próximo vencimiento. Cada barra es un día de año. ¿A alguien se le ocurre que es ese pico? ¿Se imaginan? Respuesta mañana.

Vamos con algunos sospechosos. En 2014 los dominios dejaron de ser gratis. Antes de eso uno podia registrar todos los dominios que queria y sin costo. Habia más de 2 millones de dominios registrados.

El último día y los anteriores fue un caos. Una hecatombe, una debacle total. Una seguidilla de hechos bochornosos donde la gente daba de baja sus dominios para volver a registrarlos y tener unos meses más sin pagar.

Nuestro primer sospechoso fue este. Imaginamos que esa distorción se había arrastrado hasta nuestros dias. Pero no fue así, eso fue un 5 de marzo y el día raro es el 15 de septiembre (además de algunas otros días).

Esos registros luego de este momento rateril de la historia de internet argentina cayeron mayormente al año siguente. Eso no explica el pico actual el 15 de septiembre. ¿Y entonces?

¿Fue algun registrante que hizo muchos registros ese día? Estos son la cantidad de dominios de ese día por registrante. Solo dos registrantes ese día hicieron más de 100 registros.

Uno de ellos fue Dattatec (que es el mayor registrante de dominios en Argentina) que en general registra año a nombre de terceros. Al otro registrante ya lo vamos a ver. El motivo no fue alguien entrandso bruscamente al mercado.

¿Y si vemos en que año se registraron? Estos son los dominios que vencen en septiembre de 2026 (cada día en eje Y) por el año en que fueron registrados Algo paso en 2019 y despues en 2020. Raro, ¿un evento bianual? ¿Ahora si te acordas?

Sigamos: Estos son los dominios que vencen el 15 de septiembre por zona La mayoría de los dominos en Argentina son .com.ar (el 80% aprox según https://nic.ar/es/dominios/estadisticas) Pero ese día la proporcion cambia rotundamente.

Claro! El nacimiento de los dominios .AR! Las fases de lanzamiento fueron:
1- Los que tenian un .com.ar podía reclamar el .ar (septiembre 2019)
2- La gente podía manifestar su interes en algun dominio.
3- Se analizaban y se asignaban esos dominio de interés (13 de mayo de 2020)
4- Se abrieron al público general el registro de dominios en la zona .AR

Quien fue ese gran registrante ese día? Fue Victor Ma, extranjero (basandonos en su CUIT) Victor sigue siendo hoy registrante. Aca podes ver más

¿Que pasó con esa camada de los nuevos .AR abiertos al público? Más del 80 renovo luego de 6 años, al parecer fue una buena idea. Había y sigue habiendo interés real en esos dominios.

CSVConf 2025 en Bologna — notas desde el evento

Andres Vazquez — Tue, 09 Sep 2025 08:11:18 GMT

Originalmente publicado como hilo en Twitter.

Estuve en Bologna, Italia, para CSVConf 2025. Estas son las notas que me llevé del evento.

This year we'll use 🤌separated values. We'll call it ISV (Italian emoji separated values). Excel won't get it anyway. #CSVConf

@jqnatividad proposes to upload data first allowing the CKAN Datapusher to infer the metadata and apply suggestions. It looks promising.

Someone says "Frontend developers" in a CKAN conference. That's new!

Can we remove Solr from CKAN? Cross your fingers.

CKAN 3.0.

Gestión de datos internos para que a la gente del gobierno/organización los datos le sean útiles en su trabajo diario. Eso va antes que los portales de datos abiertos. Coincido 100%.

Desde la @OKFN, @Sape_BY nos cuenta sobre el camino del "Open Data Editor", incluyendo los últimos grandes aportes de @colmanromi.

¡Hay gente criticando al hermoso formato CSV!

Mendiolaza — el padrón y el censo no pueden ser los dos correctos

Andres Vazquez — Fri, 09 Aug 2024 16:35:02 GMT

Originalmente publicado como hilo en Twitter.

Para algún periodista de Córdoba con curiosidad y tiempo para investigar un poco.

El último censo argentino dio para Mendiolaza (mi ciudad) 14.688 habitantes. El último padrón informa 14.302 electores. Esto es evidentemente inconsistente.

https://demendiolaza.ar/cuantos-somos-en-mendiolaza/

Los padrones no incluyen a los menores de 18 años (o 16, según el año). La pirámide de población de Córdoba nos dice que por lo menos hay un 30% de menores de edad que no están en el padrón.

Si Mendiolaza tiene ~14k habitantes, entonces debería tener ~9.800 electores en el padrón. Si son ~14k electores, entonces tiene ~18k habitantes. Las dos cifras no pueden ser correctas. O el padrón está mal y se agregó gente, o el censo contó de menos.

Como habitante de la zona tiendo a pensar que el censo se quedó corto. Los que vivimos por aquí suponemos que somos más.

Por otro lado hay una serie de experiencias personales que me hacen pensar distinto. He trabajado con padrones electorales casi todas las elecciones entre 2013 y 2019. No es trabajo superficial: he trabajado con los registros completos de los padrones electorales.

Recuerdo en 2015 hacer una comparativa uno a uno de todos los electores del padrón nacional (digitalizado) vs el municipal (entregado en papel en fotocopia de baja calidad). Fueron necesarios trabajos con OCR y la ayuda de amigos que me ayudaron a controlar uno por uno. Ni un error, nada. Nadie fue agregado al padrón de Mendiolaza.

Para los que no conozcan la ciudad, hemos tenido el mismo intendente desde 1999 hasta 2023 sin que hubiera claro ningún mérito aparente de la gestión de gobierno. Me permití suponer que algo pasaba. Pero no.

Otros trabajos que hice en varias ciudades fueron ver cuánta gente votaba en un mismo domicilio. Es un análisis muy interesante y surgen cosas curiosas de ahí. En mi caso me encontré con que en mi casa votaba una persona que yo conocía pero que vivía en un pueblo vecino.

Por otra parte, he sido presidente de mesa (postulándome cada vez que estuvo disponible) en casi todas las elecciones municipales. Me ha tocado ver novias y familiares de gente que conozco, que no vivía en la ciudad, votando. No miles, pero he visto a algunos.

Es conocido en la zona que mucha gente viene a sacar su carnet de conducir a este pueblo porque el precio y la burocracia es mucho menor que la ciudad capital, muy cerca de aquí. Es posible que algunas personas consignen su domicilio aquí para acudir a ese servicio. No creo que sea algo azaroso. No puedo decir mucho más porque no tengo evidencia, pero es posible que algunas de esas personas sean acompañadas a votar en cada elección.

Por último, en 2019 en lugar de ser presidente de mesa decidimos con un amigo hacer un boca de urna junto a uno de los candidatos que contaba con un equipo para poner en el campo. Fue una muy linda experiencia.

Solo con una planilla de Google Drive que ya tenía decenas de gráficos precargados fue suficiente. El equipo en la zona de la elección usaba el formulario para cargar cada respuesta y nosotros podíamos ver en tiempo real los resultados.

Ese día los resultados estaban claros a la mañana: el candidato histórico perdía por al menos 5 puntos. Luego del mediodía y a medida que avanzaba la tarde los resultados empezaron a cambiar de dirección. Finalmente el candidato de siempre ganó. Los electores de la mañana, al parecer, votaron distinto a los de la tarde. No tengo dudas de que se agregaron personas que no vivían al padrón; pero no estoy seguro del tamaño de eso.

Algunos datos más: en el censo anterior la población de la ciudad fue de 10.317 habitantes y en las elecciones de 2011 había 5.487 electores.