RFC qui nécessite que les serveurs DNS répondent aux demandes de domaine inconnu

Mon registraire de domaine et fournisseur DNS ignore actuellement les demandes DNS vers des domaines inconnus. Par ignorer, je veux dire les trous noirs et ne répond jamais, ce qui fait que mes clients DNS et les bibliothèques de résolveurs réessayent, s'arrêtent et finalement expirent.

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

En examinant d'autres services de noms de domaine populaires, je constate que ce comportement est assez unique car les autres fournisseurs renvoient un RCODE de 5 (REFUSÉ):

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

Tous renvoient quelque chose comme ceci:

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

ou

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

Le retour REFUSEDou NXDOMAINimmédiatement est approprié à mon humble avis plutôt que de simplement déposer la demande sur le sol de la salle des serveurs.

Lorsque je me plains à mon fournisseur de ne pas répondre à leurs serveurs, ils me demandent de citer le RFC que leurs serveurs violent. Je sais que c'est étrange qu'ils me demandent de prouver que leurs serveurs doivent répondre à toutes les demandes, mais tant pis.

Questions :

• Je stipule qu'à moins qu'il n'y ait des ID de demande en double ou une sorte de réponse DOS, un serveur devrait toujours répondre à la demande. Est-ce correct?
• Quel RFC et section spécifique dois-je citer pour soutenir ma stipulation?

Pour moi, c'est mauvais de ne pas répondre à une requête DNS. La plupart des clients font marche arrière puis retransmettent la même requête au même serveur DNS ou à un autre serveur. Non seulement ils ralentissent les clients, mais ils entraînent à nouveau la même requête par leurs propres serveurs ou d'autres en fonction des serveurs de noms faisant autorité et des entrées NS.

Dans RFC 1536 et 2308, je vois beaucoup d'informations sur la mise en cache négative pour des raisons de performances et pour arrêter la retransmission de la même requête. En 4074, je vois des informations sur le retour d'une réponse vide avec un RCODE de 0 afin que le client sache qu'il n'y a pas d'informations ipv6 qui devraient obliger le client à poser des questions sur un RR qui est un autre exemple de réponse vide.

Mais je ne trouve pas de RFC qui dit qu'un serveur DNS doit répondre à une demande, probablement parce que c'est implicite.

Le problème spécifique se produit lorsque je migre mon domaine (et les enregistrements DNS associés) vers leurs serveurs ou les X premières minutes après avoir enregistré un nouveau domaine avec leur service. Il y a un décalage entre le moment où les serveurs de noms faisant autorité changent (ce qui est sacrément rapide ces jours-ci) et leurs serveurs commencent à servir mes enregistrements DNS. Pendant ce laps de temps, les clients DNS pensent que leurs serveurs font autorité mais ils ne répondent jamais à une demande - même avec un REFUSED. Je comprends le décalage qui est correct mais je ne suis pas d'accord avec la décision de ne pas répondre aux requêtes DNS. Pour mémoire, je comprends comment contourner ces limitations dans leur système, mais je travaille toujours avec eux pour améliorer leurs services afin qu'ils soient plus conformes au protocole DNS.

Merci pour l'aide.

Éditer:

Quelques mois après avoir publié ceci et suivi avec mon fournisseur, ils ont changé leurs serveurs pour revenir NXDOMAINpour des domaines inconnus.

Les conseils de Shane sont corrects. L'échec de la migration des données d'un serveur faisant autorité vers un autre avant de lancer un basculement est une invitation à une panne. Indépendamment de ce qui se passe à partir de ce moment, il s'agit d'une panne déclenchée par la personne qui a balancé les enregistrements NS. Cela explique pourquoi davantage de personnes ne déposent pas de plainte auprès de votre fournisseur.

Cela dit, c'est toujours une question intéressante à répondre, donc je vais y prendre ma fissure.

Les fonctionnalités de base des serveurs DNS sont couvertes par les documents RFC 1034 et RFC 1035 , qui forment collectivement STD 13 . La réponse doit soit provenir de ces deux RFC, soit être clarifiée par une RFC ultérieure qui la met à jour.

Avant de continuer, il y a un énorme écueil ici en dehors de la portée du DNS qui doit être appelé: ces deux RFC sont antérieurs à BCP 14 (1997), le document qui clarifiait le langage de MAI, DOIT, DEVRAIT, etc.

• Les normes qui ont été rédigées avant la formalisation de cette langue PEUVENT avoir utilisé un langage clair, mais dans plusieurs cas, elles ne l'ont pas été. Cela a conduit à des implémentations divergentes de logiciels, à une confusion de masse, etc.
• STD 13 est malheureusement coupable d'interprétation dans plusieurs domaines. Si le langage n'est pas ferme sur une zone d'opération, il est souvent nécessaire de trouver un RFC clarifiant.

Avec cela à l'écart, commençons par ce que la RFC 1034 §4.3.1 a à dire:

• Le mode le plus simple pour le serveur est non récursif, car il peut répondre aux requêtes en utilisant uniquement des informations locales: la réponse contient une erreur, la réponse ou une référence à un autre serveur "plus proche" de la réponse. Tous les serveurs de noms doivent implémenter des requêtes non récursives.

...

Si le service récursif n'est pas demandé ou n'est pas disponible, la réponse non récursive sera l'une des suivantes:

• Une erreur de nom faisant autorité indiquant que le nom n'existe pas.

• Une indication d'erreur temporaire.

• Une combinaison de:

  RR qui répondent à la question, avec une indication si les données proviennent d'une zone ou sont mises en cache.

  Une référence à des serveurs de noms dont les zones sont des ancêtres plus proches du nom que le serveur qui envoie la réponse.

• Les RR que le serveur de noms pense s'avéreront utiles au demandeur.

Le langage ici est raisonnablement ferme. Il n'y a pas de "devrait être", mais un "sera". Cela signifie que le résultat final doit être soit 1) défini dans la liste ci-dessus, soit 2) autorisé par un document ultérieur sur le Standards Track qui modifie la fonctionnalité. Je ne suis pas au courant d'un tel verbiage existant pour ignorer la demande et je dirais qu'il incombe au développeur de trouver un langage qui réfute la recherche.

Étant donné le rôle fréquent du DNS dans les scénarios d'abus de réseau, ne disons pas que le logiciel du serveur DNS ne fournit pas les boutons pour supprimer sélectivement le trafic sur le sol, ce qui serait techniquement une violation de cela. Cela dit, ce ne sont pas des comportements par défaut ou des valeurs par défaut très conservatrices; des exemples des deux seraient l'utilisateur exigeant que le logiciel supprime un nom spécifique ( rpz-drop.), ou certains seuils numériques sont dépassés (BIND max-clients-per-query). D'après mon expérience, il est presque inconnu que le logiciel modifie complètement le comportement par défaut de tous les paquets d'une manière qui viole la norme, à moins que l'option n'augmente la tolérance pour les produits plus anciens qui violent une norme. Ce n'est pas le cas ici.

En bref, cette RFC peut être violée à la discrétion des opérateurs, mais elle est généralement effectuée avec une certaine précision. Il est extrêmement rare de complètement ignorer les sections de la norme comme cela est pratique, surtout quand le consensus professionnel (exemple: BCP 16 §3.3 ) commet une erreur en faveur de celui - ci étant indésirable pour générer une charge inutile sur le système DNS dans son ensemble. Dans cette optique, il n'est pas souhaitable de réessayer inutilement de supprimer toutes les demandes pour lesquelles aucune donnée faisant autorité n'est présente.

Mise à jour:

Concernant le fait qu'il ne soit pas souhaitable de laisser tomber les requêtes sur le sol, @Alnitak a partagé avec nous qu'il existe actuellement un projet de PCA couvrant ce sujet en détail. Il est un peu prématuré de l'utiliser comme une citation, mais cela aide à renforcer le consensus de la communauté avec ce qui est exprimé ici. En particulier:

À moins qu'un serveur de noms ne soit attaqué, il doit répondre à toutes les requêtes qui lui sont adressées suite aux délégations suivantes. De plus, le code ne doit pas supposer qu'il n'y a pas de délégation au serveur même s'il n'est pas configuré pour desservir la zone. Les délégations brisées sont courantes dans le DNS et la réception de requêtes pour des zones pour lesquelles le serveur n'est pas configuré n'est pas nécessairement une indication que le serveur est attaqué. Les opérateurs de la zone parent sont censés vérifier régulièrement que les enregistrements NS délégués sont cohérents avec ceux de la zone déléguée et les corriger lorsqu'ils ne le sont pas [RFC1034]. Si cela était fait régulièrement, les cas de délégations brisées seraient beaucoup plus faibles.

Cette réponse sera mise à jour lorsque l'état de ce document changera.

Lorsque vous déplacez un DNS faisant autorité pour un domaine vers un nouveau fournisseur, vous devez toujours (toujours!) Tester explicitement par rapport au nouveau fournisseur (et vous assurer qu'il envoie des enregistrements précis et configurés) avant de modifier vos informations d'enregistrement de domaine (whois). pour pointer vers les nouveaux serveurs DNS faisant autorité.

En gros, les étapes que vous suivrez:

1. Configurez tout sur le nouveau fournisseur DNS. Vous devez créer et remplir toutes les zones.

2. Assurez-vous que les nouveaux serveurs faisant autorité fonctionnent correctement. Recherchez-les explicitement:

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

   À quoi ressemble votre question, c'est qu'ils ne répondent pas à ces requêtes? Mais, vous avez dit "domaines inconnus" qui ne devraient pas l'être à ce stade, ils devraient être entièrement configurés dans leur système (et répondre avec les enregistrements que vous avez configurés).

   Mais, si vous avez déjà configuré le domaine dans leur système, il doit répondre avec les enregistrements corrects à ce stade. Si ce n'est pas le cas, ils n'hébergent pas correctement la zone, et vous devriez leur crier dessus; qu'il réponde ou non à un domaine qu'il n'a pas configuré devrait être sans conséquence. (Si je manque encore ce que vous dites, faites-le moi savoir).

3. Basculez les serveurs de noms faisant autorité avec votre registraire de domaine (whois), en laissant l'ancien fournisseur DNS opérationnel jusqu'à ce que le trafic ne le frappe plus (donnez-lui au moins 24 heures).

Si le nouveau fournisseur ne peut absolument pas remplir les enregistrements avant d'effectuer le changement, alors la façon dont ils répondent n'a vraiment pas d'importance - le fait de pointer les utilisateurs vers une autorité qui refuse complètement la requête entraînera des temps d'arrêt pour votre domaine tout comme si vous étiez obtenir aucune réponse du tout.