KINDNS: ICANN reconoce a GIGAIPNET en su programa global de buenas prácticas DNS
Resumen: ICANN nos ha incorporado oficialmente al programa KINDNS como Shared Private Resolver Operator. Te explicamos qué es esta iniciativa, por qué la seguridad operativa del DNS rara vez aparece en una propuesta comercial pero define la calidad real de un proveedor, y qué cambia para los servicios que entregamos desde Ecuador.
El DNS: la pieza invisible que sostiene cada conexión
Cada vez que escribes una dirección en tu navegador, abres una aplicación o envías un correo, el sistema de nombres de dominio (DNS) traduce ese nombre legible en una dirección IP. Es uno de los componentes más críticos de internet y, precisamente por eso, uno de los blancos preferidos de actores maliciosos: envenenamiento de caché, secuestro de zonas, ataques de amplificación, suplantación de resolvers, exfiltración mediante túneles DNS.
Históricamente, las prácticas para operar DNS de forma segura han estado documentadas en RFCs dispersos, papers académicos y guías informales que circulan entre los grandes operadores. El resultado: enorme variabilidad en cómo las empresas configuran sus resolvers y servidores autoritativos. Algunos lo hacen ejemplarmente; muchos, no.
Esa heterogeneidad es un problema sistémico, porque la seguridad del DNS es tan fuerte como su eslabón más débil.
Qué es KINDNS
KINDNS (Knowledge-Sharing and Instantiating Norms for DNS and Naming Security) es una iniciativa lanzada por ICANN en septiembre de 2022. Su propósito es consolidar en un marco simple y accionable las prácticas operativas más importantes para la seguridad del DNS, y promover su adopción voluntaria por parte de operadores de todos los tamaños.
A diferencia de una certificación tradicional basada en auditorías externas, KINDNS opera como un compromiso público verificable: el operador realiza una autoevaluación contra los estándares definidos mediante la herramienta oficial y, una vez completada, queda registrado en el listado público de participantes en kindns.org/participants.
El programa organiza a los operadores DNS en dos grandes familias, con subcategorías que tienen su propio conjunto de prácticas:
- Authoritative Server Operators, divididos en TLDs & Critical Zones (operadores de dominios de nivel superior como
.com,.orgo.ec) y Other SLD Zones (los nameservers que sirven los dominios de empresas y particulares). - Recursive Server Operators, divididos en Private Resolvers (resolvers internos de una sola organización), Shared Private Resolvers (resolvers privados compartidos por múltiples clientes, típicos de ISPs, proveedores de hosting y cloud providers) y Public Resolvers (resolvers públicos accesibles desde internet, como 1.1.1.1 o 8.8.8.8).
A estos se suma un conjunto transversal de prácticas de Platform Hardening que aplican a la plataforma sobre la que corre cualquier servicio DNS.
Nuestra incorporación: Shared Private Resolver Operator
GIGAIPNET ha sido reconocida oficialmente en la categoría Shared Private Resolver Operator, que cubre los resolvers DNS que operamos para los clientes de Telecu Cloud (hosting compartido, reventa, servidores cloud, dedicados y nube privada). Estos resolvers no están abiertos al internet público, pero atienden cientos de zonas y un volumen significativo de consultas por segundo en nombre de nuestra base de clientes.
Para esta categoría, KINDNS define siete prácticas concretas que el operador debe verificar y documentar:
1. Validación DNSSEC
DNSSEC debe estar habilitado en los resolvers recursivos, de modo que cualquier respuesta firmada sea validada criptográficamente y se descarten las que hayan sido manipuladas en tránsito. Es la línea de defensa más directa contra envenenamiento de caché.
2. Listas de control de acceso (ACL)
El servicio recursivo debe estar restringido por ACL únicamente a los rangos IP de clientes autorizados. Un resolver privado nunca debe aceptar consultas recursivas desde internet abierto, no solo por seguridad, sino para no convertirse en vector de ataques de amplificación.
3. QNAME Minimization
Las consultas a los servidores autoritativos deben enviarse con el nombre mínimo necesario en cada paso de la resolución, en lugar del FQDN completo. Es una mejora de privacidad: limita cuánta información se filtra a operadores de servidores intermedios sobre lo que está consultando el usuario final.
4. Separación entre autoritativo y recursivo
El servicio autoritativo y el recursivo no deben coexistir en el mismo servidor. Mezclarlos amplía la superficie de ataque y abre escenarios donde un resolver recursivo termina sirviendo datos cacheados como si fueran autoritativos. Es una práctica básica que sigue siendo violada con sorprendente frecuencia en la región.
5. Despliegue resiliente
El servicio recursivo debe operar sobre al menos dos servidores distintos, considerando la diversidad como mecanismo de resiliencia. KINDNS lista como ejemplos válidos correr software de distintos proveedores, ubicar resolvers en redes y Autonomous Systems diferentes, distribuirlos geográficamente o complementarlos con un resolver alterno operado por un tercero. En nuestro caso, los resolvers están distribuidos entre nodos diferentes con rutas de red independientes.
6. Monitoreo de la infraestructura
Los servicios, servidores y equipamiento de red que componen la infraestructura DNS deben tener monitoreo continuo: latencia, tasa de respuesta, salud de procesos, alertas tempranas. Sin monitoreo no hay forma de detectar un degrado o un ataque a tiempo.
7. Transporte cifrado (recomendado)
DoT (DNS-over-TLS) o DoH (DNS-over-HTTPS) debería estar disponible para proteger las consultas frente a interceptación o manipulación entre el cliente y el resolver. Es la única práctica del set marcada como recomendada y no obligatoria, y la tenemos implementada en nuestros resolvers.
Ninguna de estas prácticas es exótica para un operador serio. El valor de KINDNS está precisamente en eso: convertir lo que debería ser sentido común en un compromiso verificable, público y sostenido en el tiempo.
Qué cambia para nuestros clientes
A nivel funcional, el servicio se ve igual. A nivel de garantías, hay tres diferencias concretas:
Validación externa. Cualquier cliente, auditor o tercero puede verificar nuestra membresía directamente en el listado oficial de ICANN. Es trazabilidad pública de algo que normalmente queda escondido en documentos internos del proveedor.
Compromiso de continuidad. Mantener la membresía exige sostener las prácticas en el tiempo, no solo cumplirlas el día de la solicitud. Hay un mecanismo de revisión periódica que obliga a no relajar el rigor.
Alineación con estándares globales. Para clientes con requisitos de cumplimiento normativo, procesos de due diligence sobre proveedores, o exposición a mercados internacionales, esto se suma a la documentación que pueden presentar a sus propios auditores y clientes.
Lo que viene: Authoritative Server Operators – Other SLD Zones
En paralelo a la categoría que ya completamos, hemos presentado una segunda aplicación para la categoría Authoritative Server Operators – Other SLD Zones, que cubre la operación de los servidores autoritativos para los dominios de nuestros clientes (los nameservers que sirven las zonas DNS de cada sitio que alojamos).
Esta categoría define seis prácticas obligatorias:
- Firma DNSSEC de las zonas autoritativas y gestión adecuada de claves criptográficas.
- Restricción de transferencias de zona mediante ACLs y autenticación TSIG, para evitar que un tercero pueda obtener una copia completa de las zonas.
- Control de integridad del archivo de zona para detectar modificaciones inesperadas (maliciosas o accidentales), por ejemplo mediante ZONEMD (RFC 8976) o procedimientos de control de versiones.
- Separación entre el rol autoritativo y el rol recursivo, sin coexistencia en un mismo servidor.
- Mínimo de dos nameservers distintos por zona, con diversidad operativa y geográfica (red/AS y ubicación física).
- Monitoreo activo de toda la infraestructura DNS, servidores y equipamiento de red.
La revisión por parte de ICANN está en curso y esperamos comunicar el resultado en los próximos meses, cerrando así la cobertura KINDNS de las dos funciones DNS principales que operamos.
Por qué importa hacer esto desde Ecuador
La conversación regional sobre infraestructura digital tiende a quedarse en métricas comerciales: precio por GB, latencia al CDN más cercano, uptime declarado. La capa de seguridad operativa del DNS rara vez aparece en una propuesta comercial, pero es exactamente el tipo de detalle que distingue a un operador maduro de uno improvisado.
Que un proveedor latinoamericano figure en el listado oficial de KINDNS, junto a operadores de Norteamérica, Europa y Asia, es en sí mismo una declaración: la infraestructura crítica de internet también puede operarse con rigor desde esta región, y los clientes que confían en proveedores locales no deberían tener que aceptar estándares más bajos a cambio.
KINDNS es voluntario. Esa es, paradójicamente, su fuerza: separa a los operadores que están dispuestos a someter sus prácticas al escrutinio público de aquellos que prefieren no hacerlo.
Recursos para profundizar:
- Programa KINDNS: kindns.org
- Prácticas para Shared Private Resolvers: kindns.org/shared-private-resolvers
- Listado oficial de participantes: kindns.org/participants
- Guías y prácticas por categoría: icann-community.atlassian.net/wiki/spaces/KINDNS
¿Tienes preguntas sobre cómo opera nuestro DNS, o requisitos de cumplimiento que necesitas validar con tu proveedor de infraestructura? Conversemos.