RFC que requiere servidores DNS para responder a solicitudes de dominio desconocido

Mi registrador de dominios y DNS proporcionan actualmente ignora las solicitudes de DNS a dominios desconocidos. Por ignorar me refiero a agujeros negros y nunca responde, lo que hace que mis clientes DNS y bibliotecas de resolución vuelvan a intentarlo, retrocedan y finalmente agote el tiempo de espera.

dig @NS3.DNSOWL.COM somedomainthatdoesntexist.org
...
;; connection timed out; no servers could be reached

Al encuestar a otros servicios de nombres de dominio populares, veo que este comportamiento es bastante único ya que otros proveedores devuelven un RCODE de 5 (RECHAZADO):

dig @DNS1.NAME-SERVICES.COM somedomainthatdoesntexist.org
dig @NS-284.AWSDNS-35.COM somedomainthatdoesntexist.org
dig @NS21.DOMAINCONTROL.COM somedomainthatdoesntexist.org

Todos devuelven algo como lo siguiente:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 64732

o

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31219

Regresar REFUSEDo NXDOMAINinmediatamente es apropiado en mi humilde opinión en lugar de simplemente dejar caer la solicitud en el piso de la sala de servidores.

Cuando me quejo a mi proveedor acerca de que sus servidores no responden, me piden que cite el RFC que sus servidores están violando. Sé que es extraño que me pidan que demuestre que sus servidores deben responder a todas las solicitudes, pero que así sea.

Preguntas :

• Mi estipulación es que, a menos que haya identificadores de solicitud duplicados o algún tipo de respuesta de DOS, un servidor siempre debe responder a la solicitud. ¿Es esto correcto?
• ¿Qué RFC y sección específica debo citar para apoyar mi estipulación?

Para mí, es malo no responder a una consulta DNS. La mayoría de los clientes retrocederán y luego retransmitirán la misma consulta al mismo servidor DNS u otro servidor. No solo están ralentizando a los clientes, sino que están causando que la misma consulta sea realizada nuevamente por sus propios servidores u otros servidores, dependiendo de los servidores de nombres autorizados y las entradas NS.

En RFC 1536 y 2308 veo mucha información sobre el almacenamiento en caché negativo por razones de rendimiento y para detener la retransmisión de la misma consulta. En 4074 veo información sobre cómo devolver una respuesta vacía con un RCODE de 0 para que el cliente sepa que no hay información de ipv6 que debería hacer que el cliente pregunte sobre A RR, que es otro ejemplo de una respuesta vacía.

Pero no puedo encontrar un RFC que diga que un servidor DNS debería responder a una solicitud, probablemente porque está implícito.

El problema específico ocurre cuando migro mi dominio (y los registros DNS asociados) a sus servidores o los primeros X minutos después de registrar un nuevo dominio con su servicio. Hay un retraso entre el momento en que cambian los servidores de nombres autorizados (que es bastante rápido en estos días) y sus servidores comienzan a servir mis registros DNS. Durante este tiempo de retraso, los clientes DNS piensan que sus servidores tienen autoridad pero nunca responden a una solicitud, incluso con un REFUSED. Entiendo el retraso que está bien, pero no estoy de acuerdo con la decisión de no responder a las solicitudes de DNS. Para el registro, entiendo cómo evitar estas limitaciones en su sistema, pero todavía estoy trabajando con ellos para mejorar sus servicios para estar más en línea con el protocolo DNS.

Gracias por la ayuda.

Editar:

Dentro de un par de meses después de publicar esto y hacer un seguimiento con mi proveedor, cambiaron sus servidores para devolver NXDOMAINdominios desconocidos.

El consejo de Shane es correcto. Si no se migran los datos de un servidor autorizado a otro antes de iniciar una transición, es una invitación a una interrupción. Independientemente de lo que ocurra a partir de ese momento, esta es una interrupción iniciada por la persona que cambió los registros NS. Esto explica por qué más personas no presentan esta queja a su proveedor.

Dicho esto, esta sigue siendo una pregunta interesante para responder, así que voy a tomar mi decisión.

La funcionalidad básica de los servidores DNS está cubierta por los documentos RFC 1034 y RFC 1035 , que colectivamente forman STD 13 . La respuesta debe provenir de estos dos RFC o ser aclarada por un RFC posterior que la actualice.

Antes de continuar, hay una trampa enorme aquí fuera del alcance del DNS que debe llamarse: ambos RFC son anteriores a BCP 14 (1997), el documento que aclaró el lenguaje de MAYO, DEBE, DEBE, etc.

• Los estándares que se crearon antes de que este lenguaje se formalizara PUEDEN haber usado un lenguaje claro, pero en varios casos no lo hicieron. Esto condujo a implementaciones divergentes de software, confusión masiva, etc.
• STD 13 es lamentablemente culpable de ser interpretativo en varias áreas. Si el lenguaje no es firme en un área de operación, con frecuencia es necesario encontrar un RFC clarificador.

Con eso fuera del camino, comencemos con lo que RFC 1034 §4.3.1 tiene que decir:

• El modo más simple para el servidor no es recursivo, ya que puede responder consultas utilizando solo información local: la respuesta contiene un error, la respuesta o una referencia a otro servidor "más cercano" a la respuesta. Todos los servidores de nombres deben implementar consultas no recursivas.

...

Si el servicio recursivo no se solicita o no está disponible, la respuesta no recursiva será una de las siguientes:

• Un error de nombre autorizado que indica que el nombre no existe.

• Una indicación de error temporal.

• Alguna combinación de:

  RR que responden a la pregunta, junto con una indicación de si los datos provienen de una zona o se almacenan en caché.

  Una referencia a servidores de nombres que tienen zonas que son ancestros más cercanos al nombre que el servidor que envía la respuesta.

• RR que el servidor de nombres cree que serán útiles para el solicitante.

El lenguaje aquí es razonablemente firme. No hay "debería ser", sino un "será". Esto significa que el resultado final debe ser 1) definido en la lista anterior, o 2) permitido por un documento posterior en la Pista de estándares que modifica la funcionalidad. No estoy al tanto de que exista tal palabrería por ignorar la solicitud y diría que es responsabilidad del desarrollador encontrar un lenguaje que refute la investigación.

Dado el papel frecuente del DNS en los escenarios de abuso de red, no se puede decir que el software del servidor DNS no proporciona los mandos para soltar selectivamente el tráfico en el piso, lo que técnicamente sería una violación de esto. Dicho esto, estos no son comportamientos predeterminados o con valores predeterminados muy conservadores; ejemplos de ambos serían el usuario que requiere que el software elimine un nombre específico ( rpz-drop.) o que se excedan ciertos umbrales numéricos (BIND max-clients-per-query). Es casi inaudito en mi experiencia que el software altere por completo el comportamiento predeterminado de todos los paquetes de una manera que viole el estándar, a menos que la opción sea una que aumente la tolerancia para los productos más antiguos que violan un estándar. Ese no es el caso aquí.

En resumen, este RFC puede y es violado a discreción de los operadores, pero generalmente esto se hace con cierta precisión. Es extremadamente raro ignorar por completo las secciones del estándar como sea conveniente, especialmente cuando el consenso profesional (ejemplo: BCP 16 §3.3 ) se equivoca a favor de que no sea deseable generar una carga innecesaria en el sistema DNS en su conjunto. Teniendo esto en cuenta, los intentos innecesarios de descartar todas las solicitudes para las cuales no hay datos autorizados están menos que deseados.

Actualizar:

Con respecto a que no es deseable dejar consultas en el piso como algo natural, @Alnitak compartió con nosotros que actualmente hay un Borrador de BCP que cubre este tema en detalle. Es un poco prematuro usar esto como una cita, pero ayuda a reforzar que el consenso de la comunidad se alinee con lo que se está expresando aquí. En particular:

A menos que un servidor de nombres esté bajo ataque, debe responder a todas las consultas dirigidas a él como resultado de las siguientes delegaciones. Además, el código no debe suponer que no hay una delegación en el servidor, incluso si no está configurado para servir a la zona. Las delegaciones rotas son una ocurrencia común en el DNS y recibir consultas para zonas para las que el servidor no está configurado no es necesariamente una indicación de que el servidor está bajo ataque. Se supone que los operadores de la zona principal deben verificar regularmente que los registros NS delegados sean consistentes con los de la zona delegada y corregirlos cuando no lo son [RFC1034]. Si esto se hiciera regularmente, las instancias de delegaciones rotas serían mucho menores.

Esta respuesta se actualizará cuando cambie el estado de este documento.

Cuando mueva DNS autorizado para un dominio a un nuevo proveedor, siempre (¡siempre!) Debe probar explícitamente con el nuevo proveedor (y asegurarse de que envíen registros precisos y configurados) antes de modificar la información de registro de su dominio (whois) para apuntar a los nuevos servidores DNS autorizados.

Aproximadamente, los pasos que tomará:

1. Configure todo en el nuevo proveedor de DNS. Debe crear y completar todas las zonas.

2. Asegúrese de que los nuevos servidores autorizados funcionen correctamente. Consultalos explícitamente:

   dig @new-ns.example.com mydomain.com
   

   ¿Cómo suena, por su pregunta, es que no están respondiendo a estas preguntas? Pero, usted dijo "dominios desconocidos" que no debería estar en este punto, debería estar completamente configurado en su sistema (y respondiendo con los registros que configuró).

   Pero, si ya ha configurado el dominio en su sistema, debe responder con los registros correctos en este momento. Si no es así, no están alojando la zona correctamente, y debes gritarles; si responde o no a un dominio que no ha configurado debe ser intrascendente. (Si todavía de alguna manera extraño lo que dices, por favor avísame).

3. Cambie los servidores de nombres autorizados con su registrador de dominio (whois), dejando el antiguo proveedor de DNS en funcionamiento hasta que el tráfico ya no lo golpee (déle al menos 24 horas).

Si el nuevo proveedor no puede tener los registros completos antes de que realice el cambio, entonces la forma en que responden realmente no importará: señalar a los usuarios a una autoridad que rechaza la consulta por completo generará un tiempo de inactividad para su dominio de la misma manera que si fuera sin obtener respuesta alguna.