Y a-t-il un inconvénient à toujours mettre à jour DNS à partir de DHCP?


13

J'ai un contrôleur de domaine Windows 2012 exécutant des serveurs DNS et DHCP. Le paramètre par défaut semble être la mise à jour dynamique des enregistrements DNS A et PTR uniquement si les clients DHCP le demandent .

(C'est sous Scope Properties-> DNS)

Y a-t-il un inconvénient à sélectionner Toujours mettre à jour dynamiquement les enregistrements DNS A et PTR ?

Quelle est la différence entre cela et mettre à jour dynamiquement les enregistrements DNS A et PTR pour les clients DHCP qui ne demandent pas de mises à jour (par exemple, les clients exécutant Windows NT 4.0) ?

Réponses:


8

Y a-t-il un inconvénient à sélectionner Toujours mettre à jour dynamiquement les enregistrements DNS A et PTR?

Cela dépend de ce que vous voulez faire.

Par défaut, une machine Windows parlera directement au DNS et mettra à jour son propre Aenregistrement, et elle demandera à DHCP de mettre à jour l' PTRenregistrement.

En activant Toujours mettre à jour dynamiquement le DNS Aet les PTRenregistrements, vous dites à DHCP de mettre à jour les deux enregistrements même si le client lui demande uniquement de mettre à jour le PTR.

Quelle est la différence entre cela et "... pour les clients DHCP qui ne demandent pas de mises à jour ..."

L'exemple NT 4.0 n'est pas si pertinent de nos jours, alors considérez un environnement mixte où vous avez des clients Windows et Mac (ou Linux).

Les machines Windows gèrent leurs mises à jour DNS dynamiques (ou elles demandent à DHCP de le faire).

Mais les clients Mac / Linux ne le font pas. Cette option permet à DHCP de créer des enregistrements pour ces machines qui ne demandent pas ou ne peuvent pas demander de mises à jour DNS dynamiques.

Quelques points à considérer:

  • Vous devez créer un compte d'utilisateur AD dédié et non privilégié pour DHCP à utiliser pour les mises à jour DNS dynamiques et l'ajouter au groupe DnsUpdateProxy (cela est particulièrement important si DHCP s'exécute sur un contrôleur de domaine).
  • DHCP enregistre toujours le nom signalé par le client, même si vous configurez une réservation. Si le client signale un nom différent de celui que vous avez défini dans la réservation, le nom de la réservation sera écrasé.
  • Les enregistrements DNS dynamiques définis via DHCP auront un horodatage défini. Vous devez configurer correctement le nettoyage DNS pour supprimer ces enregistrements, même si DHCP est configuré pour supprimer les enregistrements à l'expiration du bail (c'est bien de l'avoir activé, mais il y a de nombreux cas où cela ne se produit tout simplement pas).

Je pense que vous avez réussi. Je règle généralement le nettoyage de la zone toutes les 24 heures, cela maintient les zones agréables et serrées.
Citizen

1
"En activant Toujours mettre à jour dynamiquement les enregistrements DNS A et PTR, vous dites à DHCP de mettre à jour les deux enregistrements même si le client lui demande uniquement de mettre à jour le PTR." ... et y a-t-il un inconvénient à faire cela?
Roger Lipscombe

@Roger Lipscombe Il n'y a pas d'inconvénient générique auquel je peux penser, mais je ne peux pas vraiment dire s'il y a un inconvénient pour votre situation. J'ai pensé qu'expliquer l'effet vous permettrait de faire cette détermination pour votre environnement.
briantist

"Si le client signale un nom différent de celui que vous avez défini dans la réservation, le nom de la réservation sera écrasé." J'appellerais tout changement à une réservation un inconvénient. Nous perdons des réservations tout le temps, en nous demandant si l'utilisateur spécial fait plus que simplement changer le nom de la réservation.
rjt

0

Concernant l'utilisation du groupe DnsUpdateProxy, je crois comprendre que seuls les serveurs DHCP doivent être membres de ce groupe, pas l'utilisateur de mise à jour DNS dynamique. Le compte d'utilisateur est censé être ajouté à la configuration du serveur DHCP, pas au groupe DnsUpdateProxy.

Le groupe DnsUpdateProxy est destiné aux clients DNS. L'utilisateur n'est pas un client, c'est un mécanisme utilisé par le client (le serveur DHCP) pour effectuer des mises à jour dynamiques du DNS lorsque les mises à jour sécurisées sont uniquement activées. Le client reste le serveur DHCP.

https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-dnsupdateproxy

Lorsque le serveur DHCP est sur un contrôleur de domaine, en plus de rendre le serveur membre du groupe et d'ajouter l'utilisateur à la configuration DHCP, vous devez également désactiver OpenACLOnProxyUpdates. Si vous ne le faites pas, vous ajoutez une vulnérabilité, car l'appartenance au groupe DnsUpdateProxy donne trop d'autorité sur les enregistrements DNS.

Certaines écoles de pensée suggèrent que DHCP sur un contrôleur de domaine ne devrait pas être membre de DnsUpdateProxy et que seul l'utilisateur de mise à jour DNS doit être affecté à DHCP. Cela peut être vrai pour les anciens Windows Server mais pour 2012R2 et versions ultérieures, le sentiment que j'ai des documents techniques est que le serveur doit toujours être dans le groupe DnsUpdateProxy, mais en raison d'être un DC, les autorisations d'appartenance à ce groupe ouvrent la vulnérabilité.

Donc, si vous avez DHCP sur un contrôleur de domaine avec une mise à jour DNS dynamique sécurisée activée, vous devez également exécuter cette commande sur le contrôleur de domaine qui exécute DHCP, afin que son DNS n'autorise pas les mises à jour "étrangères" à modifier les enregistrements appartenant à DHCP:

dnscmd / config / OpenAclOnProxyUpdates 0

En résumé - le groupe DnsUpdateProxy n'est pas destiné à un objet utilisateur - il ne doit être utilisé que pour les objets serveur DHCP (clients DHCP) et est principalement destiné aux "meilleures pratiques" consistant à avoir votre serveur DHCP sur un serveur non DC, pour donner les autorisations nécessaires pour mettre à jour dynamiquement DNS. L'ajout de l'utilisateur de mise à jour sécurisée à ce groupe ne sert à rien.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.