Dnsmasq et Active Directory - Réseaux PME

Index général de la série: Réseaux informatiques pour les PME: introduction

Salut les amis!. Pour comprendre et suivre correctement cet article est essentiel lecture de ses prédécesseurs:

• Dnsmasq sur CentOS 7.3
• BIND et Active Directory®

Ils expliquent des concepts théoriques et pratiques auxquels nous ne ferons pas référence dans celui-ci. Nous modifierons la distribution de l'année en cours pour Debian 8.6 "Jessie" et nous continuerons avec les mêmes paramètres que nous utilisons dans BIND et Active Directory®.

• La procédure décrite dans cet article est également valable pour CentOS 7. Le fichier de configuration / etc / dnsmasq est le même. Je le déclare car je considère inutile de créer un article séparé pour Dnsmasq et Active Directory® basé sur CentOS. Heureusement, les répertoires liés à la documentation et à la configuration sont les mêmes,
• Le Dnsmaq est une création de Simon Kelley

Limites d'utilisation de Dnsmasq

En raison de son importance, nous répétons le LIMITES qui prend en charge le Dnsmasq -run homme dnsmasq- qui reflète exactement à la suite:

LIMITES

• Les valeurs par défaut des limites de ressources sont généralement prudentes et appropriées pour une utilisation sur des périphériques de type routeur. coincé avec des processeurs lents et une mémoire faible. Dans le matériel plus  capable, il est possible d'augmenter les limites et de supporter beaucoup plus les clients. Ce qui suit s'applique à dnsmasq-2.37: les versions précédentes ne ils ont si bien grimpé.
  

• Dnsmasq est capable de prendre en charge DNS et DHCP au moins mille (1,000) les clients. Les délais de location ne doivent pas être trop courts (moins d'un temps). La valeur de –dns-forward-max peut être augmentée: commencez par l'équivalent du nombre de clients et l'augmenter si le DNS. Notez que les performances DNS dépendent également des serveurs DNS en amont. La taille du cache DNS peut être augmentée: la limite Requis est de 10,000 150 noms et la valeur par défaut (1) est très faible. L'envoi d'un SIGUSRXNUMX à dnsmasq rend les informations de bitacore utile pour affiner la taille du cache. Voir la section NOTES pour plus de détails.

• Le serveur TFTP intégré est capable de prendre en charge plusieurs transferts fichiers simultanés: la limite absolue est liée au nombre de descripteurs de fichiers autorisés à un processus et à la capacité du systèmetem appelle select () pour prendre en charge un grand nombre de descripteurs de fichiers. Si la limite est trop élevée avec –tftp-max, elle sera réduite et la limite réelle sera enregistrée au démarrage. Notez que plus de transferts sont possibles quand le même fichier est envoyé quoi quand chaque transferencia envoie un fichier différent. Il est possible d'utiliser dnsmasq pour refuser la publicité Web en utilisant une liste de serveurs de bannières bien connus, tous résolvant en 127.0.0.1 ou 0.0.0.0 dans / etc / hosts ou dans un fichier d'hôtes supplémentaire. La liste peut être très long. Dnsmasq a été testé avec succès avec un million de noms. Cette taille de fichier nécessite un processeur 1 GHz et approximatif60 Mo de RAM.

• Dnsmasq est capable de prendre en charge DNS et DHCP au moins mille (1,000) clientèle.

Installons et configurons Jessie et Dnsmasq

Nous allons commencer par une nouvelle installation propre d'un serveur basé sur Debian 8 "Jessie". Autrement dit, le système d'exploitation sans interface graphique ou autre package installé. Les paramètres réseau seront les mêmes que ceux utilisés dans l'article BIND et Active Directory®:

Nom de domaine mordor.fan LAN Network 10.10.10.0/24 ==================================== =========================================== Objectif de l'adresse IP des serveurs (serveurs avec OS Windows) ================================================ ================================
sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2
mamba.mordor.fan. 10.10.10.4 Serveur de fichiers Windows
dns.mordor.fan 10.10.10.5 Serveur DnsMasq sur Jessie
darklord.mordor.fan. 10.10.10.6 Proxy, passerelle et pare-feu sur Kerios troll.mordor.fan. 10.10.10.7 Blog basé sur ... je ne me souviens pas de shadowftp.mordor.fan. 10.10.10.8 Serveur FTP blackelf.mordor.fan. 10.10.10.9 Service e-mail complet blackspider.mordor.fan. 10.10.10.10 Service WWW palantir.mordor.fan. 10.10.10.11 Chat sur Openfire pour Windows Real CNAME ============================== Sauron ad-dc mamba fileserver darklord proxyweb troll blog shadowftp ftpserver blackelf mail blackspider www palantir openfire

Paramètres initiaux du serveur dns.mordor.fan

root @ dns: ~ # nano / etc / hostname
dns

root @ dns: ~ # nano / etc / hosts
127.0.0.1 localhost 10.10.10.5 dns.mordor.fan dns # Les lignes suivantes sont souhaitables pour les hôtes compatibles IPv6 :: 1 localhost ip6-localhost ip6-loopback ff02 :: 1 ip6-allnodes ff02 :: 2 ip6-allrouters

root @ dns: ~ # nano / etc / network / interfaces
# Ce fichier décrit les interfaces réseau disponibles sur votre # système et comment les activer. Pour plus d'informations, consultez interfaces (5). source /etc/network/interfaces.d/* # L'interface réseau de bouclage auto lo iface lo inet loopback # L'interface réseau principale allow-hotplug eth0 iface eth0 inet adresse statique 10.10.10.5 masque de réseau 255.255.255.0 réseau 10.10.10.0 diffusion 10.10.10.255. 10.10.10.1 gateway 127.0.0.1 Les options # dns- * sont implémentées par le paquet resolvconf, si installé dns-nameservers XNUMX dns-search mordor.fan

Installons Dnsmasq et htop

root @ dns: ~ # aptitude installe dnsmasq htop

Après avoir installé le package htop nous pouvons vérifier la consommation CPU et mémoire de l'équipement. Il ne consommait qu'environ 71 mégaoctets de RAM. Si nous voulons réduire encore plus la consommation, nous pouvons installer le package SSMTP -facile MTA- qui à son tour purge le colis exim4 que Debian installe toujours par défaut et dont nous n'avons vraiment pas besoin selon l'utilisation que nous allons donner à ce serveur:

root @ dns: ~ # aptitude installe ssmtp
root @ dns: ~ # aptitude purge ~ c
root @ dns: ~ # aptitude clean
root @ dns: ~ # aptitude autoclean
root @ dns: ~ # redémarrage du systemctl

Après redémarrage de l'ordinateur, la consommation est la suivante:

Faible, non? Allons-nous en.

Indiquons que Dnsmasq consulte également le DNS Microsft®

Pour tester les configurations Dnsmasq possibles sur votre ordinateur dns.mordor.fan, nous devons inclure une déclaration indiquant que le DNS Microsoft du serveur est consulté sauron.mordor.fan. Nous pouvons le faire, y compris la directive serveur = / mordor.fan / 10.10.10.3 dans l'archive dnsmasq.conf -comme nous le verrons plus tard- ou en ajoutant la ligne 10.10.10.3 de serveurs de noms dans l'archive / Etc / resolv.conf. Comme nous n'avons pas encore configuré le Dnsmasq en fonction de nos besoins, nous choisissons la deuxième manière:

root @ dns: ~ # nano /etc/resolv.conf
domaine mordor.fan
127.0.0.1 de serveurs de noms
10.10.10.3 de serveurs de noms

Nous pouvons maintenant résoudre les requêtes DNS

Avec la configuration par défaut de Dnsmasq fournie par son fichier principal /etc/dnasmq.conf, et avec ce qui est déclaré dans le fichier / Etc / resolv.conf depuis le serveur lui-même «dns«, Tout client connecté au LAN - et qui s'est déclaré serveur DNS dns.mordor.fan- vous pouvez résoudre les requêtes DNS aux frais de Microsoft® DNS pour l'instant…

• Il est très important de vérifier la vitesse de réponse du Dnsmasq lors de l'affichage de son état comme Transitaire par la simple inclusion de l'IP 10.10.10.3 dans votre fichier / Etc / resolv.conf.

Depuis mon poste de travail administratif et le support de tout l'attirail à travers lequel j'écris, je lance:

buzz @ sysadmin: ~ $ cat /etc/resolv.conf 
# Généré par le serveur de noms du domaine NetworkManager mordor.fan 10.10.10.5

buzz @ sysadmin: ~ $ nslookup
> dns
Serveur: 10.10.10.5 Adresse: 10.10.10.5 # 53 Nom: dns.mordor.fan Adresse: 10.10.10.5

> sauron
Serveur: 10.10.10.5 Adresse: 10.10.10.5 # 53

Réponse ne faisant pas autorité:
Nom: sauron.mordor.fan Adresse: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
Serveur: 10.10.10.5 Adresse: 10.10.10.5 # 53 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan nom canonique = sauron.mordor.fan. Nom: sauron.mordor.fan Adresse: 10.10.10.3

> 10.10.10.3
Serveur: 127.0.0.1 Adresse: 127.0.0.1 # 53 3.10.10.10.in-addr.arpa name = sauron.mordor.fan.

> 10.10.10.9
Serveur: 127.0.0.1 Adresse: 127.0.0.1 # 53 9.10.10.10.in-addr.arpa name = blackelf.mordor.fan.

> 10.10.10.5
Serveur: 127.0.0.1 Adresse: 127.0.0.1 # 53 5.10.10.10.in-addr.arpa name = dns.mordor.fan.

> courrier
Serveur: 10.10.10.5 Adresse: 10.10.10.5 # 53 Réponse ne faisant pas autorité: mail.mordor.fan nom canonique = blackelf.mordor.fan. Nom: blackelf.mordor.fan Adresse: 10.10.10.9> sortie

buzz @ sysadmin: ~ $

Examinons de plus près les aspects suivants:

• dns.mordor.fan répond directement aux requêtes DNS qu'il peut résoudre en fonction de vos paramètres Dnsmasq actuels. Si vous ne pouvez pas les résoudre, cela fonctionne comme Transitaire et demande à IP 10.10.10.3 s'il peut répondre à la requête. Lorsqu'on lui a demandé l'IP de l'équipement «dns«, Il répond directement. Quand on demande au Dnsmasq qui est «sauron",?, faire la transmission à 10.10.10.3 -Vous ne pouvez pas répondre directement parce que vous ne l'avez pas encore enregistré- qui renvoie une réponse non autoritaire correcte.
• Lorsqu'on lui a demandé qui est «03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan"?, faire la transmission à nouveau et cette fois, vous recevez une réponse faisant autorité de Microsoft® DNS.
• La vitesse de réponse élevée de Dnsmasq pour tout type de requête.

Ce sont de petits détails qui font un grand amour ;-).

Différences fondamentales entre Dnsmasq et BIND intégrés à un Active Directory®

Exécutons quelques requêtes DNS sur les enregistrements SOA y NS du domaine mordor.fan, à chacun des serveurs de noms impliqués:

buzz @ sysadmin: ~ $ hôte -t ​​SOA mordor.fan 10.10.10.3
En utilisant le serveur de domaine: Nom: 10.10.10.3 Adresse: 10.10.10.3 # 53 Alias: 
mordor.fan a un enregistrement SOA sauron.mordor.fan. hostmaster.mordor.fan. 56 900 600 86400 3600 XNUMX

buzz @ sysadmin: ~ $ hôte -t ​​SOA mordor.fan 10.10.10.5
En utilisant le serveur de domaine: Nom: 10.10.10.5 Adresse: 10.10.10.5 # 53 Alias: 
mordor.fan a un enregistrement SOA sauron.mordor.fan. hostmaster.mordor.fan. 56 900 600 86400 3600 XNUMX

buzz @ sysadmin: ~ $ hôte -t ​​NS mordor.fan 10.10.10.5
En utilisant le serveur de domaine: Nom: 10.10.10.5 Adresse: 10.10.10.5 # 53 Alias: 
serveur de noms mordor.fan sauron.mordor.fan.

buzz @ sysadmin: ~ $ hôte -t ​​NS mordor.fan 10.10.10.3
En utilisant le serveur de domaine: Nom: 10.10.10.3 Adresse: 10.10.10.3 # 53 Alias: 
serveur de noms mordor.fan sauron.mordor.fan.

Les réponses sont identiques - ce qui est logique - car toujours répond sauron.mordor.fan. avant une requête DNS sur les enregistrements SOA o NS, bien sembler que répond-il dns.mordor.fan. Cependant, cela diffère de ce qui est vu dans l'article BIND et Active Directory® où nous avions complètement supprimé la fonctionnalité de Microsoft® DNS. Dans cet article, TOUTES les requêtes DNS sur l'espace de noms Domino mordor.fan Le BIND leur a répondu, car c'est ainsi que nous le configurons et parce que le BIND répond aux requêtes SOA y NS en plus de permettre le régime Maître d'esclave, Transfert de zones, etc., et donc c'est un serveur DNS plus complet - complexe.

Ce sont peut-être les principales différences entre le DNS du Dnsmasq et du BIND ... mais BIND -il peut toujours y avoir un ou plusieurs mais- ne dispose pas d'un serveur DHCP qui s'intègre de manière transparente à un serveur DNS en un seul démond, et sans avoir besoin de clés TSIG, de fichiers de configuration, de bases de données de zone, etc., comme nous l'avons vu dans les articles précédents.

• Je pense que maintenant, chers lecteurs auront réalisé que je ne déteste pas BIND ou ne préfère pas Dnsmasq à BIND. Les discussions futures à ce sujet sont une perte de temps totale, car elles ont beaucoup à voir avec les besoins, les demandes, les goûts, les préférences et .... chaque solution a son charme ;-)

• Dans des scénarios similaires, laissez chacun installer et configurer le logiciel de son choix et sur lequel il en sait plus. et que tout fonctionne comme prévu.

Avantages de la combinaison Dnsmasq + Active Directory®

Avec cette combinaison, nous avons une gamme complète de réponses aux requêtes DNS et un moyen efficace de louer des adresses IP pour notre réseau local PME. Comme nous le verrons plus loin, il fonctionne correctement pour toute situation concernant la connexion ou non de l'ordinateur au contrôleur de domaine Microsoft® Active Directory®. De plus, nous avons un serveur DNS et DNS Transitaire par excellence, plus un serveur DHCP très rapide. Et le tout avec une faible demande de ressources. En veux-tu plus?

Est-ce possible Dnsmasq + BIND?

Définitivement oui. Bien que je recommande qu'ils soient installés sur différents ordinateurs afin qu'il n'y ait pas de collisions en raison du port 53 très apprécié du service DNS. Peut-être et nous verrons quelque chose à ce sujet quand nous arriverons à l'AD-DC basé sur Samba 4. Qui sait?

Conseils sur Dnamasq

• Les fichiers de travail essentiels pour Dnsmasq pour fournir des services DHCP et DNS sur un LAN sont: /etc/dnsmasq.conf, / Etc / hosts, /var/lib/misc/dnsmasq.leaseset / Etc / resolv.conf. L'archive dnsmasq.baux il est créé lorsque vous louez votre première adresse IP.
• Un autre fichier de travail que vous pouvez utiliser est / etc / ethers. Si un tel fichier existe, la directive lire-éthers déclaré dans le fichier de configuration, dit à Dnsmasq de le lire. C'est très utile quand on raconte Adresses MAC / noms d'hôte à certaines fins.
• Le service DNS peut être complètement désactivé à l'aide de la directive port = 0 dans le dnsmasq.conf.
• Le service DHCP pour une ou plusieurs interfaces réseau peut être désactivé par des directives -une pour chaque ligne- no-dhcp-interface = eth0, no-dhcp-interface = eth1, et ainsi de suite. Très utile lorsque nous sommes face à une équipe avec 2 interfaces réseau ou plus et que nous voulons que le service DHCP soit fourni uniquement par l'une d'entre elles ou par aucune. Bien sûr, si nous désactivons le service DHCP pour toutes les interfaces, nous ne laisserons que le service DNS en cours d'exécution. Si nous désactivons les deux services, pourquoi avons-nous besoin de Dnsmasq? 😉
• Pour déclarer à d'autres serveurs de noms de domaine DNS aucune sont publics ou externes au LAN -comme dans le cas de Microsoft DNS- nous le faisons via la directive serveur = / nom de domaine / IP du serveur DNS dans l'archive /etc/dnsmasq.conf. Exemple: serveur = / mordor.fan / 10.10.10.3.
• Pour indiquer à Dnsmasq que les requêtes sur les domaines locaux ne sont traitées qu'à partir du fichier / Etc / hosts ou via votre DHCP, il faut ajouter la directive local = / localnet / dans le fichier principal de votre configuration. Exemple: local = / mordor.fan /.
• Pour configurer correctement le fichier / Etc / resolv.conf - résolveur nous vous suggérons de lire son manuel en utilisant la commande homme resolv.conf. Si vous installez Debian 8.6 "Jessie", vous constaterez qu'elle est bien écrite en espagnol.
• Dnsmasq n'utilise pas les fichiers de zone pour répondre aux requêtes directes ou inverses.
• Connaître la signification de chaque champ «spécial»Utilisé dans la déclaration d'un enregistrement de ressources SRV, vous devriez consulter BIND et Active Directory®. La syntaxe des enregistrements SRV dans le fichier /etc/dnsmasq.conf est:

  srv-hôte = , , , ,

Les lecteurs qui veulent en savoir plus, veuillez lire attentivement le fichier original /etc/dnsmasq.conf ou documents existants dans l'annuaire / usr / share / doc / dnsmasq-base.

root @ dns: ~ # ls -l / usr / share / doc / dnsmasq-base /
total 128 -rw-r - r-- 1 racine racine 883 5 mai 2015 copyright -rw-r - r-- 1 racine racine 36261 5 mai 2015 changelog.archive.gz -rw-r - r-- 1 root root 11297 5 mai 2015 changelog.Debian.gz -rw-r - r-- 1 root root 26014 5 mai 2015 changelog.gz -rw-r - r-- 1 root root 2084 5 mai 2015 DBus-interface. gz -rw-r - r-- 1 racine racine 4297 5 mai 2015 doc.html drwxr-xr-x 2 racine racine 4096 19 février 17:52 exemples -rw-r - r-- 1 racine racine 9721 5 mai 2015 FAQ.gz -rw-r - r-- 1 racine racine 4180 5 mai 2015 README.Debian -rw-r - r-- 1 racine racine 12019 5 mai 2015 setup.html

Configurons Dnsmasq et Resolver

Nous prendrons comme guide initial - en changeant les noms et autres, bien sûr - le fichier de configuration utilisé dans l'article «Dnsmasq sur CentOS 7.3«.

N'oublions pas la prochaine étape:

[root @ dns ~] # mv /etc/dnsmasq.conf /etc/dnsmasq.conf.original

Adresses IP fixes

Les adresses des serveurs ou équipements qui nécessitent une adresse IP fixe IPv4 comme IPv6- sont déclarées dans le fichier / Etc / hosts:

[root @ dns ~] # nano / etc / hosts
127.0.0.1 localhost # Les lignes suivantes sont souhaitables pour les hôtes compatibles IPv6: 1 localhost ip6-localhost ip6-loopback ff02 :: 1 ip6-allnodes ff02 :: 2 ip6-allrouters # Serveurs et ordinateurs avec des adresses IP fixes. 10.10.10.1 sysadmin.mordor.fan 10.10.10.3 sauron.mordor.fan 10.10.10.4 mamba.mordor.fan 10.10.10.5 dns.mordor.fan 10.10.10.6 darklord.mordor.fan 10.10.10.7 troll.mordor.fan 10.10.10.8. 10.10.10.9 shadowftp.mordor.fan 10.10.10.10 blackelf.mordor.fan 10.10.10.11 blackspider.mordor.fan XNUMX palantir.mordor.fan

Créons le fichier /etc/dnsmasq.conf

[root @ dns ~] # nano /etc/dnsmasq.conf
# ------------------------------------------------- ------------------ # OPTIONS GÉNÉRALES # ----------------------------- -------------------------------------- domain-required # Ne passe pas de noms sans la partie domaine bogus-priv # Ne pas transmettre les adresses dans l'espace non routé expand-hosts # Ajouter automatiquement le domaine à l'hôte interface = eth0 # Interface.  ATTENTION à l'interface # except-interface = eth1 # NE PAS écouter ce NIC strict-order # Ordre dans lequel vous consultez le fichier /etc/resolv.conf # Inclure beaucoup plus d'options de configuration # via un fichier ou en localisant les # fichiers de configuration supplémentaire dans un répertoire # conf-file = / etc / dnsmasq.more.conf conf-dir = / etc / dnsmasq.d # Relatif au nom de domaine domain = mordor.fan # Domain Name # Le serveur de temps est 10.10.10.1. 10.10.10.1 address = / time.windows.com / XNUMX # Envoie une option vide de la valeur WPAD.  Requis pour que les clients # Windos 7 et versions ultérieures se comportent correctement.  ;-) dhcp-option = 252, "\ n" # Fichier où nous déclarerons les HOSTS qui seront "bannis" addn-hosts = / etc / banner_add_hosts # Consulter le serveur DNS Microsoft® "sauron" si # le laisse fonctionner server = / mordor.fan / 10.10.10.3 # Les requêtes sur les domaines locaux seront répondues # à partir de / etc / hosts ou via DHCP local = / mordor.fan / # Les requêtes sur les enregistrements PTR ou inversés seront # répondues par les serveurs "dns" et "sauron" dans cet ordre server = / 10.10.10.in-addr.arpa / 10.10.10.5 server = / 10.10.10.in-addr.arpa / 10.10.10.3 # ------- -------------------------------------------------- ---------- # REGISTROSCNAMEMXTXT # ------------------------------------- ------------------------------ # Ce type d'enregistrement nécessite une entrée # dans le fichier / etc / hosts # par exemple: 10.10.0.7 troll.mordor.fan troll # cname = ALIAS, REAL_NAME cname = ad-dc.mordor.fan, sauron.mordor.fan cname = fileserver.mordor.fan, mamba.mordor.fan cname = proxyweb.mordor.fan , darklord.mordor.fan cname = blog.mordor .fan, troll.mordor.fan cname = ftpserver.mordor.fan, shadowftp.mordor.fan cname = mail.mordor.fan, blackelf.mordor.fan cname = www.mordor.fan, blackspider.mordor.fan cname = opendire .mordor.fan, palantir.mordor.fan # MX RECORDS # Renvoie un enregistrement MX avec le nom "mordor.fan" destiné # à l'équipe blackelf.mordor.fan et avec une priorité de 10 mx-host = mordor.fan, mail. mordor.fan, 10 # La destination par défaut des enregistrements MX créés # à l'aide de l'option localmx sera: mx-target = mail.mordor.fan # Renvoie un enregistrement MX pointant vers mx-target pour TOUTES les # machines locales localmx # Enregistrements TXT. 

dhcp-bail-max = 222 # Nombre maximum d'adresses à louer
                        # par défaut est 150
# IPV6 Range # dhcp-range = 1234 ::, ra-only # Options pour RANGE # OPTIONS dhcp-option = 1,255.255.255.0 # NETMASK dhcp-option = 3,10.10.10.253 # ROUTER GATEWAY dhcp-option = 6,10.10.10.5 .15 # Serveurs DNS dhcp-option = 19,1, mordor.fan # Nom de domaine DNS dhcp-option = 28,10.10.10.255 # option ip-forwarding ON dhcp-option = 42,10.10.10.1 # BROADCAST dhcp-option = 40. 41,10.10.10.3 # NTP # dhcp-option = 44,10.10.10.3, MORDOR # NIS Domain Name # dhcp-option = 45,10.10.10.3 # NIS Server # dhcp-option = 73,10.10.10.3 # WINS # dhcp-option = 46,8 # Datagrammes NetBIOS # dhcp-option = XNUMX # Finger Server # dhcp-option = XNUMX # Nœud NetBIOS dhcp-authoritative # DHCP faisant autorité dans le sous-réseau # ------------- -------------------------------------------------- ---- # --------------------------------------------- ---------------------- # LOGGING tail -f / var / log / syslog ou journalctl -f # ------------ -------------------------------------------------- ----- log-queries # ----------------------------------------- -------------------------- # Re Enregistrements A et SRV correspondant à Active Directory # ----------------------------------------- --------------------------
# Enregistrements A
adresse = / gc._msdcs.mordor.fan / 10.10.10.3 adresse = / DomainDnsZones.mordor.fan / 10.10.10.3 adresse = / ForestDnsZones.mordor.fan / 10.10.10.3

# Enregistrement CNAME de la zone DNS Microsoft _msdcs.mordor.fan
cname=03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan,sauron.mordor.fan

# Enregistrements SRV
# srv-hôte = , , , ,

# Catalogue mondial # Zone DNS Microsoft _msdcs.mordor.fan
srv-host = _ldap._tcp.gc._msdcs.mordor.fan, sauron.mordor.fan, 3268,0,0 srv-host = _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor .fan, sauron.mordor.fan, 3268,0,0
# Zone DNS Microsoft mordor.fan
srv-host = _gc._tcp.mordor.fan, sauron.mordor.fan, 3268,0,0 srv-host = _gc._tcp.Default-First-Site-Name._sites.mordor.fan, sauron.mordor.fan .3268,0,0

# LDAP modifié et privé d'un Active Directory
# Zone DNS Microsoft _msdcs.mordor.fan
srv-host=_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.dc._msdcs.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.pdc._msdcs.mordor.fan,sauron.mordor.fan,389,0,0
# Zone Microsoft DNS mordor.fan
srv-host=_ldap._tcp.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.DomainDnsZones.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.Default-First-Site-Name._sites.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan,sauron.mordor.fan,389,0,0
srv-host=_ldap._tcp.ForestDnsZones.mordor.fan,sauron.mordor.fan,389,0,0

#
# KERBEROS modifié et privé depuis un Active Directory
srv-host=_kerberos._tcp.Default-First-Site-Name._sites.mordor.fan,sauron.mordor.fan,88,0,0
srv-host=_kerberos._tcp.mordor.fan,sauron.mordor.fan,88,0,0
srv-host=_kpasswd._tcp.mordor.fan,sauron.mordor.fan,464,0,0
srv-host=_kerberos._udp.mordor.fan,sauron.mordor.fan,88,0,0
srv-host=_kpasswd._udp.mordor.fan,sauron.mordor.fan,464,0,0

# FIN du fichier /etc/dnsmasq.conf
# ------------------------------------------------- ------------------

Créons le fichier / etc / banner_add_host

[root @ dns ~] # nano / etc /bannière_add_hosts
127.0.0.1 windowsupdate.com 127.0.0.1 ctldl.windowsupdate.com 127.0.0.1 ocsp.verisign.com 127.0.0.1 csc3-2010-crl.verisign.com 127.0.0.1 www.msftncsi.com 127.0.0.1 ipv6.msftncsi.com 127.0.0.1 teredo.ipv6.microsoft.com 127.0.0.1 ds.download.windowsupdate.com 127.0.0.1 download.microsoft.com 127.0.0.1 fe2.update.microsoft.com 127.0.0.1 crl.microsoft.com 127.0.0.1 www .download.windowsupdate.com 127.0.0.1 win8.ipv6.microsoft.com 127.0.0.1 spynet.microsoft.com 127.0.0.1 spynet1.microsoft.com 127.0.0.1 spynet2.microsoft.com 127.0.0.1 spynet3.microsoft.com 127.0.0.1. 4 spynet127.0.0.1.microsoft.com 5 spynet127.0.0.1.microsoft.com 15 office127.0.0.1client.microsoft.com 127.0.0.1 addons.mozilla.org XNUMX crl.verisign.com

[root @ dns ~] # dnsmasq --test
dnsmasq: vérification de la syntaxe OK.

[root @ dns ~] # systemctl restart dnsmasq.service 
[root @ dns ~] # systemctl status dnsmasq.service

Modifions le fichier /etc/resolv.conf - Resolver

root @ dns: ~ # nano /etc/resolv.conf 
domaine mordor.fan recherche mordor.fan

Pourquoi n'avons-nous pas les lignes habituelles déclarées dans le fichier résolution.conf? Parce que nous déclarons dans le dnsmasq.conf les directives suivantes:

# Consultez le serveur DNS Microsoft® "sauron" si nous # le laissons fonctionner
serveur = / mordor.fan / 10.10.10.3

# Les requêtes sur les domaines locaux seront traitées # à partir de / etc / hosts ou via DHCP
local = / mordor.fan /

# Les requêtes concernant les enregistrements PTR ou inversés seront # répondues par les serveurs "dns" et "sauron" dans cet ordre
serveur = / 10.10.10.in-addr.arpa / 10.10.10.5 serveur = / 10.10.10.in-addr.arpa / 10.10.10.3

Requêtes de sysadmin.mordor.fan

L'archive / Etc / resolv.conf de cette équipe est:

buzz @ sysadmin: ~ $ cat /etc/resolv.conf
# Généré par NetworkManager search mordor.fan nameserver 10.10.10.5

buzz @ sysadmin: ~ $ host -t Vers spynet4.microsoft.com
spynet4.microsoft.com a l'adresse 127.0.0.1

buzz @ sysadmin: ~ $ host -t Vers www.download.windowsupdate.com
www.download.windowsupdate.com a l'adresse 127.0.0.1

buzz@sysadmin: ~ $ dig dns
buzz @ sysadmin: ~ $ dig dns.mordor.fan
;; SECTION QUESTION :; dns.mordor.fan. DANS UN ;; SECTION RÉPONSE: dns.mordor.fan. 0 DANS UN 10.10.10.5

buzz @ sysadmin: ~ $ hôte -t ​​SRV _ldap._tcp.gc._msdcs
buzz @ sysadmin: ~ $ hôte -t ​​SRV _ldap._tcp.gc._msdcs.mordor.fan
_ldap._tcp.gc._msdcs.mordor.fan a un enregistrement SRV 0 0 3268 sauron.mordor.fan.

buzz @ sysadmin: ~ $ dig _ldap._tcp.gc._msdcs.mordor.fan
;; SECTION DES QUESTIONS :; _ldap._tcp.gc._msdcs.mordor.fan. DANS UN ;; SECTION DE RÉPONSE: _ldap._tcp.gc._msdcs.mordor.fan. 0 DANS UN 10.10.10.3

buzz @ sysadmin: ~ $ dig mordor.fan axfr
buzz @ sysadmin: ~ $ dig 10.10.10.in-addr.arpa axfr

Et de cette façon, combien de consultations nous avons besoin

Clients Dnsmasq + Active Directory® + Microsoft® Windows

Renommer un client Microsoft® Windows

sept.mordor.fan adresse IP louée:

root @ dns: ~ # cat /var/lib/misc/dnsmasq.leases 
1488006009 00:0c:29:d6:14:36 10.10.10.115 seven 01:00:0c:29:d6:14:36

Renommons le «sept»-Qui n'est pas joint au domaine Active Directory- par«eucalyptus«. Après le changement et le redémarrage, nous vérifions:

root @ dns: ~ # cat /var/lib/misc/dnsmasq.leases 
1488006633 00:0c:29:d6:14:36 10.10.10.115 eucaliptus 01:00:0c:29:d6:14:36

L'historique des modifications peut être consulté depuis "sysadmin":

buzz @ sysadmin: ~ $ host -t Un sept
seven.mordor.fan a l'adresse 10.10.10.115

Après le changement de nom

buzz @ sysadmin: ~ $ host -t Un sept
sept n'a pas de record A

buzz @ sysadmin: ~ $ host -t Un eucaliptus
eucaliptus.mordor.fan a l'adresse 10.10.10.115

Requêtes du client eucaliptus.mordor.fan

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Tous les droits sont réservés.

C: \ Utilisateurs \ buzz> nslookup
Serveur par défaut: dns.mordor.fan Adresse: 10.10.10.5

> sauron
Serveur: dns.mordor.fan Adresse: 10.10.10.5 Nom: sauron.mordor.fan Adresse: 10.10.10.3

> mordor.fan
Serveur: dns.mordor.fan Adresse: 10.10.10.5 Nom: mordor.fan Adresse: 10.10.10.3

> eucalyptus
Serveur: dns.mordor.fan Adresse: 10.10.10.5 Nom: eucaliptus.mordor.fan Adresse: 10.10.10.115

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
Serveur: dns.mordor.fan Adresse: 10.10.10.5 Nom: sauron.mordor.fan Adresse: 10.10.10.3 Alias: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> définir le type = SRV
> _kerberos._udp.mordor.fan
Serveur: dns.mordor.fan Adresse: 10.10.10.5 _kerberos._udp.mordor.fan Emplacement du service SRV: priority = 0 weight = 0 port = 88 svr hostname = sauron.mordor.fan sauron.mordor.fan internet address = 10.10.10.3. XNUMX

> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan
Serveur: dns.mordor.fan Adresse: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan Emplacement du service SRV: priority = 0 weight = 0 port = 389 svr hostname = sauron Adresse internet .mordor.fan sauron.mordor.fan = 10.10.10.3

> quitter

C: \ Utilisateurs \ buzz>

Enregistrement des clients Windows dans Microsoft® DNS

Clients Windows non joints au domaine Active Directory®

Il faut vérifier si les adresses IP louées par les différents clients Windows de Dnsmasq sont correctement enregistrées dans Microsoft® DNS. Cela peut influencer la façon dont nous activons les mises à jour dynamiques - Mises à jour dynamiques dans les zones DNS Microsoft® de l'Active Directory®. Nous partons de la configuration par défaut de Microsoft DNS qui n'autorise que les mises à jour dynamiques sécurisées - Mises à jour dynamiques -> Sécurisé uniquement, dans chacune de ses zones.

Notez que le client avec le courant FQDN eucalyptus.mordor.fan aucune est attaché au domaine Active Directory (ou à un AD-DC Samba4), et est une exception à la règle de Microsoft selon laquelle «Seuls les clients enregistrés dans Mon domaine auront la permission via Mon mécanisme de mise à jour - que je connais seulement - de s'inscrire dans Mon DNS«. Heureusement que le Samba4 AD-DC nous apprend quelque chose à ce sujet.

eucalyptus.mordor.fan IP loué 10.10.10.115:

buzz @ sysadmin: ~ $ host -t Un eucaliptus
eucaliptus.mordor.fan a l'adresse 10.10.10.115

Changeons son nom en «acajou«, Redémarrons Windows 7, et voyons ce qui se passe lorsque nous demandons les noms«eucalyptus« Et »acajou»À chacun des DNS, d'abord vers Microsoft DNS puis vers Dnsmasq:

buzz @ sysadmin: ~ $ host -t Un eucaliptus.mordor.fan 10.10.10.3
En utilisant le serveur de domaine: Nom: 10.10.10.3 Adresse: 10.10.10.3 # 53 Alias: 

Hôte eucaliptus.mordor.fan introuvable: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t Un acajou.mordor.fan 10.10.10.3
En utilisant le serveur de domaine: Nom: 10.10.10.3 Adresse: 10.10.10.3 # 53 Alias: 

Hôte mahogany.mordor.fan introuvable: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t Un eucaliptus.mordor.fan 10.10.10.5
En utilisant le serveur de domaine: Nom: 10.10.10.5 Adresse: 10.10.10.5 # 53 Alias: 

Hôte eucaliptus.mordor.fan introuvable: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t Un acajou.mordor.fan 10.10.10.5
En utilisant le serveur de domaine: Nom: 10.10.10.5 Adresse: 10.10.10.5 # 53 Alias: 

mahogany.mordor.fan a l'adresse 10.10.10.115

Nous pouvons changer le nom du client Windows 7 qui aucune est attaché au domaine mordor.fan de l'Active Directory® autant de fois que nous le souhaitons, que le DNS Microsoft® ne soit pas informé de ces changements ou qu'un tel client existe. Est-il possible que ce soit uniquement parce que nous avons sélectionné l'option  Mises à jour dynamiques -> Sécurisé uniquement dans chaque zone du DNS Micorosft?.

Pour que M. Microsoft® DNS soit informé des changements, nous devons sélectionner Mises à jour dynamiques -> Non sécurisé et sécurisé. Cette option, chers lecteurs, implique une vulnérabilité importante de la sécurité de tout serveur de noms de domaine respecté, que ce soit Microsft® ou UNIX® / Linux. Le DNS Microsoft® met en garde contre la vulnérabilité car au final ce n'est rien de plus qu'un BIND modifié et privatisé à nous proposer «Sécurité pour l'obscurité«. Sinon, pourquoi recommandez-vous d'économiser sur votre célèbre enregistrer tous les paramètres DNS et les enregistrements de votre DNS Microsoft® lorsque nous implémentons un Active Directory®?. Outre la prise en charge des mises à jour non sécurisées de Microsoft® DNS, la modification suivante est requise dans la configuration de la carte réseau du client Windows 7:

Allons vérifier:

buzz @ sysadmin: ~ $ host -t Un acajou.mordor.fan 10.10.10.3
En utilisant le serveur de domaine: Nom: 10.10.10.3 Adresse: 10.10.10.3 # 53 Alias: acajou.mordor.fan a l'adresse 10.10.10.115

buzz @ sysadmin: ~ $ host 10.10.10.115 10.10.10.3
En utilisant le serveur de domaine: Nom: 10.10.10.3 Adresse: 10.10.10.3 # 53 Alias: 115.10.10.10.in-addr.arpa pointeur de nom de domaine acajou.mordor.fan.

buzz @ sysadmin: ~ $ host -t Un acajou 10.10.10.5
En utilisant le serveur de domaine: Nom: 10.10.10.5 Adresse: 10.10.10.5 # 53 Alias: acajou.mordor.fan a l'adresse 10.10.10.115

buzz @ sysadmin: ~ $ host 10.10.10.115 10.10.10.5
En utilisant le serveur de domaine: Nom: 10.10.10.5 Adresse: 10.10.10.5 # 53 Alias: 115.10.10.10.in-addr.arpa pointeur de nom de domaine acajou.mordor.fan.

Maintenant oui. Quel beau synchronisme pour deux serveurs DNS non synchronisés, non?

Clients Windows joints au domaine Active Directory®

Unissons le client acajou.mordor.fan au domaine, mais pas avant d'éliminer la modification que nous avons apportée à la configuration de votre carte réseau, si à un moment donné nous l'avons fait pour vérifier le point du chapitre précédent. Supprimez également l'entrée pour «acajou»Dans le Microsoft® DNS, et renvoyer les mises à jour dynamiques à leur point d'origine de «Sécurisé uniquement«. À propos, il est valide de redémarrer le service Microsoft® DNS.

Après avoir rejoint le Domaine, et malgré tous nos efforts, le client «acajou»N'est pas enregistré dans Microsoft® DNS. Nous avons même déclaré dans le dnsmasq.conf -temporaire- que le premier serveur DNS est 10.10.10.3.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Tous les droits sont réservés.

C: \ Utilisateurs \ saruman> ipconfig / all

Nom d'hôte de configuration IP Windows. . . . . . . . . . . . : Suffixe DNS primaire MAHOGANY. . . . . . . : Type de nœud mordor.fan. . . . . . . . . . . . : Routage IP hybride activé. . . . . . . . : Aucun proxy WINS activé. . . . . . . . : Pas de liste de recherche de suffixes DNS. . . . . . : Adaptateur Ethernet mordor.fan Connexion au réseau local: Suffixe DNS spécifique à la connexion. : mordor.fan Description. . . . . . . . . . . : Adresse physique de la connexion réseau Intel (R) PRO / 1000 MT. . . . . . . . . : 00-0C-29-D6-14-36 DHCP activé. . . . . . . . . . . : Oui Autoconfiguration activée. . . . : Oui Adresse IPv6 de liaison locale. . . . . : fe80 :: 352a: b954: 7eba: 963e% 12 (préféré) Adresse IPv4. . . . . . . . . . . : 10.10.10.115 (préféré) Masque de sous-réseau. . . . . . . . . . . : 255.255.255.0 Bail obtenu. . . . . . . . . . : Samedi 25 février 2017 8:19:05 Le bail expire. . . . . . . . . . : Samedi 25 février 2017 4:20:36 Passerelle par défaut. . . . . . . . . : 10.10.10.253 Serveur DHCP. . . . . . . . . . . : 10.10.10.5 IAID DHCPv6. . . . . . . . . . . : 251661353 DUID client DHCPv6. . . . . . . . : 00-01-00-01-20-3B-69-81-00-0C-29-D6-14-36

   Serveurs DNS. . . . . . . . . . . : 10.10.10.3
                                       10.10.10.5
   NetBIOS sur Tcpip. . . . . . . . : Adaptateur de tunnel activé isatap.mordor.fan: État du média. . . . . . . . . . . : Média déconnecté Suffixe DNS spécifique à la connexion. : mordor.fan Description. . . . . . . . . . . : Adresse physique de l'adaptateur Microsoft ISATAP. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP activé. . . . . . . . . . . : Pas de configuration automatique activée. . . . : Oui Adaptateur de tunnel Connexion au réseau local * 9: État du média. . . . . . . . . . . : Média déconnecté Suffixe DNS spécifique à la connexion. : La description. . . . . . . . . . . : Adresse physique de l'adaptateur de tunnel Microsoft Teredo. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP activé. . . . . . . . . . . : Pas de configuration automatique activée. . . . : Et c'est

C: \ Utilisateurs \ saruman>

buzz @ sysadmin: ~ $ host -t Un acajou.mordor.fan 10.10.10.3
Utilisation du serveur de domaine: Nom: 10.10.10.3 Adresse: 10.10.10.3 # 53 Alias: Hôte caoba.mordor.fan introuvable: 3 (NXDOMAIN)

buzz@sysadmin: ~ $ host -t Vers acajou.mordor.fan
mahogany.mordor.fan a l'adresse 10.10.10.115

• La seule façon dont le client est enregistré «acajou»Dans Microsft® DNS modifie votre carte réseau comme indiquéó dans l'image précédente, c'est-à-dire en déclarant explicitement que: le suffixe DNS de la connexion est mordor.fan, qu'il enregistre l'adresse de la connexion dans DNS et qu'il utilise le suffixe DNS déclaré lors de l'enregistrement de la connexion.

buzz @ sysadmin: ~ $ host -t Un acajou.mordor.fan 10.10.10.3
En utilisant le serveur de domaine: Nom: 10.10.10.3 Adresse: 10.10.10.3 # 53 Alias: acajou.mordor.fan a l'adresse 10.10.10.115

buzz @ sysadmin: ~ $ host -t Un acajou.mordor.fan
mahogany.mordor.fan a l'adresse 10.10.10.115

Changeons le nom de «acajou» en «cèdre»

buzz @ sysadmin: ~ $ host -t Un acajou.mordor.fan 10.10.10.3
Utilisation du serveur de domaine: Nom: 10.10.10.3 Adresse: 10.10.10.3 # 53 Alias: Hôte caoba.mordor.fan introuvable: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t Vers cedar.mordor.fan 10.10.10.3
En utilisant le serveur de domaine: Nom: 10.10.10.3 Adresse: 10.10.10.3 # 53 Alias: cedro.mordor.fan a l'adresse 10.10.10.115

buzz @ sysadmin: ~ $ host -t Un acajou.mordor.fan 10.10.10.5
Utilisation du serveur de domaine: Nom: 10.10.10.5 Adresse: 10.10.10.5 # 53 Alias: Hôte caoba.mordor.fan introuvable: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t Vers cedar.mordor.fan 10.10.10.5
En utilisant le serveur de domaine: Nom: 10.10.10.5 Adresse: 10.10.10.5 # 53 Alias: cedro.mordor.fan a l'adresse 10.10.10.115

Et tout est normal, comme les clients Microsoft® et Microsoft® DNS aiment les choses.

Travaillons avec Microsoft® DHCP et Microsoft® DNS

Chers lecteurs, ce chapitre sort du contexte d'un blog dédié aux logiciels libres. Consultez l'aide de Microsoft®. Ils ne croient pas?. 😉

Conclusions

Il existe plusieurs façons de faire fonctionner le DNS Microsoft® lorsque nous le faisons coexister dans un réseau de PME avec le Dnsmasq. Parmi eux, nous ne mentionnerons que les suivants:

• Arrêtez complètement le service Microsoft® DNS sur l'ordinateur sur lequel il s'exécute, indiquant ensuite que le démarrage du service est désactivé. Décochez dans la configuration de la carte réseau de chaque client Microsoft® l'option Enregistrer l'adresse de connexion dans DNS. Supprimer du fichier /etc/dnsmasq.conf Directif serveur = / mordor.fan / 10.10.10.3. notes:
  • Même si les demandes concernant les enregistrements ne reçoivent pas de réponse SOA y NS, le réseau fonctionnera correctement, ainsi que l'union des différents clients -Microsoft® et Linux- au domaine Active Directory®.
  • Il a l'avantage que dans le réseau local des PME, il n'y aura qu'un seul serveur de noms de domaine - un homme - et ce sera le Dnsmasq. ;-). D'autre part, la possibilité d'incohérences entre les enregistrements DNS stockés dans Microsoft® DNS et ceux disponibles via Dnsmasq est éliminée.
• Laissez Microsoft® DNS s'exécuter pour répondre uniquement aux requêtes DNS sur les enregistrements SOA et NS. Notes:
  • Modifiez la configuration de la carte réseau de chaque client Windows, en décochant l'option Enregistrer l'adresse de la connexion dans DNS.
  • Nous pensons que cette solution est un gaspillage de ressources.
• Configurez les services comme nous l'avons vu tout au long de l'article, ce qui montre une solution plus conforme à la philosophie Microsoft® -pas FreeBSD / Linux- Ok?.

Résumé

• La proposition Microsoft® DNS est très fermée. Il ne laisse aucune place à d'autres solutions non conformes à sa philosophie hermétique.
• Mère Nature nous enseigne que nous existons dans un univers diversifié. La chose normale est d'avoir un LAN mixte, évoluant vers le Logiciel Libre, riche en vie et en variété.
• Il semble que pour Microsoft®, les clients qui ne rejoignent pas sa philosophie sont des exclus et ne devraient donc pas prendre la peine de les prendre en considération.
• Comme il est difficile de travailler avec un logiciel privé! Je préfère passer un peu de travail à configurer le logiciel libre et être vraiment libre, bon sang!

"Le meilleur critère de vérité est la pratique."