Je considère qu'il est peu pratique de changer un fichier d'hôte sur un grand nombre d'hôtes, mais ce n'est pas un véritable problème. je considérerais comme un véritable problème qu'un service critique de couche 3 puisse échouer et se bloquer dans un scénario irrécupérable parce qu'il y avait une dépendance cyclique du dns. les fichiers d'hôtes ont leur place, en particulier dans le fonctionnement du réseau de couche 3 où nous ne pouvons pas encore supposer qu'un service dns fonctionne.
Je suis à la recherche d'une véritable justification pour interdire par politique l'utilisation d'adresses de segment de réseau IP privé réservé.
Je ne vois pas de problème technique à l'utilisation de noms DNS publics pour résoudre des adresses IP pour un usage interne à interne. Souvent, dans ce rare scénario, il est peut-être équivalent ou moins de travail d'utiliser une zone DNS séparée. (l'utilisation d'un hosts fine est logiquement équivalente à une zone dnz séparée imo). donc je pense que si vous envisagez une adresse privée dns publique, considérez si vous avez un plus grand problème de topologie et assurez-vous que vous changez le travail pour résoudre cette topologie.
Je vois un problème de vanité, à savoir qu'il y aura d'innombrables autres réseaux où le nom public en question sera accidentellement (à l'avantage d'un attaquant) dirigé vers des ressources contrôlées par un attaquant. le problème de vanité étant, mon nom dns peut être montré à un utilisateur alors que la communication va vers un serveur que je ne contrôle pas. dans cette circonstance, des choses dépendantes du protocole peuvent se produire. Au pays du http, l'utilisation de hsts et le maintien d'une clé privée tls secrète devraient fournir une vanité suffisante, mais jusqu'à ce que les navigateurs décident de considérer toutes les pages web servies à partir de réseaux privés comme "non sécurisées", il y aura la question de la vanité dans le http. D'autres protocoles, en particulier lorsqu'il n'y a pas de preuve d'authenticité comme le tls de confiance publique (comme https), le tls de confiance privée (comme ssh), ou le tls mutuel (comme openvpn), l'utilisation de dns publics qui se résolvent en dns privés peut poser des problèmes de vanité .
certains vendeurs de matériel exploitent intentionnellement des adresses de ce type, ou du moins je le pensais. "routerlogin dot net" a pu l'être auparavant mais ne l'est plus maintenant, du moins pas d'où je me trouve, ou le fabricant pourrait la parquer comme une adresse de trou noir et compter sur mitm pour le routage ou la résolution DNS (par exemple, DNS split) pour mettre en œuvre une page de configuration de routeur conviviale.
J'ai eu une société de sécurité qui se plaignait des enregistrements dns privés parce qu'ils se trouvaient dans des listes de spam, ce qui est assez logique si la liste de spam est destinée aux opérateurs de messagerie paresseux, mais nous devrions aussi être universellement d'accord pour ne pas livrer ou accepter des e-mails provenant d'une adresse IP privée, surtout sans preuve d'authenticité et d'authentification - ce qui fait que cette plainte n'a pas de sens pour moi au sens de la vanité.
Quand je parle de dns divisés, je fais spécifiquement référence à l'exploitation de 2 ou plusieurs zones dns qui prétendent être l'autorité pour un nom mais qui servent des adresses différentes, par exemple une zone publique et une zone privée pour exemple point com qui se résolvent respectivement comme une adresse publique ou privée.
Je pense qu'il y a des problèmes techniques avec l'utilisation des dns de zone divisée (aka dns privés). particulièrement quand un os, ou une technologie plus récente (comme un vpn) est impliqué parce qu'à la fin de la journée, le programmeur de la pile réseau de l'os ou l'opérateur plus récent a plus de contrôle sur votre résolution dns nue que vous. En particulier, certains systèmes d'exploitation utilisent le multi cast dns où la réponse dns la plus rapide est considérée comme faisant autorité, et je vous parie que votre serveur dns privé sur un vpn sera plus lent que le cache dns ou le résolveur du fournisseur d'accès, il est simplement plus proche de l'utilisateur final en nombre de sauts. Cela signifie que si vous avez un nom dns qui se résout à une adresse ip publique ou privée - par circonstance de quel réseau - - en théorie - il est censé se résoudre dns via - je pense que vous êtes susceptible d'être dans une situation douloureuse.
Pour cette raison, je préfère qu'un enregistrement DNS n'ait jamais plus d'une réponse faisant autorité, quelle que soit la topologie du réseau.
pour moi, cela signifie que les utilisateurs finaux (c'est-à-dire les "développeurs que je soutiens") ont tendance à devoir choisir délibérément s'ils veulent résoudre une adresse privée ou une adresse publique en choisissant entre deux noms dns distincts à utiliser. pour leurs services/applications, mais aussi pour leurs applications web quand et où leurs applications web peuvent être accessibles à la fois sur des réseaux privés et publics grâce à un vpn.
je n'aime pas choisir sélectivement le routage via dns. ip est censé être résilient aux pannes de réseau et ceci ne le sera pas. qu'est-ce qui le serait ? pour être plus "ip", ce serait : avoir une adresse ip canonique (qui pour être canonique ne peut pas être une adresse de réseau privé), et injecter une route (/32) pour ces adresses qui envoie des paquets à un routeur que je contrôle qui répétera ce processus jusqu'à ce que la communication atteigne mon hôte sur un réseau privé tel qu'un vpn+lan sans avoir routé sur un réseau public à moins que le vpn soit désactivé. --Pour les personnes qui considèrent que la gestion d'un fichier de quelques hôtes est trop lourde, je pense que la gestion d'une table de routage comme celle-ci est loin d'être facile, à moins que vous n'utilisiez ipv6 ou que vous fassiez partie de la vieille garde qui possède des blocs d'adresses IP publiques de classe A ou B.
note latérale, je ne suis pas du tout d'accord avec l'utilisation de nat comme "partie de la topologie défensive du réseau". je l'utilise là où normalement il y a une poignée d'adresses publiques et beaucoup de traduction d'adresses de port (surtout dans les systèmes lourds de docker). Configurer accidentellement un pare-feu pour qu'il soit "rejeté par défaut" via un détail d'implémentation du fournisseur d'accès Internet qui signifie accidentellement que votre fournisseur d'accès Internet n'achemine pas actuellement le trafic destiné au réseau du pare-feu - je pense que tout le monde est d'accord pour dire que c'est une très mauvaise stratégie de défense, mais c'est celle que je vois par défaut partout. C'est tellement répandu que dans le cadre de la courbe d'adoption d'ipv6, les opérateurs réseau ont été désorientés et ont demandé un support technique pour le NAT sur ipv6 où il n'y a pratiquement aucune région autre que le culte du cargo pour l'imminent, et si vous l'imminent, il y a de bonnes chances que vous n'ayez littéralement pas assez de RAM pour construire les tables de masques réseau dont le NAT a besoin pour fonctionner, Cela signifie que le NAT ipv6 présente des caractéristiques dynamiques étranges qui, je pense qu'il y a 20 ans, auraient été considérées comme un type de logiciel complètement irresponsable et risqué à mettre sur un pare-feu où chaque affirmation doit être correcte du premier coup et renforcée contre les abus.
en général, je pense que l'affirmation selon laquelle tous les enregistrements dns publics que vous possédez doivent être résolus vers des hôtes que vous contrôlez est une bonne base de référence. elle était également parfaitement logique lorsque vous pouviez, de manière réaliste, posséder plus d'adresses ip que vous n'en aviez besoin. même maintenant, si vous devez utiliser des dns privés, je vous encourage à héberger des dns publics divisés avec une adresse de trou noir sûre connue pour être résolue, de sorte qu'aucun changement de réseau par des opérateurs amis ou autres ne puisse modifier substantiellement votre déploiement.
je pense que la crainte de divulguer les adresses et les segments de réseaux privés est stupide et sans fondement. n'importe quel attaquant sait déjà quels segments de réseaux privés vous possédez et exploitez, la liste est suffisamment petite pour être mémorisée. il serait plus surprenant de découvrir qu'un opérateur n'utilise pas de réseau privé, un peu comme découvrir qu'un opérateur n'utilise pas tcp/ip ou n'utilise pas osi.
Je ne vois aucun problème avec les noms DNS obscurs qui peuvent être résolus publiquement vers des adresses de réseaux privés. Les noms DNS obscurs qui n'ont aucune chance d'être découverts par force brute, n'ont aucune chance qu'un utilisateur puisse deviner de taper manuellement dans une barre d'adresse. pratiquement toutes les zones DNS fonctionnent avec des transferts de zone désactivés, ce qui signifie qu'elles sont opaques à moins que vous ne connaissiez le nom DNS exact avant de le résoudre. (avec le transfert de zone activé, n'importe qui peut lister tous vos enregistrements dns plutôt que de deviner et de vérifier).
c'est parce qu'il y a une pénurie d'adresses IP publiques ipv4 et que des facteurs économiques m'obligent à travailler occasionnellement avec moins que ce dont j'ai besoin. l'adoption et l'utilisation prolifiques de l'ipv6 élimineraient le besoin d'utiliser des dns privés, mais l'ipv6 n'est très souvent pas déployé parce qu'il y a un coût dans le matériel, le logiciel et le personnel opérationnel.
note finale, parfois je suis forcé d'utiliser des noms DNS par des intergiciels, comme les équilibreurs de charge de certains fournisseurs de nuages qui ne fonctionnent que si vous pouvez toujours utiliser la résolution DNS publique vers un résolveur contrôlé par le fournisseur de nuages, même en utilisant un espace d'adressage privé.
Je n'ai pas de réponse dictatoriale à donner ici, juste quelques idées que je n'ai pas vues ailleurs dans ce fil. "certainement pas si le public est composé de personnes, les gens feront des erreurs", "probablement pas si vous avez d'autres options réalistes", "si vous devez le faire, c'est bien, soyez prudent, et soyez informé, comme tout ce que nous faisons en ligne".
