DNS por HTTPS (DoH)

El DNS público de Google proporciona dos API de DoH distintas en estos extremos:

  • https://dns.google/dns-query – RFC 8484 (GET y POST)
  • https://dns.google/resolve?hl=es-419 – API de JSON (GET)

La página Descripción general de transporte seguro tiene ejemplos de la línea de comandos de curl para usar las API, así como detalles de TLS y otras funciones comunes de DNS a través de TLS (DoT) y DoH.

DoH también es compatible con el servicio Public DNS64 de Google solo para IPv6.

El DNS público de Google no admite URL http: inseguras para llamadas a la API.

Métodos HTTP

DESCUBRAN
Usar el método GET puede reducir la latencia, ya que se almacena en caché de manera más eficaz. Las solicitudes GET de RFC 8484 deben tener un parámetro de consulta ?dns= con un mensaje DNS codificado en Base64Url. El método GET es el único compatible con la API de JSON.
POST
El método POST solo es compatible con la API de RFC 8484 y usa un mensaje DNS binario con una solicitud de tipo de contenido/dns-message en el cuerpo de la solicitud y en la respuesta HTTP de DoH.
HEAD
HEAD no se admite actualmente y muestra un error 400 de solicitud incorrecta.

Otros métodos muestran errores 501 no implementados.

Códigos de estado HTTP

El DoH de Google Public DNS muestra los siguientes códigos de estado HTTP:

Listo

200 OK
El análisis HTTP y la comunicación con el agente de resolución de DNS se realizaron correctamente, y el contenido del cuerpo de la respuesta es una respuesta DNS en codificación binaria o JSON, según el extremo de la consulta, el encabezado Accept y los parámetros GET.

Redirecciones

301 Movido permanentemente
Los clientes deben reintentar en la URL proporcionada en el encabezado Location:. Si la consulta original era una solicitud POST, los clientes solo deberían reintentar con GET si la URL nueva especifica un argumento de parámetro GET dns; de lo contrario, los clientes deben reintentar con POST.

Es posible que se usen otros códigos, como 302 Found, 307 Temporary Redirect o 308 Permanent Redirect, y los clientes del DoH deben manejar los cuatro códigos.

Las respuestas con los códigos 301 y 308 permanentes deben almacenarse en caché de forma indefinida y, si resulta práctico, se puede solicitar a los usuarios que actualicen su configuración original con la URL nueva.

Las solicitudes POST que obtienen respuestas 307 o 308 siempre se deben reintentar con POST.

Errores

Las respuestas de error tendrán una explicación del estado HTTP en el cuerpo, con HTML o texto sin formato.

400 Bad Request
Problemas para analizar los parámetros GET o un mensaje de solicitud de DNS no válido. Para los parámetros GET incorrectos, el cuerpo HTTP debe explicar el error. La mayoría de los mensajes DNS no válidos obtienen un error 200 OK con un FORMERR. Se muestra el error de HTTP para los mensajes ilegibles sin sección Question, una marca QR que indica una respuesta o cualquier otra combinación de marcas sin sentido con errores de análisis de DNS binario.
Carga útil demasiado grande [413 Payload Too Large]
El cuerpo de una solicitud POST de RFC 8484 superó el tamaño máximo de 512 bytes para los mensajes.
El URI 414 es demasiado largo
El encabezado de consulta GET era demasiado grande o el parámetro dns tenía un mensaje DNS codificado en Base64Url que superaba el tamaño máximo de 512 bytes.
415 Unsupported Media Type
El cuerpo de POST no tenía un encabezado application/dns-message de tipo de contenido.
429 Too Many Requests
El cliente envió demasiadas solicitudes en un período determinado. Los clientes deberían dejar de enviar solicitudes hasta el tiempo especificado en el encabezado Reintentar después (un tiempo relativo en segundos).
500 Internal Server Error
Errores de DoH internos del DNS público de Google.
Sin implementar [501 Not Implemented]
Solo se implementan los métodos GET y POST; otros métodos reciben este error.
502 Bad Gateway
El servicio de DoH no pudo comunicarse con los agentes de resolución de DNS público de Google.

En el caso de una respuesta 502, aunque reintentar en una dirección DNS pública de Google alternativa podría ser útil, una respuesta de resguardo más eficaz sería probar otro servicio de DoH o cambiar a DNS UDP o TCP tradicionales en 8.8.8.8.

Beneficios del DoH

Usar HTTPS, no solo la encriptación TLS, tiene algunos beneficios prácticos:

  • Las API de HTTPS con amplia disponibilidad y compatibilidad sencilla simplifican la implementación del DNS público de Google y de los clientes potenciales.
  • Un servicio HTTPS proporciona aplicaciones web con acceso a todos los tipos de registros DNS, lo que evita las limitaciones de las API de DNS del SO y del navegador existentes, que generalmente solo admiten búsquedas de host a dirección.
  • Los clientes que implementan la compatibilidad con HTTPS basada en UDP de QUIC pueden evitar problemas como el bloqueo de línea que puede ocurrir cuando se usa el transporte de TCP.

Prácticas recomendadas de privacidad para DoH

Los desarrolladores de aplicaciones de DoH deben considerar las prácticas recomendadas de privacidad que se describen en RFC 8484 y se expanden a continuación:

  • Limita el uso de encabezados HTTP

    Los encabezados HTTP revelan información sobre la implementación del DoH del cliente y se pueden usar para anonimizar a los clientes. Los encabezados como Cookie, User-Agent y Accept-Language son los peores infractores, pero incluso el conjunto de encabezados enviados puede ser revelador. A fin de minimizar este riesgo, envía solo los encabezados HTTP necesarios para DoH: Host, tipo de contenido (para POST) y, si es necesario, aceptar. El usuario-agente debe incluirse en todas las versiones de desarrollo o prueba.

  • Usar opciones de padding de EDNS

    Sigue las instrucciones en RFC 8467 para usar las opciones de relleno de EDNS a fin de rellenar consultas de DoH con algunas longitudes comunes como protección contra el análisis de tráfico. El padding de HTTP/2 también es posible, pero a diferencia del padding de EDNS, no provocará padding en las respuestas de los servidores de DoH.

  • Usa POST de RFC 8484 solo para aplicaciones sensibles a la privacidad o modos de navegador

    Por lo general, no se recomienda usar POST para las consultas DoH, lo que reduce la capacidad de almacenamiento en caché de las respuestas y puede aumentar la latencia de DNS. Sin embargo, reducir el almacenamiento en caché es probablemente conveniente para las aplicaciones sensibles a la privacidad y podría brindar protección contra ataques de tiempo de apps web que intentan determinar qué dominios visitó recientemente el usuario.

Issues

Para informar un error o solicitar una función nueva, abre un problema para DoH.