Dominio principal
DNS
En la faceta Dominio principal, los análisis de DNS se agrupan por dominio principal para que los lectores puedan seguir un área concreta de la infraestructura de Internet, la gobernanza, los mercados de conectividad o el capital digital. La página reúne artículos relacionados, evidencia pública, instituciones, empresas, personas, exposición regional, dependencias operativas y contexto de mercado que de otro modo aparecerían en páginas de categoría separadas. Explica el dominio, la clase probable de actor, el contexto de mercado o de gobernanza y el material de origen que los lectores deben usar al comparar señales. Operadores, analistas y lectores de gobernanza pueden ver cómo el mismo dominio aparece en eventos, perfiles, cambios de mercado, evidencia de fuentes públicas, dependencias regionales y decisiones de infraestructura de ciclos más largos a lo largo del tiempo.
IETF
El registro asignó un número; el resolutor todavía decide
RFC 9563 incorpora firmas SM2 y resúmenes SM3 al vocabulario de DNSSEC. La asignación evita ambigüedades en el protocolo, pero no acredita consenso del IETF, idoneidad criptográfica, soporte efectivo ni una respuesta autenticada.
IETF
El servidor de respaldo respondió. La clave en caché no encajó: RFC 8901
Un segundo proveedor de DNS autoritativo puede seguir respondiendo cuando falla el primero y aun así no ofrecer una respuesta aceptable para un resolutor validador. RFC 8901 convierte la redundancia DNSSEC en un contrato de sincronización entre firmantes, no en un recuento de…
Historia de Internet
Gihan Dias y el paso de Sri Lanka del enlace al nombre
Antes de que una red pueda sentirse propia, no basta con que transporte paquetes. La historia de Gihan Dias conduce desde el correo que viajaba por llamadas breves hasta una pregunta más política y más íntima: ¿con qué escritura puede un país nombrarse en la raíz de Internet?
Expediente
Cuando el parche no demuestra la reparación: la cadena de riesgo de BIND ante KeyTrap y la recursión excesiva
Las vulnerabilidades de un resolvedor DNS rara vez terminan cuando aparece una versión corregida. En BIND, una entrada especialmente construida puede convertir el procesamiento normal de consultas en un problema de disponibilidad: la recursión excesiva puede agotar recursos de…
IETF
James Gould y la señal de ocultación que no demuestra la política
Una respuesta RDAP puede no mostrar un dato por razones opuestas: porque el dato no existe o porque existe y el servidor no lo entrega a ese cliente. Para una pantalla ambos casos parecen un hueco. La RFC 9537, coescrita por James Gould, permite que el servidor describa uno de…
Expediente
Cuánta discreción cabe en un dominio interno
Una empresa puede demostrar que autorizó una excepción DNS sin publicar los nombres privados que contiene. RFC 9704 separa esas dos necesidades, pero deja decisiones importantes a los operadores: qué identidad hacer visible, qué ámbito delegar y cómo renovar el acuerdo.
IETF
Suzanne Woolf y la etiqueta de servidor que no identifica una máquina
Un servidor DNS puede adjuntar un identificador a su respuesta, pero la palabra «identificador» promete más de lo que el paquete demuestra. En una red con anycast, balanceadores y valores elegidos por el operador, la etiqueta solo adquiere significado cuando se conserva su…
IETF
Sara Dickinson y la promesa del resolutor que el cifrado no puede demostrar
Una consulta DNS cifrada cruza la red como una carta dentro de un sobre opaco, pero alguien tiene que abrirla para contestar. El RFC 8932, firmado entre otros por Sara Dickinson, obliga a mirar precisamente a quien abre ese sobre: qué anota, durante cuánto tiempo, con quién lo…
ICANN
Allison Mankin y la muestra de colisión de nombres que no demostraba su causa
Un mapa de calor puede mostrar miles de consultas hacia la raíz y, aun así, no revelar qué programa las originó ni qué se rompería si cambiara la respuesta. El informe RFC 8023, firmado también por Allison Mankin, convierte esa diferencia en una regla de trabajo: medir no…
Expediente
La clave constaba, pero aún no era confiable
Un mensaje puede demostrar que su emisor posee una clave privada y, al mismo tiempo, no demostrar que deba controlar una delegación. Esa diferencia aparece con nitidez en la propuesta que DNSOP llevó a última llamada hasta el 7 de septiembre: el punto crítico no es recibir un DNS…
Expediente
El punto final movió la frontera de confianza
Para el DNS, `example.co.uk` y `example.co.uk.` pueden conducir al mismo nodo. Para una aplicación, las dos grafías pueden activar decisiones de seguridad distintas. Cuando DNSOP cierra el 7 de septiembre su última llamada de grupo sobre la integración de nombres, una…
IETF
La minimización de QNAME es un contrato de secuencia, no un interruptor de privacidad
Un resolvedor puede indicar que minimiza QNAME y, sin embargo, revelar nombres, costes y fallos distintos según su caché. La evidencia no es una casilla binaria: es la secuencia acotada que producen las delegaciones conocidas, las respuestas negativas y los fallbacks.
Expediente
DNS recibió el aviso. El padre aún tenía que decidir: el límite de delegación de RFC 9859
RFC 9859 hace más rápida una comprobación de mantenimiento de delegación. No convierte un aviso en una decisión del lado padre ni una respuesta DNS en prueba de un cambio publicado.