Resumen
- Elegir al azar valores no asignados obliga a tratar lo desconocido de manera general, pero un valor puede recibir semántica real después de que el software haya aprendido a emitirlo o ignorarlo como grease.
- Una fecha de fin sólo reduce ese riesgo si las versiones desplegadas dejan de usar el valor; estado del registro, versión y configuración activa forman una sola cadena de custodia.
Supongamos que en enero el tipo de registro no estaba asignado. Un resolvedor lo usó como ruido deliberado para comprobar si la ruta toleraba extensiones futuras. En octubre, IANA le asignó una semántica real. El dispositivo antiguo nunca se actualizó: siguió enviándolo como prueba y otro intermediario siguió ignorándolo como si careciera de significado.
El paquete no cambió. Cambió la autoridad que define lo que el número significa.
Esa transición concentra el dilema de draft-ietf-dnsop-grease-03. El greasing mantiene abiertos los puntos de extensión mediante el uso periódico de valores no asignados. La práctica evita que servidores, proxies y equipos intermedios aprendan que sólo el conjunto actual es válido. Pero el espacio no asignado no es propiedad permanente del experimento.
La revisión 03, publicada el 6 de julio de 2026, es un Internet-Draft activo del grupo DNSOP con intención Informational. No es una RFC ni una reserva IANA. El documento deja sin resolver qué rangos deberían reservarse y conserva como trabajo en curso el comportamiento detallado, el fallback, la configuración y la telemetría. No se puede presentar su arquitectura como un despliegue decidido.
Lo desconocido es una condición temporal
DNS ofrece varios lugares candidatos: posiciones de banderas, Opcode, versión y banderas EDNS, Class, Resource Record Type y código de opción EDNS. Un receptor correctamente implementado debería tolerar valores desconocidos en estas superficies según la regla de cada campo.
RCODE y Extended RCODE quedan fuera porque una respuesta con un código distinto cambia el estado que interpreta el consultante. Allí introducir azar no prueba simple tolerancia; altera la operación.
Mientras un valor carece de significado, enviarlo permite observar si la ruta acepta la categoría “desconocido”. Cuando recibe una asignación, deja de pertenecer a esa categoría. Una implementación que conserva la clasificación antigua ya no está haciendo greasing: está interfiriendo con una función real.
Por eso el manifiesto de una prueba debería registrar la instantánea del registro usada al seleccionar valores. La frase “era libre cuando compilamos” no describe el estado cuando el paquete sale meses después.
Reservar evita la colisión y facilita otra rigidez
Una solución es reservar un rango exclusivamente para greasing. Ninguna extensión real ocuparía esos números, de modo que software longevo podría usarlos sin colisión. La telemetría también podría reconocerlos fácilmente.
La ventaja produce su propia vulnerabilidad. Un middlebox puede codificar “permitir rango grease” y continuar bloqueando todo valor desconocido fuera de él. El test pasa porque el aparato reconoce el examen. El punto de extensión real sigue cerrado.
La reserva puede fosilizarse del mismo modo que pretendía evitar. Además, no todos los registros tienen espacio suficiente. Algunos, como RR Type, contienen subrangos con comportamientos distintos; una sola reserva no ejercita todos.
La revisión 03 expone estos argumentos y dice que el grupo aún no alcanzó consenso. La sección de valores reservados sigue siendo un marcador. Un futuro acto de IANA coordinaría sintaxis; no certificaría tolerancia general.
La fecha de fin debe ejecutarse
El borrador propone una fecha de fin preconfigurada o configurable para retirar una operación de greasing antes de que interfiera con asignaciones futuras. Es una buena propiedad de salida. No basta con imprimir la fecha en documentación.
Un equipo que no recibe actualizaciones puede seguir emitiendo el valor vencido. Una configuración copiada puede anular la fecha. Una imagen de contenedor archivada puede volver a desplegar una prueba ya retirada. La salida necesita un propietario y verificación en tiempo de ejecución.
La evidencia mínima conecta cuatro estados: registro vigente, política de selección, versión ejecutada y configuración efectiva. Si cualquiera falta, el operador no puede demostrar que el experimento abandonó el número a tiempo.
El riesgo es asimétrico. Retirar demasiado pronto reduce cobertura del test. Retirar demasiado tarde puede interferir con semántica legítima. La gobernanza debe preferir una salida verificable a una suposición optimista sobre actualizaciones.
El fallo no identifica al culpable
Cuando una consulta con grease falla, sólo sabemos que la ruta observada no toleró la condición. El rechazo puede provenir del servidor autoritativo, un equilibrador, proxy, cortafuegos o middlebox. Una red anycast puede enviar el control y la prueba a instancias distintas.
El resolvedor suele reintentar sin la extensión. Si el segundo intento funciona, la comparación implica el cambio introducido, pero no localiza el componente. Si sólo se guarda el éxito final, incluso esa evidencia desaparece.
Las pruebas paralelas reducen latencia: una consulta normal sirve al usuario y otra con grease alimenta telemetría. Sin embargo, son dos transacciones. Necesitan un recibo de emparejamiento que conserve nombre, destino, valor, transporte, tiempo, instancia observable, caché y resultado.
Un contador agregado sin estas dimensiones puede acusar al extremo visible por un bloqueo intermedio. La reparación llega al actor equivocado y el obstáculo permanece.
El fallback puede entrenar una degradación
La recuperación sin extensión protege disponibilidad. Para una futura característica de seguridad, también puede ser explotada. Un adversario provoca fallos cuando aparece la opción protectora; el resolvedor reintenta sin ella y entrega una respuesta aparentemente normal.
El propósito del greasing es descubrir ese patrón antes de que la extensión sea necesaria y permitir que operadores eliminen el fallback inseguro. No debe convertir la retirada de opciones en una costumbre permanente.
Cada fallback requiere registro del primer intento, motivo, condición de uso, propietario de reparación y criterio de retiro. “El usuario recibió respuesta” no es cierre del incidente de extensibilidad.
Una muestra pequeña no hereda representatividad
El texto sugiere usar sólo una fracción del tráfico y pregunta si una de cada mil consultas podría bastar para una imagen aproximada. No es una tasa normativa.
En un gran resolvedor, una muestra así puede contener millones de observaciones y seguir sesgada. Dominios populares, grandes proveedores autoritativos, regiones densas y horas concretas dominarán. Sistemas heredados raros pueden quedar fuera.
Combinar operadores aumenta cobertura, no crea automáticamente un denominador común. Sus clientes, políticas, transporte, valores y manejo de reintentos difieren. Una cifra global necesita procedencia y estratificación.
DNS Error Reporting puede notificar a operadores autoritativos, pero el informe es una afirmación del resolvedor y requiere controles contra falsificación. Es una pista para investigar, no una sentencia remota.
El servidor que inyecta no ve necesariamente el desenlace
Un respondedor autoritativo también podría devolver una bandera, opción, versión EDNS o tipo inesperado. El borrador considera ese sentido más delicado. El servidor puede no saber si el consultante aceptó, eligió otro servidor, falló o causó un error de aplicación.
Emitir no demuestra recibir. Las pruebas dirigidas necesitan clientes controlados, observación o informes de usuario. Por eso la propuesta dice que el greasing iniciado por el respondedor debería estar desactivado por defecto.
La selección tampoco debe ser predecible: una secuencia fija permite identificar producto o versión del resolvedor. Mantener extensibilidad no justifica crear una huella innecesaria.
El número dejó de ser ruido porque una autoridad de registro le dio significado. La disciplina completa consiste en hacer visible esa transición para todo software que lo tocó. Greasing sin salida verificable no protege el futuro; ocupa temporalmente su espacio y confía en que nadie olvide devolverlo.
Fuentes
- https://www.ietf.org/archive/id/draft-ietf-dnsop-grease-03.txt
- https://www.ietf.org/archive/id/draft-ietf-dnsop-grease-03.html
- https://www.ietf.org/archive/id/draft-ietf-dnsop-grease-03.xml
- https://datatracker.ietf.org/doc/draft-ietf-dnsop-grease/
- https://datatracker.ietf.org/doc/draft-ietf-dnsop-grease/history/
- https://datatracker.ietf.org/doc/draft-ietf-dnsop-grease/references/
- https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-dnsop-grease/
- https://www.ietf.org/archive/id/draft-huque-dnsop-grease-00.txt
- https://www.rfc-editor.org/rfc/rfc8701.txt
- https://www.rfc-editor.org/rfc/rfc6891.txt
- https://www.rfc-editor.org/rfc/rfc1034.txt
- https://www.rfc-editor.org/rfc/rfc1035.txt
- https://www.rfc-editor.org/rfc/rfc2671.txt
- https://www.rfc-editor.org/rfc/rfc7871.txt
- https://www.rfc-editor.org/rfc/rfc7873.txt
- https://www.rfc-editor.org/rfc/rfc8126.txt
- https://www.rfc-editor.org/rfc/rfc7766.txt
- https://www.rfc-editor.org/rfc/rfc5452.txt
- https://www.rfc-editor.org/rfc/rfc9499.txt
- https://www.ietf.org/archive/id/draft-edm-protocol-greasing-04.txt
- https://www.rfc-editor.org/rfc/rfc9567.txt
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
