Pregunte quién produjo la respuesta.
Dos búsquedas DNS pueden no coincidir sin que ninguna de las herramientas se dañe. Se pueden solicitar a un servidor autorizado los datos actuales de la zona; otro puede preguntarle a un solucionador recursivo que contiene una respuesta anterior. Una útil investigación de autenticación registra qué ruta produjo cada observación en lugar de tratar una marca verde de cualquier sitio de búsqueda como el estado final del dominio.
Un servidor autorizado responde desde las zonas a las que sirve. Un solucionador recursivo trabaja en nombre de un cliente, consultando otros servidores o reutilizando información almacenada en caché. Un solucionador de resguardos generalmente pasa preguntas a un servicio recursivo. El mismo software puede realizar más de una función, así que identifique la función de esta respuesta en particular en lugar de depender del nombre de un producto. RFC 1034 , secciones 4.3.1 y 5.3.1.
Esta distinción es importante cuando un artículo recién publicado Selector DKIM aparece en las herramientas del host DNS pero no está disponible para un verificador. La autoridad puede establecer para qué sirve actualmente un servidor; el resultado recursivo ayuda a explicar lo que puede ver una ruta receptora. Ninguna observación sustituye a la otra.
Establecer la delegación antes de elegir un punto final
Comience con el propietario exacto y el tipo implicado en el mensaje o instrucción de servicio. Siga la delegación hasta la zona responsable de ese propietario. Una zona secundaria puede tener servidores autorizados diferentes a los de la principal, y un alias de proveedor puede conducir a una zona diferente nuevamente. Es posible que el host DNS que se muestra en un ticket antiguo ya no sea el host delegado. RFC 1034 , secciones 4.2.1–4.2.2.
Prepare una lista de nombres de servidores autorizados y sus direcciones, luego consulte los servidores relevantes directamente. Conserve la dirección con la que se contactó. Si diferentes autoridades devuelven registros diferentes, investigue primero la publicación DNS o el problema de servicio de zona. Un solucionador puede encontrarse legítimamente con cualquier autoridad disponible; elegir el servidor con la respuesta deseada no resuelve la inconsistencia.
Un rastro puede ayudar a inspeccionar la ruta de delegación, pero es una observación separada. No reproduce la ruta en caché del receptor, la configuración de reenvío, la red de origen o DNSSEC comportamiento de validación. Etiquete un seguimiento como seguimiento en lugar de presentarlo como el historial de consultas del proveedor de correo.
Interpretar banderas con sus límites.
El indicador AA identifica una respuesta autorizada en la respuesta DNS . RD registra que se solicitó recursividad; RA anuncia disponibilidad de recursividad. RD y RA no prueban que el servidor haya realizado una nueva búsqueda de esta respuesta. Un servidor recursivo puede satisfacer una solicitud del caché. RFC 1035 , sección 4.1.1.
Para una verificación de autoridad directa, no solicite recurrencia e inspeccione la respuesta real. Una respuesta sin AA, una remisión, RECHAZADO o un tiempo de espera requiere interpretación; la dirección del servidor por sí sola no hace que todas las respuestas sean autorizadas. Cuando aparezcan alias, mantenga visibles a cada propietario y objetivo e identifique qué zona proporciona los datos finales. La autoridad sobre el propietario del alias no establece automáticamente autoridad sobre su objetivo.
Conserve las secciones completas de preguntas, respuestas y autoridad. Un comando que imprime solo cadenas TXT oculta el contexto necesario para distinguir datos antiguos almacenados en caché, una referencia, un alias y una respuesta de ausencia. La salida breve es útil para una lectura rápida después de guardar el registro de diagnóstico completo.
Comparar un par ficticio de observaciones de resolución
Imagina un selector ficticio blue._domainkey.example.com. A las 10:00 UTC, dos servidores autorizados relevantes devuelven el nuevo registro de clave pública previsto. A las 10:02, el Resolver A devuelve una clave anterior cuando quedan 420 segundos, mientras que el Resolver B devuelve la nueva clave. Estos tiempos, resultados y TTL se inventan para ilustrar el razonamiento; no se realizaron mediciones de la red.
Ese patrón es consistente con diferentes historiales de caché, pero la observación por sí sola no prueba la causa. Verifique que todas las preguntas usaron el mismo nombre, tipo y clase, que se registraron los puntos finales del servidor y que ninguna vista dividida o política de reenvío cambió la respuesta. Si el solucionador A se actualiza posteriormente desde una autoridad inconsistente, es posible que simplemente esperar no resuelva el problema.
La nota de incidente propuesta diría: "Las autoridades incluidas en la muestra están de acuerdo con la nueva clave; el solucionador A aún devuelve la clave anterior; el resultado del receptor aún no se ha observado". No indicaría que todos los receptores estén actualizados o que la autenticación pase ahora. Mantenga la disponibilidad de la clave pública anterior y la transición de la firma del remitente bajo un plan de rotación coordinado en lugar de eliminar registros para que la pantalla de búsqueda luzca ordenada.
Separe los problemas de datos de los problemas de accesibilidad
Un SERVFAIL recursivo no establece que un récord está ausente. Es posible que no se pueda acceder a una autoridad, que una delegación falle o que la validación DNSSEC impida que el solucionador acepte la respuesta. Una respuesta directa de un servidor limita la investigación, pero no prueba que todas las dependencias estén en buen estado para el solucionador recursivo.
El transporte también importa. DNS requiere compatibilidad con TCP y una respuesta UDP truncada puede requerir un reintento de TCP. Comparar una propuesta cavar @AUTH_IP blue._domainkey.example.com . TXT +norecurso con la misma consulta usando +tcp cuando el transporte esté implicado. No modifique la configuración del firewall o de seguridad simplemente para pasar la prueba; Haga que el operador responsable revise la ruta diagnosticada. RFC 7766 , secciones 5 a 6.
Hacer la comparación reproducible
Utilice una fila de la hoja de cálculo por consulta: marca de tiempo UTC, ubicación del operador, punto final del servidor, elección de recursividad, propietario, tipo, clase, código de respuesta, indicadores, registros, TTL y transporte. Repita las observaciones seleccionadas en un intervalo documentado y conserve las filas anteriores. Las cachés DNS evolucionan, por lo que sobrescribir el primer resultado elimina evidencia útil de sincronización.
Termine con un mensaje controlado a través del remitente afectado y conserve las identidades y los resultados del receptor confiable. La comparación DNS puede explicar una dependencia; no puede demostrar la ubicación de la bandeja de entrada ni la búsqueda interna de un receptor en particular. Este artículo proporciona un flujo de trabajo propuesto y una comparación ficticia. Siguen siendo necesarias respuestas originales, autorizadas y recursivas con marca de tiempo antes de que se pueda cerrar la puerta de evidencia del catálogo.