Cómo comprobar DNS: registros, TTL y errores
ToolMellow ·
Una consulta DNS pide a un resolutor un tipo concreto de registro para un nombre concreto. Usa el comprobador DNS de ToolMellow para revisar direcciones, alias, rutas de correo o registros de texto, comparar los proveedores seleccionados y guardar una observación fechada. Empieza por el nombre DNS exacto y el tipo de registro adecuado para tu tarea.
La herramienta consulta Cloudflare y Google Public DNS desde las ubicaciones de consulta disponibles de ToolMellow. Los resultados describen esas solicitudes; no establecen lo que ve cada usuario, dispositivo o resolutor. Esta guía explica los controles, cómo interpretar cada resultado y qué investigar cuando un registro difiere del valor esperado. Todos los nombres, direcciones y valores de ejemplo siguientes son ilustrativos, no mediciones en vivo.
Cómo realizar una consulta DNS
Abre el comprobador DNS y espera a que cargue la configuración de conexión. Introduce un nombre como www.example.com, selecciona un tipo de registro, elige uno o ambos proveedores y selecciona las ubicaciones de consulta disponibles. Pulsa Comprobar DNS para enviar la solicitud. Cargar la página o editar el nombre no consulta sus registros automáticamente.
Antes de interpretar los valores, revisa el proveedor, la ubicación, el estado y la marca de tiempo. Si conoces el valor que necesitas, introdúcelo en el campo opcional de valor esperado y elige Coincidencia exacta o Contiene. Descargar informe DNS guarda la observación actual como dns-results.json; conserva el archivo para comparar el antes y el después.
- Cada consulta utiliza un nombre DNS y un tipo de registro. Ejecuta consultas A y AAAA por separado si investigas ambas familias de direcciones.
- La selección predeterminada es A, ambos proveedores y la ubicación principal de ToolMellow. Las ubicaciones disponibles proceden de la configuración actual del servicio.
- Cambiar el nombre, tipo, proveedor o ubicación borra el resultado anterior. Editar el valor esperado o el modo de comparación vuelve a comparar el resultado actual localmente.
Elige el tipo de registro DNS según tu tarea
Los registros DNS responden a preguntas distintas. Una consulta A no solicita todos los registros de un dominio y una consulta MX no envía un correo de prueba. El selector admite nueve tipos. La comparación de valores esperados admite los ocho tipos de consulta directa indicados a continuación; los resultados PTR pueden revisarse y descargarse, pero su comparación con un valor esperado no está disponible.
| Tipo | Qué contiene | Interpretación práctica |
|---|---|---|
| A | Datos de una dirección IPv4 | Comprueba la dirección IPv4 devuelta para el nombre solicitado; no prueba la web alojada en esa dirección. |
| AAAA | Datos de una dirección IPv6 | Comprueba IPv6 por separado de A; que funcione el destino IPv4 no establece que funcione IPv6. |
| CNAME | Nombre de destino de un alias | Revisa el alias y la escritura devuelta. Un alias DNS no crea por sí mismo una redirección HTTP. |
| MX | Preferencia del intercambiador de correo y nombre de destino | Lee tanto la preferencia como el nombre de host. La presencia del registro no prueba la entrega del correo. |
| TXT | Texto transportado en DNS | Revisa datos de verificación o correo en el nombre exacto indicado por tu proveedor. |
| NS | Nombres de servidores de nombres | Revisa los nombres devueltos; son distintos del proveedor recursivo seleccionado para la consulta. |
| SOA | Metadatos de autoridad de la zona | Revisa los metadatos de la zona y el contexto de respuestas negativas; la hora de consulta no es la hora de edición del registro. |
| CAA | Datos de autorización de autoridades de certificación | Revisa la autorización publicada; esto no comprueba la validez de un certificado ni de HTTPS. |
| PTR | Un puntero de nombre DNS inverso | Introduce el nombre completo del registro DNS inverso. Aquí no se admiten una IP literal ni la comparación con un valor esperado. |
RFC 1035: implementación DNS y formatos de registrosRFC 3596: extensiones DNS para IPv6RFC 8659: autorización de autoridades de certificación
Introduce el nombre DNS correcto, incluidos los nombres TXT e IDN
Introduce el nombre al que pertenece el registro DNS, sin esquema URL, ruta, dirección de correo ni puerto. El dominio raíz y su nombre www son entradas diferentes. Las instrucciones de verificación pueden pedir un subdominio o un nombre con prefijo de guion bajo; consultar TXT en la raíz no busca automáticamente TXT en esos otros nombres.
El comprobador elimina espacios al principio y al final, reconoce variantes Unicode de punto admitidas, quita un punto raíz final, convierte los nombres internacionalizados admitidos a ASCII con domainToASCII de Node y pasa el nombre a minúsculas. Requiere al menos dos etiquetas, cada una con un máximo de 63 caracteres ASCII después de la conversión y un total máximo de 253. Las etiquetas ordinarias admiten letras, cifras y guiones interiores. Se aceptan las etiquetas de servicio admitidas con prefijo de guion bajo, pero no guiones bajos interiores arbitrarios.
| Entrada ilustrativa | Uso | Detalle de la entrada |
|---|---|---|
example.com | Registros del dominio raíz | Selecciona el tipo necesario; no se enumeran todos los tipos ni subdominios. |
www.example.com. | Registros del nombre www | El punto raíz final se acepta y se elimina del nombre normalizado de la consulta. |
_dmarc.example.com | Observación de TXT relacionado con DMARC | Elige TXT. Esta consulta no evalúa todo el descubrimiento de políticas DMARC ni la alineación del mensaje. |
selector._domainkey.example.com | Observación de TXT relacionado con DKIM | Sustituye selector por el selector indicado por tu servicio de correo. |
bücher.example | Entrada de nombre internacionalizado | Los IDN admitidos se convierten a un nombre compatible con ASCII; revisa el nombre normalizado en el resultado. |
10.113.0.203.in-addr.arpa | Entrada del nombre de registro PTR | Los octetos IPv4 están en orden inverso en este ejemplo de nombre DNS inverso; la comparación no está disponible. |
https://example.com/path, 203.0.113.10, *.example.com | Formas de entrada rechazadas | Usa un nombre DNS. Para una IP literal, utiliza la herramienta separada de consulta IP o DNS inverso. |
RFC 5891: nombres de dominio internacionalizadosNode.js: conversión URL domainToASCIIRFC 1035: implementación DNS y formatos de registrosRFC 6376: firmas DKIM y búsqueda de claves por selectorRFC 9989: descubrimiento de políticas y alineación DMARC
Los proveedores recursivos y los servidores autoritativos tienen funciones distintas
Un servidor de nombres autoritativo publica datos de una zona DNS. Un resolutor recursivo obtiene respuestas para sus clientes y puede reutilizar información en caché. Seleccionar Google Public DNS o Cloudflare elige el servicio recursivo de esta observación; no significa que aloje tu zona ni que sea el servidor autoritativo de tu dominio.
ToolMellow envía solicitudes desde su servidor o una sonda configurada a los endpoints HTTPS fijos del proveedor y lee sus respuestas JSON. Este formato JSON definido por el proveedor difiere de los mensajes binarios DNS estandarizados para DNS sobre HTTPS. La consulta no cambia el DNS de tu dispositivo, no consulta un servidor arbitrario que introduzcas ni traza todas las delegaciones desde la raíz.
RFC 1034: nombres de dominio, resolución y cachéRFC 8484: consultas DNS sobre HTTPSGoogle Public DNS: API JSON para DNS sobre HTTPSCloudflare 1.1.1.1: solicitudes DNS sobre HTTPS con JSON
Lee juntos el nombre del registro, el TTL y los detalles de la observación
Cada fila de respuesta incluye el nombre del registro, su tipo, el TTL devuelto en segundos y los datos textuales. Lee también el nombre: una respuesta recursiva puede incluir una cadena de alias y una dirección del destino del alias. Un CNAME auxiliar u otro tipo devuelto no sustituye al tipo solicitado. Despliega Registros de autoridad cuando necesites contexto para una respuesta negativa o una referencia a otros servidores.
Cada resultado de proveedor y ubicación tiene una marca de tiempo de observación y una duración. La marca de tiempo describe esta consulta, no cuándo el administrador editó el DNS. La duración incluye el recorrido de la solicitud y el trabajo HTTP y de procesamiento; no es una medición exclusiva de DNS para tu propia conexión. Si un fallo deja el resultado sin registros o indicadores, considera esos detalles ausentes en lugar de inventar sus valores.
RFC 1035: implementación DNS y formatos de registrosRFC 2308: caché negativa de consultas DNS
Interpreta los estados DNS sin confundir ausencia y fallo
Una respuesta negativa válida y una solicitud que no pudo completarse necesitan seguimientos diferentes. En ToolMellow, la clasificación positiva NOERROR contiene una respuesta del tipo solicitado. Otras respuestas DNS satisfactorias se clasifican por su contexto SOA, CNAME o NS. La tabla explica el estado visible sin convertir toda respuesta vacía en un dominio inexistente.
Una respuesta truncada está incompleta incluso si una parte contiene el texto esperado. La herramienta marca la comparación como inconclusa ante truncamiento o fallos operativos. Un proveedor puede responder correctamente mientras otro falla; conserva ambos resultados en lugar de tomar el fallo como prueba de ausencia del registro.
| Estado o condición | Significado en este comprobador | Siguiente paso útil |
|---|---|---|
| NOERROR | La respuesta satisfactoria contiene datos del tipo solicitado | Revisa cada valor pertinente, su nombre y TTL; el éxito DNS no comprueba el servicio de destino. |
| NXDOMAIN | El resolutor informa de que el nombre DNS consultado no existe | Comprueba la escritura y el nombre previsto. No es una consulta de disponibilidad de registro de dominios. |
| NODATA | No hay respuesta del tipo solicitado; la respuesta satisfactoria contiene SOA en Authority | Comprueba si ese nombre debería tener ese tipo. La ausencia de AAAA no equivale a un dominio inexistente. |
| ALIAS_ONLY | Se devuelve CNAME sin el tipo solicitado, después de comprobar SOA | Revisa el alias e investiga su destino; una respuesta A con solo CNAME no aporta el valor A esperado. |
| REFERRAL | Tras las clasificaciones anteriores, no hay respuesta solicitada pero sí NS en Authority | Revisa Registros de autoridad; no es una respuesta completa del registro solicitado. |
| EMPTY_ANSWER | No hay respuesta solicitada ni contexto SOA, CNAME o NS reconocido | Conserva los detalles; no lo reclasifiques como NXDOMAIN. |
| SERVFAIL o REFUSED | El servidor DNS comunica un fallo o una negativa a responder | Investiga el proveedor y la configuración del dominio; el estado por sí solo no identifica una causa concreta. |
| Error HTTP, tiempo de espera agotado, respuesta mal formada o fallo de sonda | La observación no pudo completarse de forma fiable | Revisa la información de conexión y repite la consulta cuando corresponda; no está probada la ausencia del registro. |
| Truncado / TC | El proveedor comunica una respuesta incompleta | Considera la comparación inconclusa y conserva el indicador de respuesta parcial. |
RFC 2308: caché negativa de consultas DNSGoogle Public DNS: API JSON para DNS sobre HTTPSCloudflare 1.1.1.1: solicitudes DNS sobre HTTPS con JSON
Qué significa el TTL después de cambiar un registro DNS
El TTL expresa la duración de la caché en segundos. Un resolutor recursivo puede devolver el tiempo restante de la información almacenada, por lo que dos respuestas con los mismos datos pueden mostrar TTL diferentes. El número devuelto no es una cuenta atrás hasta que todos los resolutores del mundo usen tu nuevo valor.
Las respuestas positivas, las negativas y la información de delegación pueden tener historiales de caché distintos. Reducir ahora el TTL no acorta retroactivamente la duración asignada a una copia ya almacenada. Algunos resolutores también pueden servir datos caducados conforme a políticas de resiliencia especificadas. Una nueva consulta aporta otra observación, no un certificado de que todas las cachés están actualizadas.
Para un cambio planificado, confirma con el servicio de alojamiento DNS el nombre y los valores previstos, conserva las observaciones antiguas y nuevas y repite las comprobaciones pertinentes a intervalos útiles. Planifica la verificación según las instrucciones del proveedor y el contexto previo de caché. Una afirmación general de 24 o 48 horas no describe todos los cambios DNS.
RFC 2181, sección 8: tiempo de vidaRFC 2308: caché negativa de consultas DNSRFC 8767: servir datos DNS caducados
Por qué el acuerdo entre proveedores no prueba la propagación mundial
Google y Cloudflare pueden responder de forma diferente por sus observaciones almacenadas o su comportamiento de resolución. También pueden influir las respuestas autoritativas que dependen de la ubicación. Compara primero el mismo nombre normalizado y tipo a las horas registradas; después revisa estados, nombres, valores y TTL. Una diferencia no identifica automáticamente la respuesta correcta.
Cada consulta permite seleccionar hasta cuatro ubicaciones configuradas, pero solo están disponibles las que aparecen en la interfaz. Si aparece una, ambos proveedores se consultan desde esa ubicación. La región declarada no es geografía confirmada de forma independiente cuando su indicador de verificación es false. No deduzcas una red mundial de sondas del número de proveedores ni del límite de selección.
El acuerdo demuestra acuerdo entre estas observaciones. Tu dispositivo, otra red o un resolutor corporativo privado pueden ver algo distinto, sobre todo con cachés locales o DNS con vistas distintas según la red. Usa un servicio de varias ubicaciones con el alcance adecuado o los diagnósticos de tu red si necesitas esas perspectivas adicionales.
RFC 1034: nombres de dominio, resolución y cachéRFC 8767: servir datos DNS caducados
Compara valores esperados literalmente con Coincidencia exacta o Contiene
La comparación revisa los valores de Answer del tipo solicitado y admitido por la función. Coincidencia exacta exige que todo el texto devuelto sea igual al esperado; Contiene exige que incluya la subcadena esperada. Ambas distinguen mayúsculas y minúsculas. Un solo valor coincidente marca como coincidente ese resultado de proveedor y ubicación, aunque otros valores difieran. No demuestra que el conjunto completo de registros sea igual a la configuración prevista.
La comparación no elimina espacios, comillas ni puntos finales, no normaliza la escritura IPv6 ni analiza la sintaxis de las políticas DNS. No admite expresiones regulares. La igualdad de nombres DNS puede ignorar diferencias de mayúsculas en el protocolo, mientras que esta comparación de cadenas las distingue. Si necesitas igualdad literal, usa la presentación devuelta y revisa los datos completos antes de tomar una subcadena breve como evidencia.
- NXDOMAIN y NODATA suelen compararse como diferentes si no hay valor del tipo solicitado; son observaciones negativas válidas, no fallos de solicitud.
- Los resultados fallidos o truncados son inconclusos. Tampoco está disponible la comparación si el texto esperado está vacío, supera 4096 unidades de cadena JavaScript o se consulta PTR.
- El texto esperado permanece en esta pestaña y en el informe descargado. No se envía con la consulta DNS. Una coincidencia textual no prueba validación DNSSEC ni propiedad del dominio.
| Datos devueltos ilustrativos | Texto esperado | Qué muestra la comparación |
|---|---|---|
A: 203.0.113.10 | 203.0.113.10 | Coincidencia exacta coincide con este valor; otras respuestas A pueden contener direcciones distintas. |
CNAME: target.example.com. | target.example.com | El punto final produce una diferencia en Coincidencia exacta; Contiene encuentra la subcadena. |
MX: 10 mail.example.com. | mail.example.com | La preferencia y el punto final producen una diferencia exacta; Contiene solo comprueba un fragmento textual. |
TXT: "verification=sample-token" | verification=sample-token | Las comillas incluidas en la respuesta producen una diferencia exacta; Contiene puede encontrar el fragmento. |
CNAME: Target.example.com. | target.example.com. | La comparación literal exacta difiere por las mayúsculas, aunque la igualdad de nombres DNS tenga otra semántica. |
TXT: "part-one" "part-two" | part-onepart-two | La función no une fragmentos entre comillas ni interpreta una política completa. |
Interpreta el indicador de datos autenticados DNSSEC junto con su fuente
La indicación Autenticado refleja el indicador AD del resolutor recursivo seleccionado. Es ese resolutor quien afirma que los datos están autenticados; ToolMellow no verifica de forma independiente las firmas DNSSEC ni la cadena de confianza. Confiar en esa afirmación también depende de confiar en el resolutor y en el canal que transporta su respuesta.
No autenticado significa que el proveedor no afirmó AD. Los datos sin firmar pueden producir ese resultado, por lo que el indicador aislado no demuestra un dominio averiado o malicioso. SERVFAIL también exige investigación, no un diagnóstico automático de DNSSEC. El comprobador solicita datos de respuesta relacionados con DNSSEC y mantiene la comprobación habilitada en el proveedor, pero no realiza una auditoría DNSSEC completa ni una prueba de fugas DNS del navegador.
RFC 4035: DNSSEC y afirmaciones de datos autenticadosGoogle Public DNS: API JSON para DNS sobre HTTPSCloudflare 1.1.1.1: solicitudes DNS sobre HTTPS con JSON
Comprueba el DNS de la web antes de investigar alojamiento y HTTPS
Si una web apunta a un destino antiguo, consulta el nombre de host exacto utilizado por los visitantes. Compara A y AAAA por separado y revisa CNAME para un alias como www. No supongas que el dominio raíz y www tienen la misma configuración. Compara el resultado con los registros previstos en las instrucciones de alojamiento, incluido el destino de alias requerido.
Un valor DNS aparentemente correcto es una parte del diagnóstico de una web. Las redirecciones HTTP, el enrutamiento del host virtual, la validez del certificado y las respuestas de la aplicación requieren comprobaciones propias. CNAME es un alias DNS; enviar al visitante a otra URL es comportamiento HTTP. CAA trata de autorización de autoridades de certificación; su presencia no confirma que la web actual sirva un certificado válido.
RFC 1035: implementación DNS y formatos de registrosRFC 8659: autorización de autoridades de certificación
Consulta TXT de verificación, SPF, DKIM y DMARC en el nombre correcto
Para verificar un dominio, copia el nombre del registro de las instrucciones del servicio y elige TXT. Compara el registro completo con el token requerido, teniendo en cuenta las comillas y los fragmentos mostrados. Encontrar el token es evidencia útil, pero el servicio solicitante aplica su propio proceso de verificación de propiedad.
La política SPF utiliza TXT en el dominio de correo pertinente. La búsqueda de claves DKIM usa un nombre con selector, como selector._domainkey.example.com; obtén el selector del servicio de correo en lugar de adivinarlo. Una comprobación relacionada con DMARC suele empezar con TXT en _dmarc.example.com. El descubrimiento moderno de políticas DMARC y la alineación de identificadores incluyen reglas adicionales que una sola observación TXT no evalúa.
MX describe el enrutamiento del correo, mientras que estos mecanismos basados en TXT tienen funciones distintas. El comprobador no sigue todos los include de SPF, no valida un mensaje firmado, no evalúa todo el descubrimiento de políticas DMARC, no analiza informes DMARC ni prueba la entrega. La presencia de registros y una coincidencia de subcadena no sustituyen esas comprobaciones.
RFC 7208, sección 3.1: políticas SPF en registros TXTRFC 6376: firmas DKIM y búsqueda de claves por selectorRFC 9989: descubrimiento de políticas y alineación DMARC
Comprende la privacidad de la consulta y comparte un informe útil
El nombre y el tipo consultados pasan por el intermediario de ToolMellow o la sonda seleccionada hasta el resolutor público elegido. El resolutor ve la dirección de red de la sonda; ToolMellow no le reenvía los encabezados de IP del visitante. El alojamiento sigue recibiendo metadatos habituales de solicitudes. HTTPS no vuelve anónima toda la actividad ni establece una política de cero registros; el nombre consultado también puede ser sensible.
El texto esperado se compara localmente y puede incluirse como expectedComparison en dns-results.json. Antes de compartir un informe, revisa el nombre consultado, los datos devueltos y el texto esperado, especialmente los tokens de verificación. Envía la observación pertinente a su destinatario previsto en lugar de asumir que todo valor exportado es apropiado para publicarlo.
En una solicitud de soporte, incluye el nombre y tipo exactos, la configuración prevista, el proveedor y la ubicación, la hora de observación, el estado, los datos pertinentes de Answer y Authority y si algún resultado fue truncado o falló. El informe descargado es una instantánea; la herramienta no mantiene un historial de registros en el servidor ni exporta toda tu zona DNS.
Investiga paso a paso una respuesta DNS ausente o inesperada
Empieza por contrastar el nombre normalizado del registro y el tipo seleccionado con las instrucciones de tu alojamiento DNS. Distingue después una respuesta negativa de una solicitud fallida, revisa alias y detalles de Authority y compara ambas observaciones de proveedor. Si usaste un valor esperado, comprueba el texto completo y el modo de comparación antes de concluir que la configuración difiere.
Tras un cambio, guarda un informe y realiza comprobaciones posteriores deliberadas. La herramienta no repite las consultas automáticamente, y repetir solicitudes no vacía todas las cachés. Usa Reintentar conexión cuando se ofrezca ante problemas de configuración, respeta los avisos de límite de solicitudes y realiza una nueva consulta cuando corresponda. Cancelar detiene el trabajo pendiente del cliente y transmite la cancelación a las solicitudes ascendentes, pero no puede deshacer una consulta ya enviada.
Usa las herramientas separadas de consulta IP o DNS inverso si partes de una dirección, y los diagnósticos DNS de tu sistema operativo si investigas el recorrido del resolutor de ese dispositivo. Este comprobador no enumera todos los subdominios, no permite seleccionar SRV, DS, DNSKEY ni ANY, no transfiere una zona ni evalúa la disponibilidad de registro de dominios. Elige el diagnóstico adecuado para la pregunta antes de atribuir un alcance mayor a una respuesta satisfactoria.
Preguntas frecuentes
¿Cómo comprobar todos los registros DNS de un dominio?
Consulta por separado los nombres y tipos admitidos pertinentes para tu tarea. ToolMellow utiliza un nombre y tipo por solicitud; no enumera todos los subdominios, no transfiere la zona ni ofrece un inventario completo de todos los registros.
¿Por qué Google y Cloudflare muestran resultados DNS diferentes?
Sus historiales de caché y su comportamiento de resolución pueden diferir, y las respuestas autoritativas pueden depender de la ubicación. Compara el mismo nombre normalizado y tipo, horas, estados, nombres de registro, valores y TTL. La diferencia por sí sola no identifica la respuesta correcta.
¿El TTL indica cuándo termina la propagación DNS?
No. El TTL devuelto informa de la duración de caché del dato observado. Las cachés positivas y negativas, las delegaciones y las políticas de datos caducados pueden afectar a otras observaciones. No establece una hora de finalización mundial.
¿En qué se diferencian NXDOMAIN y NODATA?
NXDOMAIN informa de que el nombre consultado no existe. NODATA significa que no hay respuesta del tipo solicitado; el comprobador lo identifica mediante SOA en Authority con una respuesta satisfactoria. Un nombre puede tener registros A y no devolver datos AAAA.
¿Por qué falla Coincidencia exacta con mi TXT o CNAME?
La función compara el texto completo devuelto y distingue mayúsculas de minúsculas. Pueden influir comillas, espacios, puntos finales, preferencia MX y presentación. Revisa el valor completo; Contiene solo comprueba una subcadena y no valida todo un registro o política.
¿Una coincidencia significa que todos los registros DNS son correctos?
No. Un valor coincidente de Answer del tipo solicitado y admitido basta para marcar como coincidente ese resultado de proveedor y ubicación. Otros valores pueden diferir, y el texto no prueba propiedad, validación DNSSEC, entrega de correo ni acuerdo mundial.
¿Puedo introducir una IP para consultar PTR?
Para una dirección literal, usa las herramientas separadas de consulta IP o DNS inverso. Este comprobador DNS requiere un nombre completo de registro inverso, como el ejemplo 10.113.0.203.in-addr.arpa. La comparación de valor esperado para PTR no está disponible.
¿Cómo comprobar SPF, DKIM y DMARC?
Elige TXT en el dominio SPF pertinente, en el nombre de selector DKIM indicado por el proveedor bajo _domainkey o en el nombre _dmarc adecuado. Estas consultas revisan texto publicado; no evalúan todas las dependencias SPF, una firma DKIM de mensaje ni el descubrimiento y alineación completos de DMARC.
¿No autenticado significa que mi dominio es inseguro?
No autenticado significa que el proveedor seleccionado no afirmó el indicador AD. Los datos sin firmar también pueden producirlo. ToolMellow no valida DNSSEC independientemente y esa indicación aislada no establece que un dominio sea inseguro.
¿Este comprobador prueba el servidor DNS de mi dispositivo?
Consulta los proveedores públicos elegidos desde las ubicaciones disponibles de ToolMellow. Ese recorrido puede diferir del resolutor y las cachés de tu dispositivo, navegador o red privada. Usa diagnósticos locales para esa pregunta.
¿El acuerdo de dos proveedores prueba la propagación mundial?
Solo demuestra acuerdo entre las observaciones completadas. Dos proveedores consultados desde una sola ubicación listada no forman una red mundial de sondas. Las ubicaciones disponibles y los detalles de confianza de región determinan el alcance del informe.
¿Se envía mi valor esperado a los proveedores DNS?
No. El texto esperado permanece en la pestaña y puede aparecer en el informe descargado. El nombre DNS y el tipo reales sí se envían al resolutor seleccionado a través del servicio. Revisa los tokens y otros datos del informe antes de compartirlo.
Fuentes y lecturas adicionales
- RFC 1034: nombres de dominio, resolución y caché
- RFC 1035: implementación DNS y formatos de registros
- RFC 3596: extensiones DNS para IPv6
- RFC 8659: autorización de autoridades de certificación
- RFC 2181, sección 8: tiempo de vida
- RFC 2308: caché negativa de consultas DNS
- RFC 8767: servir datos DNS caducados
- RFC 4035: DNSSEC y afirmaciones de datos autenticados
- RFC 8484: consultas DNS sobre HTTPS
- Google Public DNS: API JSON para DNS sobre HTTPS
- Cloudflare 1.1.1.1: solicitudes DNS sobre HTTPS con JSON
- RFC 4343: DNS sin distinción de mayúsculas
- RFC 5891: nombres de dominio internacionalizados
- Node.js: conversión URL domainToASCII
- RFC 7208, sección 3.1: políticas SPF en registros TXT
- RFC 6376: firmas DKIM y búsqueda de claves por selector
- RFC 9989: descubrimiento de políticas y alineación DMARC