dnsmasq descarta una respuesta DNS privada: ¿es la protección contra rebinding?

El servidor DNS de la empresa devuelve la dirección privada esperada y, aun así, falla una consulta a través del resolutor de reenvío local. La respuesta existe, lo que descarta la zona ascendente y el propio registro. Queda el paso en el que el resolutor decide si devuelve esa respuesta al cliente. Si ese resolutor es dnsmasq, el rechazo probablemente ya está en el registro.

Recibir una respuesta y elegir devolverla son dos pasos distintos.

Compare el mismo nombre en ambos resolutores

Anote qué resolutor usa realmente la aplicación y el nombre de host exacto que consulta. Después compare el resultado ascendente con el evento del resolutor de reenvío para ese mismo nombre. Una respuesta ascendente ausente, una respuesta negativa en caché y un rechazo registrado exigen tres correcciones distintas.

Una dirección visible en una consulta de diagnóstico directa no demuestra que la aplicación la recibiera por su ruta habitual. Las dos consultas pueden salir de resolutores distintos o del mismo resolutor con políticas diferentes. Anote ambos resultados antes de teorizar, porque en este paso se sustituye uno por otro. La comparación es todo el diagnóstico.

Lea el rechazo en lugar del síntoma

La opción stop-dns-rebind de dnsmasq rechaza las respuestas de dirección privada que cumplen los requisitos y llegan del nivel ascendente, y las registra cuando lo hace. Esa protección existe por una buena razón: un nombre público que de pronto se resuelve a una dirección privada es el ataque de rebinding clásico. También se cruza con un servicio privado a propósito, que es su caso.

Busque el rechazo en el registro antes de cambiar nada, porque el mensaje nombra el mecanismo.

Si no hay rechazo ni respuesta ascendente, la protección contra rebinding no es su problema, y desactivarla sería un cambio que no arregla nada y amplía la exposición. Es peor que el fallo original, porque elimina un control y deja el defecto. Confirme primero la línea de registro concreta. Después decida.

Limite la excepción a un solo dominio

Para un dominio verificado, el manual de dnsmasq ofrece una excepción limitada al dominio en lugar de un interruptor global.

rebind-domain-ok=corp.example

El dominio anterior es solo ilustrativo. Use el dominio administrativo que realmente opera y comprenda el alcance de coincidencia de la opción antes de aplicarla, porque una regla de sufijo abarca más que el único host probado. El generador de configuración de un router puede exponer el mismo ajuste mediante su propio control en lugar de una directiva en bruto. Cualquiera de las dos vías sirve si el alcance resultante es el que pretendía.

Una excepción a la detección de rebinding hace exactamente una cosa: deja pasar las respuestas de ese dominio.

No configura un reenviador de split-DNS, ni hace alcanzable un nivel ascendente inalcanzable, ni crea una ruta hacia la dirección devuelta. Cada uno de esos requisitos es independiente y tiene su propia firma de fallo, y cada uno falla de forma distinta en el cliente.

Verifique sin eliminar la frontera

Consulte de nuevo el nombre de host por la ruta de reenvío y luego conéctese al servicio con sus comprobaciones de identidad habituales. Una excepción de DNS no es motivo para aceptar un certificado inesperado, y los dos fallos se confunden con facilidad cuando ambos aparecen como un error del navegador. Pruebe el nombre y el servicio por separado. Solo uno de los dos fue alguna vez un problema de DNS.

Guarde el motivo de la excepción junto a la configuración, con fecha y responsable.

Vuelva a comprobarlo cuando el servicio privado se mueva o cambie el dominio. Desactivar la protección globalmente cambiaría el trato de respuestas no relacionadas y aun así dejaría el fallo de ruta o de servicio si el rebinding nunca fue la causa.