Resumen

  • Known-Answer Suppression permite que una consulta mDNS lleve en su sección Answer los registros que ya conoce. Si el TTL restante alcanza como mínimo la mitad del valor correcto, el respondedor no repite el dato; si baja de esa frontera, debe responder y renovar la caché.
  • Esa sección de una consulta no es autoritativa. Describe lo que un equipo cree durante un intervalo y no puede alimentar la caché de terceros. Por ello, una ausencia de respuesta solo es explicable junto con la consulta, los dos TTL, los demás interesados y la expiración.

La escena parece sencilla: una sala de reuniones despierta, los equipos buscan pantallas e impresoras y las listas se llenan. Sin una disciplina de tráfico, cada aplicación que mantiene abierta la búsqueda seguiría preguntando y cada servicio repetiría lo que todos ya recibieron.

Multicast DNS resuelve nombres y registros con mensajes DNS en el enlace local, mediante UDP 5353. No necesita un servidor unicast convencional para .local.. Su ventaja también crea el problema: una pregunta llega a muchos posibles respondedores, y muchas respuestas llegan a todos los oyentes del mismo dominio.

Stuart Cheshire aparece primero, junto a Marc Krochmal, entre los dos autores de la RFC 6762. El documento no elimina la autonomía de los hosts. Diseña una forma mínima de coordinarla: el que pregunta revela parte de su estado, el que responde calcula si hablar todavía añade información y el tiempo limita cuánto puede durar el silencio.

Una búsqueda continua no termina con el primer resultado

Una consulta puntual puede aceptar la primera respuesta. Un navegador de servicios necesita algo distinto. Debe mostrar instancias que lleguen después y retirar las que ya no existen mientras la persona siga mirando.

La RFC evita convertir esa atención en sondeo constante. Entre las dos primeras consultas continuas debe pasar al menos un segundo; los intervalos posteriores se duplican como mínimo. Al llegar a una hora, pueden mantenerse en una consulta por hora. Un retraso inicial aleatorio reduce la posibilidad de que numerosos clientes pregunten a la vez.

Known-Answer Suppression es obligatoria para este comportamiento continuo. El equipo vuelve a preguntar porque podría haber respuestas nuevas o perdidas. No está pidiendo otra copia de cada registro que aún conserva.

La distinción depende del interés local. Si ninguna aplicación usa un registro y su desaparición no cambia nada visible, el querier no debe mantenerlo con consultas periódicas. El consumo común se justifica por una necesidad presente, no por la mera posibilidad de acumular información.

Una consulta que declara su propia memoria

El interrogador coloca en la sección Answer los registros ya guardados. La optimización sirve sobre todo para conjuntos Shared: conocer algunas instancias no cierra la posibilidad de que existan otras. Un registro Unique en caché suele ser la respuesta completa y normalmente elimina la razón para repetir la misma pregunta.

El respondedor compara el registro recibido con su estado. Si habría enviado el mismo dato y el TTL restante indicado es al menos la mitad del valor correcto, debe callar. El querier conserva margen suficiente antes de que el registro expire.

Por debajo de la mitad, debe contestar. El objetivo cambia de ahorrar una transmisión a evitar que una caché interesada llegue al borde de expiración sin renovación. Por eso el querier tampoco debería transportar registros que ya han consumido más de la mitad de su vida: ocuparían espacio y no lograrían suprimir nada.

La regla no evalúa credibilidad ni calidad. Medio TTL no significa media certeza. Compara dos relojes de la misma clase para decidir una acción. El registro sigue siendo válido o no según su vida restante; la fracción solo decide si una nueva copia aporta valor operativo.

Una métrica de cero respuestas no conserva esta prueba. El recibo útil incluye nombre, tipo y clase de la pregunta, registro conocido, TTL original y restante, TTL correcto del respondedor, carácter Shared o Unique y motivo de la decisión.

La palabra Answer no concede autoridad

La RFC establece que otros queriers no deben guardar registros observados en la sección conocida de una consulta. Aunque el formato use el campo Answer, el emisor solo expresa una creencia. El host que originó el dato puede haberse marchado.

Si los vecinos copiaran esa información, una observación antigua se multiplicaría sin que el servicio volviera a hablar. La economía local se transformaría en propagación de estado obsoleto. La prohibición mantiene el efecto estrecho: la lista puede evitar una respuesta dirigida a esa consulta, pero no actualizar la memoria colectiva.

También limita la interpretación humana. El interrogador no representa al servicio, no autentica al propietario y no declara salud. Participa en una decisión de capacidad, nada más.

De ahí que el silencio sea ambiguo. Puede ser una supresión correcta, pero también puede proceder de pérdida, filtrado, demora o ausencia. La red no entrega significado solo porque un contador permanezca en cero.

Cuando la lista llega por fragmentos

Una lista extensa puede necesitar varios paquetes. El primero incluye la pregunta, tantos registros como quepan y el bit TC. Los siguientes completan inmediatamente las respuestas conocidas.

Al ver TC, el respondedor espera entre 400 y 500 milisegundos. Si un paquete posterior enumera un registro que pensaba enviar, lo retira de su plan. La excepción protege a otros oyentes: si otro host formuló la misma pregunta y espera la respuesta, el dato sigue siendo necesario.

Más paquetes TC prolongan la espera. El texto reconoce que un flujo continuo podría, en teoría, aplazar indefinidamente una respuesta. Su elección ante una sobrecarga así es conservadora: retrasar el descubrimiento antes que añadir respuestas redundantes a un enlace ya saturado.

La preferencia tiene costes. Una aplicación tarda más en completar la lista y un monitor puede confundir la pausa con una avería. Deben medirse la duración, la secuencia de paquetes y los demás solicitantes; el estándar no demuestra que una implantación concreta aplique bien el equilibrio.

La salida está en la caducidad

Cada registro tiene un RR TTL. Tras ese intervalo deja de ser válido y debería salir de la caché. Un servicio no queda preservado por el simple hecho de haber sido descubierto una vez.

Mientras una aplicación siga interesada, la RFC recomienda nuevas consultas cerca del 80, 85, 90 y 95 por ciento de la vida, con una pequeña variación aleatoria. Una respuesta reinicia el TTL. Si las cuatro preguntas no obtienen contestación, el registro se elimina al llegar al cien por cien.

Esta secuencia completa el contrato. En la primera parte de la vida, la memoria evita repeticiones. Más tarde, el respondedor debe renovar. Al final, la falta de prueba fresca deja de sostener el dato.

El tiempo ofrece una vía de salida que ninguna autoridad central tiene que conceder. Una creencia ejerce influencia sobre el tráfico solo mientras conserva un plazo verificable.

El código en ejecución conserva o rompe el límite

El repositorio público mDNSResponder de Apple describe demonios, herramientas y bibliotecas abiertos para DNS Service Discovery. Indica que el demonio observa el puerto 5353, resuelve .local. con mDNS y se usa como resolver del sistema en macOS, además de poder operar en otras plataformas.

Esa fuente muestra una superficie real de implementación, no la conducta universal de todos los equipos. Versiones, derivados, puntos de acceso, puentes entre VLAN y políticas multicast pueden cambiar qué consultas llegan y qué respuestas se suprimen.

La verificación debe mirar paquetes y estado: lista conocida correcta, comparación de TTL, renovación bajo la mitad, silencio sobre ella, espera TC acotada y eliminación al caducar. La norma fija la regla mínima; solo el código y la red demuestran el resultado.

Este reparto encaja con la primacía del código en ejecución. No rebaja el valor de la RFC. Impide usarla como sustituto de evidencia operacional.

La contribución de Cheshire tampoco es un poder ilimitado

Las RFC 6762 y 6763 sitúan a Stuart Cheshire primero y a Marc Krochmal después. Prueban participación destacada en la especificación colectiva de Multicast DNS y DNS-Based Service Discovery.

El perfil de IETF Datatracker revisado el 30 de agosto de 2026 enumera 28 RFC y un puesto actual de delegado en el Congestion Control Working Group. Esos datos son temporales. No prueban invención exclusiva, propiedad de Bonjour, control sobre productos Apple ni responsabilidad por una red local ajena.

La disciplina de atribución es la misma que la del paquete. Un nombre prueba contribución; un registro conocido prueba un estado de caché. Ninguno debe convertirse en una autoridad que su evidencia no soporta.

Fuentes