Resumen

  • La revisión 03 del borrador DNSOP sobre GREASE propone usar valores no asignados en varios puntos de extensión del DNS para que implementaciones e intermediarios no conviertan la práctica actual en una lista rígida. Sigue siendo un Internet-Draft activo e incompleto, no una RFC ni una orden de despliegue.
  • Reintentar sin el valor experimental puede aumentar la latencia; lanzar a la vez una consulta normal protege la respuesta, pero aumenta la carga. En sentido inverso, el servidor puede no saber si su respuesta experimental causó un fallo aguas abajo.
  • Antes de habilitar GREASE por defecto, un mandato temporal debe fijar campo, algoritmo, muestra, exclusiones, presupuestos de demora y volumen, datos conservados, fecha de caducidad y responsable de desactivación. Es una propuesta de Daniel Kade, no texto del IETF.

Los protocolos se endurecen sin que nadie pulse un botón para endurecerlos. Primero, una extensión queda vacía durante años. Después, los programas que solo conocen los valores habituales empiezan a rechazar cualquier otro. Los equipos intermedios aprenden la misma costumbre. Cuando llega una función legítima, el espacio existe en el registro, pero ya no existe en la red real.

GREASE intenta mantener abierta esa puerta. Envía valores carentes de utilidad que un receptor correcto debe ignorar. La RFC 8701 formalizó la técnica para TLS: valores reservados y dispersos permiten descubrir a los pares intolerantes antes de que una función real dependa de ellos.

El borrador Greasing Protocol Extension Points in the DNS lleva la pregunta al DNS. Su revisión 03 fue publicada el 6 de julio de 2026 y caduca el 7 de enero de 2027. Pertenece al grupo DNSOP, pero aún es trabajo en curso. No hay consenso sobre rangos reservados; la sección que debería proponerlos sigue siendo un marcador; el comportamiento detallado y las consideraciones para IANA están por completar.

La idea técnica y la autorización operativa no maduran necesariamente al mismo ritmo. Un producto puede implementar el mecanismo antes de que se hayan acordado sus límites. El riesgo comienza cuando esa capacidad se presenta como una opción inocua y termina activada sobre tráfico que pertenece también a usuarios, autoridades y redes intermedias.

Siete espacios, no un solo interruptor

La revisión enumera siete lugares posibles: un indicador del encabezado DNS, Opcode, versión EDNS, indicadores EDNS, Class, tipo de registro y código de opción EDNS. La escala importa. Un bit ofrece una sola posición libre; los campos de dieciséis bits ofrecen decenas de miles. Las asignaciones de IANA cambian y cada registro aplica procedimientos distintos.

El borrador no incluye RCODE ni RCODE extendido. Modificar esos campos cambiaría la lectura que el consultante hace del estado de la respuesta. Los candidatos elegidos son aquellos cuyas novedades debería ignorar un receptor conforme sin romper el intercambio.

Por eso, GREASE no consiste en fabricar mensajes inválidos. El valor está hecho para carecer de semántica funcional. Sirve como sonda: si se ignora, la articulación conserva movimiento; si se rechaza, aparece una incompatibilidad potencial.

Pero una sonda no sirve igual en todos los huecos. Una opción EDNS contiene código y datos, así que hay que definir ambos. Probar un tipo de registro puede exigir una pregunta nueva. Un rango reservado es viable en un espacio grande y desproporcionado en uno pequeño. El permiso debe concederse por punto de extensión y dirección, no a una etiqueta comercial que englobe todos los ensayos.

La ruta de control determina el coste

Si falla la consulta con GREASE, el resolutor puede repetirla sin el añadido. El segundo intento suele conservar compatibilidad. El primer intento, sin embargo, ya consumió tiempo. Para el usuario, el experimento se manifiesta como latencia; para la telemetría común, puede desaparecer porque el resultado final fue correcto.

La alternativa es paralela. Se envía una consulta normal a la vez que la experimental. La respuesta normal atiende al cliente y la otra se usa solo para observación. Se evita esperar al fallo, pero el servidor autoritativo recibe más tráfico y la red procesa dos intercambios donde antes había uno.

Una política de reintento gasta presupuesto de demora. Una política paralela gasta presupuesto de volumen, CPU y salida. Ambas gastan almacenamiento, alertas y horas de diagnóstico. No basta con elegir una fracción de muestreo sin declarar cuál de estas cuentas se está cargando.

El borrador habla de una porción pequeña y escribe tentativamente “quizá una de cada mil consultas”. El signo de interrogación es importante. No es una norma, una garantía ni una medición de capacidad. En un gran servicio, una fracción minúscula puede concentrar miles de consultas adicionales contra un mismo destino.

Las reglas del experimento necesitan porcentaje y límite absoluto, tanto global como por autoridad. Deben excluir momentos de incidente, destinos declarados frágiles y categorías de servicio de alta consecuencia. La expansión por etapas debe depender de métricas independientes de éxito del servicio y de éxito de la prueba.

El experimento iniciado por el servidor pierde visibilidad

Cuando el resolutor inicia GREASE, observa el resultado inmediato. Sabe qué valor envió, puede registrar el silencio o la respuesta y compararlo con un control. Todavía no sabe qué dispositivo exacto provocó la diferencia, pero conserva el comienzo y el final cercano del ensayo.

Un servidor también podría devolver una opción, versión o bandera inesperada. Esa dirección puede resultar valiosa en pruebas acotadas. También es más peligrosa: el servidor quizá no vea si el resolutor aceptó la respuesta, consultó otra autoridad, abandonó la operación o trasladó un error a la aplicación.

La revisión 03 señala que GREASE iniciado por el respondedor debería estar desactivado por defecto. Esta separación no debe perderse en la interfaz de administración. Aceptar pruebas salientes de un resolutor no equivale a aceptar que un servicio autoritativo altere respuestas para clientes desconocidos.

El sentido servidor requiere zonas o nombres expresos, observación externa desde clientes, umbrales más estrictos y un apagado probado. Si el iniciador no puede ver el daño final, tampoco puede promocionar el experimento por la sola ausencia de alarmas locales.

Lo reservado puede fosilizarse; lo libre puede dejar de serlo

Reservar una serie de valores para GREASE evita que más tarde reciban una función real. También permite reconocerlos en una captura. El inconveniente es que un programa puede aprender una excepción: ignorar esa serie conocida y continuar rechazando cualquier otro valor nuevo. La prueba pasa, pero la capacidad general sigue cerrada.

Escoger al azar entre valores sin asignar reduce esa señal reconocible. Abre otro peligro. IANA puede asignar mañana uno de ellos. Una implementación antigua podría haber aprendido a ignorarlo y seguir haciéndolo cuando ya tenga significado.

El borrador propone reducir la colisión mediante una fecha de fin configurada. El registro temporal es una defensa de protocolo. Obliga a que el experimento termine antes de convertirse en comportamiento olvidado y fuerza a revisar las tablas actuales antes de renovarlo.

La página de parámetros DNS de IANA, actualizada el 28 de agosto de 2026 al momento de esta investigación, mantiene tablas separadas para clases, tipos, opcodes, opciones EDNS, banderas y versiones. Su estado presente no resuelve los rangos GREASE todavía debatidos. Una copia fechada del registro sirve como evidencia de lo que estaba libre; no concede propiedad sobre el futuro.

Una medición que no produce reparación solo produce molestias

El propósito no es generar errores sino encontrarlos mientras todavía se pueden corregir. Para eso, el evento experimental debe sobrevivir al reintento. El registro mínimo incluye punto de extensión, clase de valor, versión del algoritmo, dirección, hora, respuesta próxima, duración, ruta normal de control y resultado entregado al cliente.

También debe limitar lo que afirma. Un tiempo agotado no identifica al intermediario responsable. Un FORMERR no localiza el rechazo. La diferencia entre la consulta experimental y la normal puede demostrar un comportamiento reproducible; atribuirlo a un equipo o empresa exige otra evidencia.

La cadencia de GREASE crea una tensión adicional. El borrador general sobre la técnica advierte que una frecuencia demasiado baja se confunde con el ruido, mientras que una pauta demasiado regular facilita el trato especial. La revisión DNS añade que los valores no aleatorios pueden delatar una implementación de resolutor.

Reproducibilidad y privacidad no se maximizan a la vez. Un valor estable durante una versión facilita confirmar un defecto, pero también ayuda a reconocer el producto. Variarlo en cada consulta reduce estabilidad, aunque los reintentos pueden esconder fallos probabilísticos. El mandato debe documentar la elección: rotación por épocas, retención breve, minimización de nombres, agregación antes de compartir y acceso restringido a trazas crudas.

El reintento no resuelve la decisión de seguridad

Retirar una extensión ante cualquier incompatibilidad mantiene el servicio. También recompensa al receptor rígido: el resto de la red adapta su conducta para que nunca tenga que corregirse.

La revisión 03 señala un riesgo de seguridad. Si el mecanismo de reintento desactiva opciones de extensión, un atacante podría forzar la ruta que suprime una función protectora. GREASE pretende sacar esos defectos a la luz y reducir con el tiempo la necesidad de replegarse.

No obstante, observar un fallo, contenerlo y eliminar el reintento son decisiones diferentes. El operador que mide puede no controlar el equipo defectuoso. Quitar el reintento de inmediato puede transformar una deuda de mantenimiento en una interrupción pública.

Las reglas deben conservar tres estados: incompatibilidad observada, impacto mitigado y retirada autorizada del reintento. Cada uno necesita evidencia y propietario propios. Un gráfico con fallos no otorga por sí solo autoridad para cambiar la política de compatibilidad.

Un mandato que caduca

El primer bloque del mandato identifica a quien aprueba el uso de tráfico real, al equipo que lo ejecuta, al analista que puede publicar conclusiones y al responsable con acceso efectivo al interruptor. El valor predeterminado de un proveedor no sustituye la decisión del operador.

El segundo bloque fija el objeto de cable: campo, conjunto o algoritmo de valores, datos anexos, dirección, versión de software y huella de las tablas IANA examinadas. Reserva, uso experimental, uso privado y ausencia de asignación deben conservar sus diferencias.

El tercero define tráfico y coste: clases incluidas, exclusiones, etapas, porcentaje, máximo por segundo, límite por destino, reintento o paralelo, presupuesto de latencia, volumen, CPU, registros y alertas. El control normal debe poder responder aunque falle la rama experimental.

El cuarto define prueba y privacidad: qué cuenta como intolerancia, qué queda sin atribuir, cuánto se conserva, quién recibe agregados, cómo se evita convertir nombres consultados o patrones de resolutor en una base de seguimiento.

El último bloque impone el tiempo: inicio, fecha automática de fin, revisión del registro, renovación explícita, interruptor por prueba, umbral de suspensión y responsable del retorno. Una asignación nueva que choque con los valores activos debe retirarlos sin esperar a un incidente.

La apertura futura del DNS merece una práctica constante. Esa práctica no convierte el tráfico presente en material gratuito. Antes de que el ensayo se vuelva invisible por estar activado de fábrica, sus beneficiarios, costes y límites deben quedar visibles.

Fuentes

  1. Greasing Protocol Extension Points in the DNS — revisión 03
  2. Ficha Datatracker del borrador DNS GREASE
  3. Historial del documento DNS GREASE
  4. Documentos activos de DNSOP
  5. Mandato del grupo DNSOP
  6. RFC 8701 — GREASE para TLS
  7. RFC 6891 — mecanismos de extensión para DNS
  8. Maintaining Protocols Using Grease and Variability — revisión 06
  9. Parámetros DNS de IANA