Tema
Poder de delegación del DNS
Dentro de la faceta Tema, la inteligencia temática Poder de delegación del DNS conecta artículos que comparten un tema específico, un enfoque en señales o una temática de seguimiento. La página ofrece a los lectores un recorrido más completo a través de informes relacionados, evidencia de fuentes, actores del mercado e implicaciones de infraestructura, con el contexto suficiente para entender por qué el tema es relevante en los movimientos corporativos, las decisiones de gobernanza, la exposición regional y el riesgo operativo. Los lectores pueden comparar señales recurrentes, organizaciones implicadas, evidencia pública, contexto de mercado, continuidad del servicio, contratación, competencia, cumplimiento y cuestiones de planificación estratégica que subyacen al tema, en lugar de quedarse en una lista escueta de artículos relacionados. Explica de qué trata el tema, qué actores o políticas de infraestructura están implicados, qué evidencia respalda la cobertura y por qué puede ser relevante para operadores, clientes, inversores y lectores interesados en las políticas.
IETF
Wes Hardaker y el servidor DNS que tuvo que sobrevivir a dos TTL
El error no estaba en la nueva configuración. Estaba en declarar muerto al servidor anterior mientras una parte de Internet todavía conservaba una indicación válida para encontrarlo.
Historia de Internet
El nombre era local. El número aún necesitaba un registro: el límite de mapeo DNS de la RFC 1101
En 1989 el DNS ya distribuía nombres de host, pero todavía no ofrecía una forma normalizada de preguntar cómo se llamaba una red a partir de su número. La RFC 1101 propuso usar PTR, nombres de host cero en `IN-ADDR.ARPA` y máscaras para resolver esa ausencia. La lección no es que…
IETF
Tobias Fiebig y los cuatro comprobantes de alcance del DNS
Dos equipos pueden presentar informes correctos y llegar a una conclusión equivocada. El equipo de dominios muestra NS, A, AAAA y glue publicados. El equipo de red enseña una consulta que terminó con éxito. Ninguno ha demostrado todavía que dos servicios autoritativos respondan…
Historia de Internet
El servicio de nombres casi fue un negociador: cómo RFC 830 separó dominios y capacidades
Una consulta de RFC 830 podía recibir dos respuestas en momentos distintos. La primera conducía al punto de servicio del dominio de destino. La segunda decía si allí existía el transporte y la aplicación solicitados, o proponía una alternativa. Entre ambas quedaba una frontera…
IETF
David Lawrence y la respuesta DNS que siguió viva tras su TTL
Que una respuesta DNS haya caducado no obliga a fingir que ya no existe, pero tampoco permite tratarla como vigente. RFC 8767 abre un puente de continuidad: el resolvedor intenta llegar a la fuente autoritativa, clasifica el fallo, usa durante poco tiempo la copia antigua y sigue…
IETF
Steve Sheng y el bloqueo que no detuvo el mantenimiento DNSSEC
El panel puede mostrar un dominio bloqueado y, aun así, el padre publicar un DS nuevo de forma legítima. RFC 10026 explica por qué: el bloqueo pertenece a un actor y a una clase de órdenes; no congela por definición todos los caminos de mantenimiento.
IETF
Peter Thomassen y la actualización que necesitaba cada servidor autoritativo
La decisión más importante del RFC 9975 no es qué dato publicar, sino cuándo negarse a publicar cualquiera. Peter Thomassen convierte el desacuerdo entre servidores autoritativos en una regla operativa: el estado del padre permanece intacto hasta que el servicio delegado hable de…
Expediente
El DNS abrió la negociación, pero no podía firmar la venta
RFC 10023 permite anunciar que un dominio registrado está disponible sin apagarlo. La señal reduce el coste de encontrar a un posible vendedor; no demuestra quién puede obligarlo, qué se vende ni si la operación llegó a buen término.
Expediente
El dominio no había caído; la ruta de autoridad sí: RFC 10001 y el diagnóstico DNS por familia
Dos equipos miran el mismo incidente. El primero consulta desde una red de doble pila y obtiene respuesta. El segundo reproduce el fallo desde una red sólo IPv6 y no llega al servidor autoritativo. Ambos dicen que comprobaron “el DNS”. RFC 10001 demuestra por qué esa frase borra…
Expediente
Llegó una sola respuesta, pero faltaba un tipo: RFC 10029 y la autoridad de la evidencia DNS
Una aplicación móvil celebra haber reducido tres consultas a un paquete. Recibe A y AAAA, no ve HTTPS y continúa como si el conjunto estuviera completo. RFC 10029 obliga a leer otro dato antes de actuar: la lista de tipos terminados. La eficiencia sólo es correcta cuando la…
Expediente
El registro publicó el TTL. El resolvedor siguió con su reloj: RFC 10037 y la autoridad sobre una ventana DNS
Los 300 segundos no empiezan cuando alguien pulsa «guardar». El registro puede aceptar el nuevo TTL y mostrarlo en RDAP, mientras una zona aún distribuye el valor anterior y miles de resolvedores conservan copias obtenidas en momentos distintos. RFC 10037 hace visible una pieza…
Expediente
El error volvió como una nueva pregunta: DNS Report-Channel y la autoridad de la señal
El servidor autoritativo puede entregar una zona cuya firma ya no convence al validador y, aun así, no ver ninguna alarma en su lado. DNS Error Reporting abre un camino de regreso: el servidor anuncia un agente, el resolutor decide si diagnostica y comunica, y una segunda…
Expediente
El paquete ocultó su longitud exacta, pero el patrón siguió hablando: EDNS Padding y los límites de la privacidad DNS
Una consulta DNS cifrada puede mantener en secreto el nombre y conservar, al mismo tiempo, una silueta reconocible. EDNS Padding altera esa silueta añadiendo bytes. Su valor no se mide por cuánto creció un paquete, sino por cuántos intercambios distintos acabaron pareciéndose…
Expediente
La zona ofreció rutas; el cliente decidió la conexión: autoridad en DNS SVCB y HTTPS
Publicar un destino alternativo con protocolo, puerto y parámetros coherentes evita que el cliente empiece a ciegas. Aun así, la zona no conoce las capacidades del dispositivo, el proxy que lo representa, la ruta que funciona ni el certificado que encontrará.
Expediente
La lista llegó intacta; la inexistencia se decidió aquí: RPZ y autoridad sobre la respuesta DNS
Una zona de política puede venir del proveedor correcto y superar todos los controles de transporte. El salto decisivo ocurre después: un resolutor local elige si convierte esa información en inexistencia, silencio, redirección o excepción para sus propios usuarios.
Expediente
El resumen coincidía y la zona seguía mal: ZONEMD y el alcance real de la integridad criptográfica
Una zona DNS puede atravesar todos los controles criptográficos y aun así enviar tráfico al destino equivocado. ZONEMD reduce una clase importante de incertidumbre, pero obliga a distinguir con rigor entre una copia íntegra y una decisión correcta.
Expediente
La señal estaba firmada. La delegación aún no era segura: CDS/CDNSKEY y la autoridad para publicar DS
Un proveedor puede firmar correctamente la petición que anuncia su clave y aun así carecer de una cadena capaz de autenticarla. CDS/CDNSKEY reduce el trabajo manual entre hijo y padre, pero conserva una frontera decisiva entre control operativo, mandato del titular, admisión…
Expediente
El catálogo era válido. El borrado no: DNS Catalog Zones y la autoridad para aprovisionar
Un operador puede cambiar la configuración de servidores secundarios administrados por otra organización sin iniciar sesión en ellos. Esa es la utilidad de DNS Catalog Zones y también la razón por la que un catálogo autenticado nunca debe convertirse, por sí solo, en permiso…
Tendencias de servicios en la nube de Europa y Oriente Medio
La frontera regional detrás de la GPU: cómo evaluar la capacidad desplegable de Genesis Cloud
El inventario de aceleradores no basta para describir una nube de inteligencia artificial. La capacidad útil también depende de dónde residen los datos, hasta dónde llega la red privada y cuánto trabajo exige reconstruir un servicio cuando cambia de región. La documentación…
Historia de Internet
Un desvío no podía ser también el destino: la frontera de DNS CNAME
DNS podía conservar un nombre antiguo y conducirlo hacia otro lugar, pero exigía que el nodo de origen renunciara a sus respuestas ordinarias. CNAME convirtió esa renuncia en una instrucción fiable: guardar el desvío, rehacer la pregunta en el nombre objetivo y separar la…