Dnsmasq és Active Directory - kkv-hálózatok

A sorozat általános mutatója: Számítógépes hálózatok kkv-k számára: Bevezetés

Hello barátok!. A cikk megértése és helyes követése lényeges elődeit olvasva:

Elmagyarázzák azokat az elméleti és gyakorlati fogalmakat, amelyekre ebben a cikkben nem fogunk hivatkozni. A terjesztést a folyó évben megváltoztatjuk Debian 8.6 "Jessie" és ugyanazokkal a paraméterekkel folytatjuk, amelyeket használunk BIND és Active Directory®.

  • Az ebben a bejegyzésben leírt eljárás a CentOS 7-re is érvényes. Az / etc / dnsmasq konfigurációs fájl ugyanaz. Kijelentem, mert feleslegesnek tartom külön cikk készítését a Dnsmasq és az Active Directory számára® a CentOS alapján. Szerencsére a dokumentációval és a konfigurációval kapcsolatos könyvtárak megegyeznek, 😉
  • A Dnsmaq a Simon Kelley

A Dnsmasq használatának korlátai

Fontossága miatt megismételjük a HATÁROK amely támogatja a Dnsmasq -runt ember dnsmasq- ami tükrözi pontosan a következő:

HATÁROK

  • Az erőforráskorlátok alapértelmezett értéke általában konzervatív, és megfelelő az útválasztó típusú eszközökön való használatra. ragadt a lassú processzorokkal és kevés memóriával. Hardverben többet  képes növelni a határokat, és még sok más támogatást nyújtani ügyfelek. A következő a dnsmasq-2.37-re vonatkozik: a korábbi verziók nem olyan jól felmásztak.
  • A Dnsmasq képes legalább ezer (1,000) DNS és DHCP támogatására ügyfelek. A bérleti idők nem lehetnek túl rövidek (kevesebb, mint egy idő). A –dns-forward-max értéke növelhető: kezdje az ügyfelek számának megfelelő összeg, és növelje, ha a DNS. Vegye figyelembe, hogy a DNS teljesítménye a kiszolgálóktól is függ Upstream DNS. A DNS gyorsítótár mérete növelhető: a határ Szükséges 10,000 150 név, és az alapértelmezett (1) nagyon alacsony. Ha egy SIGUSRXNUMX-et elküld a dnsmasq-nak, akkor bitacore-információk lesznek hasznos a gyorsítótár méretének finombeállításához. A részletekért lásd a MEGJEGYZÉSEK részt.
  • A beépített TFTP szerver képes támogatni a többszörös átvitelt egyidejű fájlok: az abszolút korlát a folyamathoz engedélyezett fájlkezelők számához és a rendszerek képességéhez kapcsolódikA hívás kiválasztása () nagyszámú fájlkezelő támogatásához. Ha a határérték túl magasra van állítva a –tftp-max paranccsal, akkor a méretarány megszűnik, és a tényleges határértéket az indításkor időzítik. Vegye figyelembe, hogy több átutalás lehetségesek, amikor ugyanazt a fájlt küldik, amikor minden egyes transza ferencia más fájlt küld. A dnsmasq használatával megtagadhatja az internetes hirdetést egy lista segítségével jól ismert szalagkiszolgálók, amelyek 127.0.0.1 vagy 0.0.0.0 az / etc / hosts fájlban vagy egy további hosts fájlban. A lista lehet legyen nagyon hosszú. A Dnsmasq millió névvel sikeresen tesztelt. Ehhez a fájlmérethez 1 GHz-es processzor szükséges, és hozzávetőleges60 MB RAM.
  • A Dnsmasq képes legalább ezer (1,000) DNS és DHCP támogatására ügyfelek.

Telepítsük és konfiguráljuk a Jessie-t és a Dnsmasq-ot

A szerver új és tiszta telepítéséből indulunk ki Debian 8 "Jessie". Vagyis az operációs rendszer grafikus felület vagy más csomag telepítése nélkül. A hálózati paraméterek megegyeznek a cikkben használtakkal BIND és Active Directory®:

Domain név mordor.fan LAN hálózat 10.10.10.0/24 ======================================= ============================================ Szerverek IP-címe Windows) ================================================= ===============================
sauron.mordor.ventilátor. 10.10.10.3 Active Directory® 2008 SR2
mamba.mordor.fan. 10.10.10.4 Windows fájlszerver
dns.mordor.fan 10.10.10.5 DnsMasq Server Jessie-n
darklord.mordor.ventilátor. 10.10.10.6 Proxy, átjáró és tűzfal a Kerios troll.mordor.fan oldalon. 10.10.10.7 A ... alapú blog nem emlékszem a shadowftp.mordor.fan fájlra. 10.10.10.8 FTP-kiszolgáló blackelf.mordor.fan. 10.10.10.9 Teljes e-mail szolgáltatás blackspider.mordor.fan. 10.10.10.10 WWW szolgáltatás palantir.mordor.fan. 10.10.10.11 Chat Openfire for Windows Real rendszeren CNAME ============================= Sauron AD-DC Mamba fájlkiszolgáló darklord proxyweb troll blog shadowftp ftpserver blackelf mail blackspider www palantir openfire

A dns.mordor.fan szerver kezdeti beállításai

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

root @ dns: ~ # nano / etc / hosts
127.0.0.1 localhost 10.10.10.5 dns.mordor.fan dns # A következő sorok kívánatosak az IPv6-kompatibilis gépek számára: 1 localhost ip6-localhost ip6-loopback ff02 :: 1 ip6-allnodes ff02 :: 2 ip6-allrouters

root @ dns: ~ # nano / etc / network / interfaces
# Ez a fájl leírja a rendszeren elérhető hálózati interfészeket # és azok aktiválását. További információ: interfészek (5). forrás /etc/network/interfaces.d/* # A visszacsatolt hálózati interfész automatikus lo iface lo inet visszacsatolás # Az elsődleges hálózati interfész allow-hotplug eth0 iface eth0 inet statikus cím 10.10.10.5 netmask 255.255.255.0 hálózati 10.10.10.0 broadcast 10.10.10.255. 10.10.10.1 átjáró 127.0.0.1 A # dns- * opciókat a resolvconf csomag valósítja meg, ha telepítve van a dns-nameservers XNUMX dns-search mordor.fan

Telepítsük a Dnsmasq-ot és a htop-ot

root @ dns: ~ # aptitude telepítse a dnsmasq htopot

A csomag telepítése után htop ellenőrizhetjük a berendezés processzorát és memóriafelhasználását. Csak körülbelül 71 megabájt RAM-ot emésztett fel. Ha még jobban szeretnénk csökkenteni a fogyasztást, telepíthetjük a csomagot SSMTP -egyszerű MTA- ami viszont megtisztítja a csomagot Példa4 hogy a Debian alapértelmezés szerint mindig telepít, és amire valójában nincs szükségünk a szervernek adott felhasználás szerint:

root @ dns: ~ # aptitude install ssmtp
root @ dns: ~ # alkalmassági tisztítás ~ c
root @ dns: ~ # alkalmasság tiszta
root @ dns: ~ # aptitude autoclean
root @ dns: ~ # systemctl újraindítás

A számítógép újraindítása után a fogyasztás a következő: Dnsmasq és az Active Directory

Alacsony, igaz? Menjünk tovább.

Jelezzük, hogy a Dnsmasq konzultál a Microsft® DNS-sel is

A számítógépen a lehetséges Dnsmasq konfigurációk teszteléséhez dns.mordor.fan, tartalmaznunk kell egy nyilatkozatot, amely jelzi, hogy a kiszolgáló Microsoft DNS-ét keresték meg sauron.mordor.ventilátor. Megtehetjük az irányelvet is beleértve szerver = / mordor.fan / 10.10.10.3 az archívumban dnsmasq.conf -amint később látni fogjuk- vagy hozzáadjuk a sort nameserver 10.10.10.3 az archívumban / Etc / resolv.conf. Mivel még nem konfiguráltuk a Dnsmasq-ot az igényeinknek megfelelően, a második utat választjuk:

root @ dns: ~ # nano /etc/resolv.conf
domain mordor.fan
nameserver 127.0.0.1
nameserver 10.10.10.3

Most már megoldhatjuk a DNS-lekérdezéseket

A Dnsmasq alapértelmezett konfigurációjával, amelyet a fő fájl biztosít /etc/dnasmq.conf, és az állományban deklaráltakkal / Etc / resolv.conf magától a szervertől «dns«, Bármely kliens, amely csatlakozik a LAN-hoz, és DNS-kiszolgálóként nyilatkozott dns.mordor.fan- megoldhatja a DNS-lekérdezéseket a Microsoft® DNS költségén átmenetileg…

  • Nagyon fontos ellenőrizni a Dnsmasq válaszsebességét, amikor állapotát jeleníti meg előmozdító az IP 10.10.10.3 puszta felvételével a fájljába / Etc / resolv.conf.

Az adminisztrációs munkaállomásomtól és az összes kellék támogatásától, amelyen keresztül írok, futok:

buzz @ sysadmin: ~ $ cat /etc/resolv.conf 
# A NetworkManager domain által generált mordor.fan névkiszolgáló 10.10.10.5

buzz @ sysadmin: ~ $ nslookup
> dns
Szerver: 10.10.10.5 Cím: 10.10.10.5 # 53 Név: dns.mordor.fan Cím: 10.10.10.5

> Sauron
Szerver: 10.10.10.5 Cím: 10.10.10.5 # 53

Nem mérvadó válasz:
Név: sauron.mordor.fan Cím: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
Szerver: 10.10.10.5 Cím: 10.10.10.5 # 53 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan kanonikus név = sauron.mordor.fan. Név: sauron.mordor.fan Cím: 10.10.10.3

> 10.10.10.3
Szerver: 127.0.0.1 Cím: 127.0.0.1 # 53 3.10.10.10.in-addr.arpa name = sauron.mordor.fan.

> 10.10.10.9
Szerver: 127.0.0.1 Cím: 127.0.0.1 # 53 9.10.10.10.in-addr.arpa name = blackelf.mordor.fan.

> 10.10.10.5
Szerver: 127.0.0.1 Cím: 127.0.0.1 # 53 5.10.10.10.in-addr.arpa name = dns.mordor.fan.

> mail
Szerver: 10.10.10.5 Cím: 10.10.10.5 # 53 Nem hiteles válasz: mail.mordor.fan kanonikus név = blackelf.mordor.fan. Név: blackelf.mordor.fan Cím: 10.10.10.9> exit

buzz @ sysadmin: ~ $

Vizsgáljuk meg közelebbről a következő szempontokat:

  • dns.mordor.fan közvetlenül válaszol azokra a DNS-lekérdezésekre, amelyeket a jelenlegi Dnsmasq-beállítások szerint megoldhat. Ha nem tudja megoldani őket, úgy működik előmozdító és megkérdezi az IP 10.10.10.3 IP-t, hogy képes-e válaszolni a lekérdezésre. Amikor a készülék IP-címét kérik «dns«, Közvetlenül válaszol. Amikor a Dnsmasq-tól megkérdezik, ki az «Sauron",?, készítsen szállítmányozás a 10.10.10.3 -Nem válaszolhat közvetlenül, mert még nem regisztrálta- ki ad vissza egy helyes, nem autoriter választ.
  • Amikor megkérdezik, ki a «03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan"?, készítsen szállítmányozás Ismét hiteles választ kap a Microsoft® DNS-től.
  • A Dnsmasq nagy válaszsebessége bármilyen típusú lekérdezéshez.

Apró részletek, amelyek nagyszerűvé teszik a szerelmet ;-).

Alapvető különbségek az Active Directory®-ba integrált Dnsmasq és BIND között

Futtassunk pár DNS-lekérdezést a rekordokon SOA y NS a domain mordor.ventilátor, minden érintett névszervernek:

buzz @ sysadmin: ~ $ host -t SOA mordor.fan 10.10.10.3
Tartománykiszolgáló használata: Név: 10.10.10.3 Cím: 10.10.10.3 # 53 Álnevek: 
A mordor.fan rendelkezik SOA rekord sauron.mordor.fan névvel. hostmaster.mordor.fan. 56 900 600 86400 3600 XNUMX

buzz @ sysadmin: ~ $ host -t SOA mordor.fan 10.10.10.5
Tartománykiszolgáló használata: Név: 10.10.10.5 Cím: 10.10.10.5 # 53 Álnevek: 
A mordor.fan rendelkezik SOA rekord sauron.mordor.fan névvel. hostmaster.mordor.fan. 56 900 600 86400 3600 XNUMX

buzz @ sysadmin: ~ $ host -t NS mordor.fan 10.10.10.5
Tartománykiszolgáló használata: Név: 10.10.10.5 Cím: 10.10.10.5 # 53 Álnevek: 
mordor.fan névkiszolgáló sauron.mordor.fan.

buzz @ sysadmin: ~ $ host -t NS mordor.fan 10.10.10.3
Tartománykiszolgáló használata: Név: 10.10.10.3 Cím: 10.10.10.3 # 53 Álnevek: 
mordor.fan névkiszolgáló sauron.mordor.fan.

A válaszok azonosak - ami logikus -, mert mindig válaszoljon sauron.mordor.ventilátor. DNS-lekérdezés előtt a rekordokkal kapcsolatban SOA o NS, Bár látszik mit válaszol dns.mordor.fan. Ez azonban eltér a cikkben láthatóaktól BIND és Active Directory®, ahol teljesen eltávolítottuk a Microsoft® DNS funkcióit. Ebben a cikkben MINDEN DNS-lekérdezés a Domino névtérről mordor.ventilátor A BIND válaszolt nekik, mert mi így konfiguráltuk, és mert a BIND válaszol a lekérdezésekre SOA y NS a rendszer engedélyezése mellett Mesterszolga, Zónaátvitel stb., És ezért teljesebb DNS-kiszolgáló - komplex.

Talán ezek a fő különbségek a Dnsmasq és a BIND DNS között ... de BIND - mindig lehet egy vagy több, de nincs DHCP szerver, amely zökkenőmentesen integrálódik a DNS szerverrel egyetlen démonés anélkül, hogy TSIG kulcsokra, konfigurációs fájlokra, zóna adatbázisokra stb. lenne szükség, amint azt az előző cikkekben láthattuk.

  • Azt hiszem, hogy a Kedves Olvasók mostanra rájöttek, hogy nem utálom a BIND-t, és nem is a Dnsmasq-ot kedvelem a BIND-vel szemben. A róla folytatott jövőbeli beszélgetések teljes időpazarlás, mivel sok köze van az igényekhez, igényekhez, ízléshez, preferenciákhoz és .... minden megoldásnak megvan a maga varázsa ;-).
  • Hasonló esetekben mindenki telepítse és konfigurálja az általa választott szoftvert, amelyről többet tud. és hogy minden a várt módon működik.

A Dnsmasq + Active Directory® kombináció előnyei

Ezzel a kombinációval teljes választ kínálunk a DNS-lekérdezésekre, és hatékony eszközöket kínálunk az IP-címek bérlésére a kkv-k LAN számára. Mint később látni fogjuk, minden helyzetben helyesen működik, függetlenül attól, hogy a számítógép csatlakozik-e a Microsoft® Active Directory® tartományvezérlőhöz. Ezen felül van egy DNS és DNS szerverünk előmozdító par excellence, plusz egy nagyon gyors DHCP szerver. És mindez kevés erőforrásigénnyel. Kérsz ​​még?

Lehetséges a Dnsmasq + BIND?

Határozottan igen. Bár azt javaslom, hogy különböző számítógépekre telepítsék őket, hogy ne történjenek ütközések a DNS-szolgáltatás nagyon szeretett 53-as portja miatt. Talán látni fogunk róla valamit, amikor eljutunk a Samba 4 alapú AD-DC-be. Ki tudja?

Tippek a Dnamasq-hoz

  • A Dnsmasq számára a DHCP- és DNS-szolgáltatások LAN-on történő biztosításához elengedhetetlen munkafájlok a következők: /etc/dnsmasq.conf, / Etc / hosts, /var/lib/misc/dnsmasq.leasing, És / Etc / resolv.conf. A fájl dnsmasq.bérleteket az első IP-cím bérbeadásakor jön létre.
  • Egy másik munkafájl, amelyet használhat / etc / éterek. Ha létezik ilyen fájl, akkor az irányelv olvasó-éterek deklarálva a config fájlban, felszólítja a Dnsmasqot, hogy olvassa el. Nagyon hasznos, ha viszonyulunk egymáshoz MAC-címek / hosztnevek bizonyos célokra.
  • A DNS-szolgáltatást az irányelv segítségével teljesen letilthatják port = 0 a dnsmasq.conf.
  • Az egy vagy több hálózati csatoló DHCP szolgáltatását irányelvekkel lehet letiltani - minden vonalon egy-egy no-dhcp-interface = eth0, no-dhcp-interface = eth1, stb. Nagyon hasznos, ha egy 2 vagy több hálózati interfésszel rendelkező csapat előtt állunk, és azt akarjuk, hogy a DHCP szolgáltatást csak egyikük vagy egyikük nyújtsa. Természetesen, ha minden felületen letiltjuk a DHCP szolgáltatást, akkor csak a DNS szolgáltatást hagyjuk futva. Ha letiltjuk mindkét szolgáltatást, akkor miért van szükségünk a Dnsmasq-ra? 😉
  • Nyilatkozni más DNS-tartománynév-kiszolgálóknak, hogy nem nyilvánosak vagy a LAN-on kívül vannak - mint a Microsoft DNS esetében - az irányelv révén tesszük szerver = / domain név / DNS szerver IP az archívumban /etc/dnsmasq.conf. például: szerver = / mordor.fan / 10.10.10.3.
  • Ha azt akarjuk mondani a Dnsmasq-nak, hogy a helyi domainekkel kapcsolatos kérdésekre csak a fájl válaszol / Etc / hosts vagy a DHCP-n keresztül hozzá kell adnunk az irányelvet helyi = / localnet / a konfiguráció fő fájljában. Példa: helyi = / mordor.fan /.
  • A fájl megfelelő konfigurálásához / Etc / resolv.conf - rezolverkábel javasoljuk, hogy olvassa el a kézikönyvet a parancs segítségével férfi resolv.conf. Ha telepíti a Debian 8.6 "Jessie" -t, akkor azt találja, hogy jól meg van írva spanyolul.
  • A Dnsmasq nem használja a Zónák fájlokat a közvetlen vagy visszakérdezések megválaszolásához.
  • Az egyes mezők jelentésének megismerése «speciális»Ezt az SRV erőforrásrekord deklarációjában használják, konzultáljon BIND és Active Directory®. Az SRV rekordok szintaxisa a fájlban /etc/dnsmasq.conf Ez a következő:
    srv-host = , , , ,

Olvasók, akik többet akarnak tudni, kérjük, olvassák el figyelmesen az eredeti fájlt /etc/dnsmasq.conf vagy a könyvtárban lévő meglévő dokumentumokat / usr / share / doc / dnsmasq-base.

root @ dns: ~ # ls -l / usr / share / doc / dnsmasq-base /
összesen 128 -rw-r - r-- 1 gyökérgyökér 883 5. május 2015. copyright -rw-r - r-- 1 gyökérgyökér 36261 5 2015. május 1. changelog.archive.gz -rw-r - r-- 11297 gyökérgyökér 5 2015. május 1. changelog.Debian.gz -rw-r - r-- 26014 gyökérgyökér 5 2015. május 1. changelog.gz -rw-r - r-- 2084 gyökérgyökér 5 2015. május 1. DBus-interface. Gz -rw- r - r-- 4297 gyökérgyökér 5 2015. május 2. doc.html drwxr-xr-x 4096 gyökérgyökér 19 február 17. 52:1 példa -rw-r - r-- 9721 gyökérgyökér 5 2015. május 1. GYIK.gz -rw -r - r-- 4180 gyökérgyökér 5 2015. május 1. README.Debian -rw-r - r-- 12019 gyökérgyökér 5 2015. május XNUMX. setup.html

Konfiguráljuk a Dnsmasq-ot és a Resolver-t

Kezdeti útmutatóként vesszük figyelembe - természetesen a nevek és mások megváltoztatását - a cikkben használt konfigurációs fájlt «Dnsmasq a CentOS 7.3-on”.

Ne felejtsük el a következő lépést:

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

Fix IP-címek

A fix IP-t igénylő szerverek vagy berendezések címei IPv4 mint IPv6- szerepelnek az aktában / Etc / hosts:

[root @ dns ~] # nano / etc / hosts
127.0.0.1 localhost # Az alábbi sorok kívánatosak az IPv6-kompatibilis gépek számára: 1 localhost ip6-localhost ip6-loopback ff02 :: 1 ip6-allnodes ff02 :: 2 ip6-allrouters # Szerverek és számítógépek fix IP-vel. 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

Hozzuk létre az /etc/dnsmasq.conf fájlt

[root @ dns ~] # nano /etc/dnsmasq.conf
# ------------------------------------------------- ------------------ # ÁLTALÁNOS OPCIÓK # ---------------------------- - -------------------------------------- domain szükséges # Ne adjon át neveket domain nélkül rész hamis-priv # Ne adja át a címeket az irányítatlan térben expand-hosts # Tartomány automatikus hozzáadása a gazdagéphez = eth0 # Interfész.  VIGYÁZZA az interfészt # kivétel-interfész = eth1 # NE hallgassa meg ezt a szigorú NIC-sorrendű # sorrendet, amelyben az /etc/resolv.conf fájlt keresse meg további egy könyvtárban # conf-file = / etc / dnsmasq.more.conf conf-dir = / etc / dnsmasq.d # Tartománynévre vonatkozó domain = mordor.fan # Domain név # Időkiszolgáló értéke 10.10.10.1. 10.10.10.1 address = / time.windows.com / XNUMX # Üres opciót küld a WPAD értékből.  Szükséges a # Windos 7 és újabb kliensek megfelelő viselkedéséhez.  ;-) dhcp-option = 252, "\ n" # Fájl, ahol kijelentjük azokat a HOSTS-okat, amelyek "tiltva" lesznek. addn-hosts = / etc / banner_add_hosts # Forduljon a Microsoft® DNS-kiszolgálóhoz "sauron", ha # engedjük run server = / mordor.fan / 10.10.10.3 # A helyi domainekkel kapcsolatos kérdésekre # / / etc / hosts vagy a helyi DHCP-n keresztül válaszolunk = / mordor.fan / # A PTR vagy Reverse rekordokra vonatkozó kérdésekre a kiszolgálók # választ adnak " dns "és" sauron "abban a sorrendben szerver = / 10.10.10.in-addr.arpa / 10.10.10.5 szerver = / 10.10.10.in-addr.arpa / 10.10.10.3 # ------- - ------------------------------------------------- - --------- # REGISTROSCNAMEMXTXT # ------------------------------------- - ----------------------------- # Ehhez a regisztrációhoz meg kell adni egy # bejegyzést az / etc / hosts # fájlban, pl .: 10.10.0.7. 10 troll.mordor.fan troll # cname = ALIAS, REAL_NAME cname = ad-dc.mordor.fan, sauron.mordor.fan cname = fájlszerver.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 # Visszaad egy MX rekordot a "mordor.fan" névvel # rendeltetéssel a blackelf.mordor.fan csapatnak és 10 mx-host = mordor.fan, mail prioritással. mordor.fan, XNUMX # A localmx opcióval # létrehozott MX rekordok alapértelmezett rendeltetési helye a következő lesz: mx-target = mail.mordor.fan # Visszaad egy MX rekordot, amely az összes # helyi localmx gép # TXT rekord mx-targetre mutat. 

dhcp-rental-max = 222 # A bérelhető címek maximális száma
                        # alapértelmezés szerint 150
# IPV6 tartomány # dhcp-range = 1234 ::, csak ra # Opciók a 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 # DNS-kiszolgálók dhcp-option = 19,1, mordor.fan # DNS-tartománynév dhcp-option = 28,10.10.10.255 # opció ip-továbbítás BE 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 # NetBIOS datagrammak # dhcp-option = XNUMX # Finger Server # dhcp-option = XNUMX # NetBIOS csomópont dhcp-mérvadó # Hiteles DHCP az alhálózatban # ------------- -------------------------------------------------- ---- # --------------------------------------------- ---------------------- # LOGGING tail -f / var / log / syslog vagy journalctl -f # ------------ -------------------------------------------------- ----- log-queries # ----------------------------------------- -------------------------- # Újra A és SRV rekordok, amelyek megfelelnek az Active Directory # ----------------------------------------- --------------------------
# Feljegyzések A
address = / gc._msdcs.mordor.fan / 10.10.10.3 address = / DomainDnsZones.mordor.fan / 10.10.10.3 address = / ForestDnsZones.mordor.fan / 10.10.10.3

# Microsoft DNS zóna CNAME rekord _msdcs.mordor.fan
cname=03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan,sauron.mordor.fan

# SRV rekord
# srv-host = , , , ,

# Globális katalógus # Microsoft DNS zóna _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
# Microsoft DNS zóna 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

# Az Active Directory módosított és privát LDAP-ja
# Microsoft DNS zóna _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
# Microsoft DNS zóna 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 módosított és privát egy Active Directory-ból
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

# Az /etc/dnsmasq.conf fájl VÉGE
# ------------------------------------------------- ------------------

Hozzuk létre az / etc / banner_add_host fájlt

[root @ dns ~] # nano / etc /banner_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 - teszt
dnsmasq: a szintaxis ellenőrzése OK.

[root @ dns ~] # systemctl indítsa újra a dnsmasq.service szolgáltatást 
[root @ dns ~] # systemctl állapot dnsmasq.service

Módosítsuk az /etc/resolv.conf - Resolver fájlt

root @ dns: ~ # nano /etc/resolv.conf 
domain mordor.fan keresés mordor.fan

Miért nincsenek a fájlban deklarált szokásos sorok? solve.conf? Mert kijelentjük a dnsmasq.conf a következő irányelvek:

# Forduljon a "sauron" Microsoft® DNS-kiszolgálóhoz, ha # hagyjuk futni
szerver = / mordor.fan / 10.10.10.3

# A helyi domainekkel kapcsolatos kérdésekre # / etc / hosts vagy DHCP-n keresztül válaszolunk
helyi = / mordor.fan /

# A PTR vagy a Reverse rekordokkal kapcsolatos kérdésekre a "dns" és a "sauron" szerverek válaszolnak # abban a sorrendben
szerver = / 10.10.10.in-addr.arpa / 10.10.10.5 kiszolgáló = / 10.10.10.in-addr.arpa / 10.10.10.3

Lekérdezések a sysadmin.mordor.fan webhelyről

A fájl / Etc / resolv.conf ennek a csapatnak:

buzz @ sysadmin: ~ $ cat /etc/resolv.conf
# A NetworkManager által generált keresés mordor.fan névkiszolgáló 10.10.10.5
buzz @ sysadmin: ~ $ host -t A spynet4.microsoft.com címre
A spynet4.microsoft.com címe 127.0.0.1

buzz @ sysadmin: ~ $ host -t A www.download.windowsupdate.com webhelyre
A www.download.windowsupdate.com címe 127.0.0.1

zümmögés@sysadmin: ~ $ dig dns
buzz @ sysadmin: ~ $ dig dns.mordor.fan
;; KÉRDÉS SZEKCIÓ :; dns.mordor.fan. A-ban ;; VÁLASZ SZEKCIÓ: dns.mordor.fan. 0 IN A 10.10.10.5

buzz @ sysadmin: ~ $ host -t SRV _ldap._tcp.gc._msdcs
buzz @ sysadmin: ~ $ host -t SRV _ldap._tcp.gc._msdcs.mordor.fan
A _ldap._tcp.gc._msdcs.mordor.fan SRV rekordja 0 0 3268 sauron.mordor.fan.

buzz @ sysadmin: ~ $ dig _ldap._tcp.gc._msdcs.mordor.fan
;; KÉRDÉSSZEKCIÓ :; _ldap._tcp.gc._msdcs.mordor.fan. A-ban ;; VÁLASZ SZEKCIÓ: _ldap._tcp.gc._msdcs.mordor.fan. 0 IN A 10.10.10.3

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

Így hány konzultációra van szükségünk

Dnsmasq + Active Directory® + Microsoft® Windows kliensek

Microsoft® Windows Client átnevezése

hét.mordor.ventilátor bérelt IP-cím:

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

Nevezzük át a «hét»-Ami nem csatlakozik az Active Directory tartományhoz-«eukaliptusz«. A változás és az újraindítás után ellenőrizzük:

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

A változások története a "sysadmin" oldalon látható:

buzz @ sysadmin: ~ $ host -t A hét
A seven.mordor.fan címe 10.10.10.115

A névváltoztatás után

buzz @ sysadmin: ~ $ host -t A hét
hétnek nincs A rekordja

buzz @ sysadmin: ~ $ host -t A eukaliptus
Az eucaliptus.mordor.fan címe 10.10.10.115

Lekérdezések az eucaliptus.mordor.fan kliensről

Microsoft Windows [verziószám 6.1.7601]
Szerzői jog (c) 2009 Microsoft Corporation. Minden jog fenntartva.

C: \ Users \ buzz> nslookup
Alapértelmezett kiszolgáló: dns.mordor.fan Cím: 10.10.10.5

> sauron
Szerver: dns.mordor.fan Cím: 10.10.10.5 Név: sauron.mordor.fan Cím: 10.10.10.3

> mordor.fan
Szerver: dns.mordor.fan Cím: 10.10.10.5 Név: mordor.fan Cím: 10.10.10.3

> eukaliptusz
Szerver: dns.mordor.fan Cím: 10.10.10.5 Név: eucaliptus.mordor.fan Cím: 10.10.10.115

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
Szerver: dns.mordor.fan Cím: 10.10.10.5 Név: sauron.mordor.fan Cím: 10.10.10.3 Álnevek: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> set type = SRV
> _kerberos._udp.mordor.fan
Szerver: dns.mordor.fan Cím: 10.10.10.5 _kerberos._udp.mordor.fan SRV szolgáltatás helye: prioritás = 0 súly = 0 port = 88 svr hosztnév = sauron.mordor.fan sauron.mordor.fan internetcím = 10.10.10.3. XNUMX

> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan
Szerver: dns.mordor.fan Cím: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan SRV szolgáltatás helye: prioritás = 0 súly = 0 port = 389 svr hosztnév = sauron .mordor.fan sauron.mordor.fan internetcím = 10.10.10.3

> kilépés

C: \ Felhasználók \ buzz>

Windows ügyfelek regisztrációja a Microsoft® DNS-ben

Windows kliensek nem csatlakoztak az Active Directory® tartományhoz

Ellenőriznünk kell, hogy a különböző Windows kliensek által a Dnsmasq-tól bérelt IP-címek megfelelően vannak-e regisztrálva a Microsoft® DNS-ben. Befolyásolhatja ahogy bekapcsoljuk a dinamikus frissítéseket - Dinamikus frissítések az Active Directory® Microsoft® DNS zónáiban. A Microsoft DNS alapértelmezett konfigurációjából indulunk ki, amely csak biztonságos dinamikus frissítéseket engedélyez - Dinamikus frissítések -> Csak biztonságos, minden zónájában.

Vegye figyelembe, hogy az ügyfél az aktuális FQDN eucalyptus.mordor.fan nem az Active Directory tartományhoz (vagy egy Samba4 AD-DC) csatolva van, és kivétel a Microsoft szabályától, amely szerint «Csak a Saját domainben regisztrált klienseknek lesz engedélyem a Saját frissítési mechanizmusomon keresztül - amelyet csak én tudok - regisztrálni a Saját DNS-be«. Szerencsére a Samba4 AD-DC tanít nekünk valamit.

eukaliptusz.mordor.fan bérelt IP 10.10.10.115:

buzz @ sysadmin: ~ $ host -t A eukaliptus
Az eucaliptus.mordor.fan címe 10.10.10.115

Változtassuk meg a nevét «mahagóni«, Indítsuk újra a Windows 7-et, és nézzük meg, mi történik, amikor a neveket kérjük«eukaliptusz»Y«mahagóni»Mindegyik DNS-hez először a Microsoft DNS-hez, majd a Dnsmasq-hoz:

buzz @ sysadmin: ~ $ host -t A eucaliptus.mordor.fan 10.10.10.3
Tartománykiszolgáló használata: Név: 10.10.10.3 Cím: 10.10.10.3 # 53 Álnevek: 

Az eucaliptus.mordor.fan gazdagép nem található: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t A mahagóni.mordor.fan 10.10.10.3
Tartománykiszolgáló használata: Név: 10.10.10.3 Cím: 10.10.10.3 # 53 Álnevek: 

A mahagóni.mordor.fan gazdagép nem található: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t A eucaliptus.mordor.fan 10.10.10.5
Tartománykiszolgáló használata: Név: 10.10.10.5 Cím: 10.10.10.5 # 53 Álnevek: 

Az eucaliptus.mordor.fan gazdagép nem található: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t A mahagóni.mordor.fan 10.10.10.5
Tartománykiszolgáló használata: Név: 10.10.10.5 Cím: 10.10.10.5 # 53 Álnevek: 

mahagóni.mordor.fan címe 10.10.10.115

Megváltoztathatjuk a Windows 7 kliens nevét nem a Tartományhoz van csatolva mordor.ventilátor annyiszor, ahányszor csak szeretnénk, hogy a Microsoft® DNS ne tudjon meg ezekről a változásokról, vagy hogy létezzen ilyen ügyfél. Lehetséges, hogy csak azért, mert kiválasztottuk az opciót  Dinamikus frissítések -> Csak biztonságos a Micorosft DNS minden zónájában?

Ahhoz, hogy a Microsoft® DNS tudjon a változásokról, ki kell választanunk Dinamikus frissítések -> Nem biztonságos és biztonságos. Ez a lehetőség, Tisztelt Olvasók, jelentős biztonsági rést jelent minden olyan tartománynév-kiszolgáló biztonságában, amelyet tiszteletben tartanak, legyen az Microsft® vagy UNIX® / Linux. A Microsoft® DNS figyelmeztet a sebezhetőségre, mert végül nem más, mint egy módosított és privatizált BIND, amely felajánlja nekünk «Biztonság a sötétségért«. Ha nem, miért javasolja spórolni híres hírein bejegyzés az Microsoft® DNS összes DNS-beállítását és rekordját, amikor Active Directory®-t implementálunk? A Microsoft® DNS nem biztonságos frissítésének támogatásán túl a következő módosításra van szükség a Windows 7 ügyfél hálózati kártya konfigurációjában:

Nézzük meg:

buzz @ sysadmin: ~ $ host -t A mahagóni.mordor.fan 10.10.10.3
Tartománykiszolgáló használata: Név: 10.10.10.3 Cím: 10.10.10.3 # 53 Álnevek: caoba.mordor.fan címe 10.10.10.115

buzz @ sysadmin: ~ $ host 10.10.10.115 10.10.10.3
Tartománykiszolgáló használata: Név: 10.10.10.3 Cím: 10.10.10.3 # 53 Álnevek: 115.10.10.10.in-addr.arpa tartománynévmutató mahagóni.mordor.fan.

buzz @ sysadmin: ~ $ host -t A mahagóni 10.10.10.5
Tartománykiszolgáló használata: Név: 10.10.10.5 Cím: 10.10.10.5 # 53 Álnevek: caoba.mordor.fan címe 10.10.10.115

buzz @ sysadmin: ~ $ host 10.10.10.115 10.10.10.5
Tartománykiszolgáló használata: Név: 10.10.10.5 Cím: 10.10.10.5 # 53 Álnevek: 115.10.10.10.in-addr.arpa tartománynévmutató mahagóni.mordor.fan.

Igen, most. Milyen szép szinkronizálás két, semmiképp sem szinkronizált DNS-kiszolgáló számára, igaz?

Windows kliensek csatlakoztak az Active Directory® tartományhoz

Egyesítsük az ügyfelet mahagóni.mordor.ventilátor a Domainhez, de nem a hálózati kártya konfigurációjában végrehajtott módosítás kiküszöbölése előtt, ha valamikor megtettük az előző fejezet pontjának ellenőrzésére. Törölje a «mahagóni»A Microsoftban® DNS-t, és állítsa vissza a dinamikus frissítéseket a «Csak biztonságos«. Egyébként érvényes a Microsoft szolgáltatás újraindítása® DNS.

Miután csatlakozott a Domainhez és minden erőfeszítésünk ellenére az ügyfél «mahagóni»Nincs regisztrálva a Microsoft® DNS-ben. Még a dnsmasq.conf -temporary- hogy az első DNS szerver 10.10.10.3.

Microsoft Windows [verziószám 6.1.7601]
Szerzői jog (c) 2009 Microsoft Corporation. Minden jog fenntartva.

C: \ Users \ saruman> ipconfig / all

A Windows IP konfigurációs gazdagép neve. . . . . . . . . . . . : MAHOGANY Elsődleges Dns utótag. . . . . . . : mordor.fan Csomópont típusa. . . . . . . . . . . . : Hibrid IP-útválasztás engedélyezve. . . . . . . . : Nincs engedélyezve a WINS proxy. . . . . . . . : Nincs DNS utótag keresési lista. . . . . . : mordor.fan Ethernet adapter Helyi kapcsolat: Csatlakozás-specifikus DNS-utótag. : mordor.fan Leírás. . . . . . . . . . . : Intel (R) PRO / 1000 MT hálózati kapcsolat fizikai címe. . . . . . . . . : 00-0C-29-D6-14-36 DHCP engedélyezve. . . . . . . . . . . : Igen Az automatikus konfiguráció engedélyezve. . . . : Igen Link-local IPv6-cím. . . . . : fe80 :: 352a: b954: 7eba: 963e% 12 (Előnyben részesített) IPv4-cím. . . . . . . . . . . : 10.10.10.115 (Előnyben részesített) alhálózati maszk. . . . . . . . . . . : 255.255.255.0 Lízing megszerzése. . . . . . . . . . : 25. február 2017., szombat 8:19:05 A bérleti idő lejár. . . . . . . . . . : 25. február 2017., szombat 4:20:36 Alapértelmezett átjáró. . . . . . . . . : 10.10.10.253 DHCP-kiszolgáló. . . . . . . . . . . : 10.10.10.5 DHCPv6 IAID. . . . . . . . . . . : 251661353 DHCPv6 kliens DUID. . . . . . . . : 00-01-00-01-20-3B-69-81-00-0C-29-D6-14-36

   DNS szerverek. . . . . . . . . . . : 10.10.10.3
                                       10.10.10.5
   NetBIOS a Tcpip felett. . . . . . . . : Engedélyezett alagút adapter isatap.mordor.fan: Médiaállapot. . . . . . . . . . . : Média leválasztva Kapcsolat-specifikus DNS utótag. : mordor.fan Leírás. . . . . . . . . . . : Microsoft ISATAP adapter fizikai címe. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP engedélyezve. . . . . . . . . . . : Nincs engedélyezve az automatikus konfiguráció. . . . : Igen Alagútadapter Helyi kapcsolat * 9: Adathordozó állapota. . . . . . . . . . . : Média leválasztva Kapcsolat-specifikus DNS utótag. : Leírás. . . . . . . . . . . : Microsoft Teredo Tunneling Adapter fizikai cím. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP engedélyezve. . . . . . . . . . . : Nincs engedélyezve az automatikus konfiguráció. . . . : És ez

C: \ Felhasználók \ saruman>

buzz @ sysadmin: ~ $ host -t A mahagóni.mordor.fan 10.10.10.3
Tartománykiszolgáló használata: Név: 10.10.10.3 Cím: 10.10.10.3 # 53 Álnevek: Host caoba.mordor.fan nem található: 3 (NXDOMAIN)

zümmögés@sysadmin: ~ $ host -t To mahagany.mordor.fan
mahagóni.mordor.fan címe 10.10.10.115
  • Az egyetlen mód az ügyfél regisztrálására «mahagóni»A Microsft® alkalmazásban a DNS a jelzett módon módosítja a hálózati kártyátó az előző képen, vagyis kifejezetten kijelenti, hogy: a kapcsolat DNS-utótagja a mordor.fan, hogy regisztrálja a kapcsolat címét a DNS-ben, és a deklarált DNS-utótagot használja a kapcsolat regisztrálásakor.
buzz @ sysadmin: ~ $ host -t A mahagóni.mordor.fan 10.10.10.3
Tartománykiszolgáló használata: Név: 10.10.10.3 Cím: 10.10.10.3 # 53 Álnevek: caoba.mordor.fan címe 10.10.10.115

buzz @ sysadmin: ~ $ host -t A mahagóni.mordor.fan
mahagóni.mordor.fan címe 10.10.10.115
Változtassuk meg a nevét "mahagóni" -ról "cédrus" -ra
buzz @ sysadmin: ~ $ host -t A mahagóni.mordor.fan 10.10.10.3
Tartománykiszolgáló használata: Név: 10.10.10.3 Cím: 10.10.10.3 # 53 Álnevek: Host caoba.mordor.fan nem található: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t To cedar.mordor.fan 10.10.10.3
Tartománykiszolgáló használata: Név: 10.10.10.3 Cím: 10.10.10.3 # 53 Álnevek: cedro.mordor.fan címe 10.10.10.115

buzz @ sysadmin: ~ $ host -t A mahagóni.mordor.fan 10.10.10.5
Tartománykiszolgáló használata: Név: 10.10.10.5 Cím: 10.10.10.5 # 53 Álnevek: Host caoba.mordor.fan nem található: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t To cedar.mordor.fan 10.10.10.5
Tartománykiszolgáló használata: Név: 10.10.10.5 Cím: 10.10.10.5 # 53 Álnevek: cedro.mordor.fan címe 10.10.10.115

És minden normális, mivel a Microsoft® klienseknek és a Microsoft® DNS-nek tetszik a dolog.

Dolgozzunk a Microsoft® DHCP és a Microsoft® DNS szolgáltatásokkal

Tisztelt Olvasók! Ez a fejezet nem tartozik a szabad szoftverek számára készített blog szövegkörnyezetébe. Lásd a Microsoft® súgóját. Nem hiszik? 😉

Következtetések

Számos módja van a Microsoft® DNS-sel való együttműködésnek, amikor egy kkv-hálózatban a Dnsmasq-szal együtt élünk. Közülük csak a következőket említjük:

  • Állítsa le teljesen a Microsoft® DNS szolgáltatást azon a számítógépen, ahol fut, utólag jelezve, hogy a szolgáltatás indítása le van tiltva. Törölje a jelet az egyes Microsoft® kliensek hálózati kártyájának konfigurációjában arról a lehetőségről, hogy a kapcsolat címét regisztrálja a DNS-be. Eltávolítás a fájlból /etc/dnsmasq.conf Irányelv szerver = / mordor.fan / 10.10.10.3. jegyzetek:
    • Még akkor is, ha a nyilvántartásokkal kapcsolatos kérdésekre nem válaszolunk SOA y NS, a hálózat megfelelően fog működni, valamint a különböző kliensek - a Microsoft és a Linux - egyesülése az Active Directory® tartományhoz.
    • Előnye, hogy a kkv LAN-ban csak egy Domain Name Server lesz - férfi férfi - és a Dnsmasq lesz. ;-). Másrészt kiküszöböli a következetlenségek lehetőségét a Microsoft® DNS-ben tárolt és a Dnsmasq-on keresztül elérhető DNS-rekordok között.
  • Hagyja futni a Microsoft® DNS-t, hogy csak a SOA és NS rekordokkal kapcsolatos DNS-kérdésekre válaszoljon. jegyzets:
    • Módosítsa az egyes Windows-ügyfelek hálózati kártyáinak konfigurációját, törölve a kapcsolat címének DNS-be történő regisztrálásának jelölését.
    • Azt gondoljuk hogy ez a megoldás az erőforrások pazarlása.
  • Konfigurálja a szolgáltatásokat, amint azt a cikkben láttuk, ami inkább a Microsoft® filozófiájának tetsző megoldást mutat - nem a FreeBSD / Linux- Ok?

Összegzés

  • A Microsoft® DNS javaslata nagyon lezárt. Nem hagy teret más olyan megoldásoknak, amelyek nincsenek összhangban a hermetikus filozófiájával.
  • Az Anyatermészet arra tanít minket, hogy sokféle univerzumban létezünk. A normális dolog az, hogy vegyes LAN-ja van, a szabad szoftver felé halad, és gazdag az élete és a változatossága.
  • Úgy tűnik, hogy a Microsoft® számára azok az ügyfelek, akik nem csatlakoznak a filozófiájához, kitaszítottak, ezért nem szabad fáradozniuk, hogy figyelembe vegyék őket.
  • Milyen nehéz dolgozni a privát szoftverrel! Inkább töltenék egy kis munkát a Szabad Szoftver felállításával, és valóban szabad lennék, a fenébe!

"Az igazság legjobb kritériuma a gyakorlat."


Hagyja megjegyzését

E-mail címed nem kerül nyilvánosságra. Kötelező mezők vannak jelölve *

*

*

  1. Az adatokért felelős: Miguel Ángel Gatón
  2. Az adatok célja: A SPAM ellenőrzése, a megjegyzések kezelése.
  3. Legitimáció: Az Ön beleegyezése
  4. Az adatok közlése: Az adatokat csak jogi kötelezettség alapján továbbítjuk harmadik felekkel.
  5. Adattárolás: Az Occentus Networks (EU) által üzemeltetett adatbázis
  6. Jogok: Bármikor korlátozhatja, helyreállíthatja és törölheti adatait.

  1.   Zodiac Carburus dijo

    Remek cikk, amit írtál, Federico!

  2.   Julio Leon dijo

    Óriási cikk kedvesem. És az összefoglaló a legjobb XD
    Mérlegek;

  3.   gyík dijo

    Nem hiszem, hogy láttam volna egy teljesebb és részletesebb útmutatót a sysadmin számára az interneten (spanyol nyelven), az a munka, amelyet a Networks for SME-nek végez, az a keret.

    Bár a munka nehézkes, és ennek a részletességnek az elérése sok óra kérdése, úgy gondolom, hogy létrehoz egy referenciapontot, amelyet felhasználni fog, amint az sok SysAdmin számára ismertté válik, amelyek sokak számára kulcsot jelentenek a cikktanárban a mindennapos tevékenységek közül.

    Ami a dnsmasq-ot és az aktív könyvtárat illeti, azt hiszem, soha nem volt lehetőségem mindkettővel dolgozni, de a laboratóriumomban, egy Windows kliens hiányában, úgy tűnik, minden rendben volt, és nem csoda, hogy ezzel a kiváló lépéssel lépés.

    Mentsd meg a következő mondatodat: "Milyen nehéz dolgozni a Private Software szoftverrel! Inkább töltenék egy kis munkát a Szabad Szoftver konfigurálásával, és valóban szabadok lennék, a fene egye meg! »... Tegyük fel, hogy egy kis munkát az ingyenes szoftver konfigurálásával egy időre kihagyok, főleg az Önéhez hasonló dokumentumokhoz és sok más embertől, hogyan is a szabad szoftverek állandó humanizálásával.

    Gratulálok FIco ... Továbblépünk.

  4.   Federico dijo

    Zodiákus: A szavaid ösztönzik az írás folytatását. Ne habozzon, sok jó órát - fenékre van szükség egy ilyen szerény cikk megírásához.

    Julio León: Üdvözlet téged is, kedves Julio. Remélhetőleg, és folytatja velünk az utat, hogy kicsit többet tudjon meg a szabad szoftverről.

    Lagarto: A eltöltött napok és órák megérdemlik, amikor a hozzászóláshoz hasonló kommenteket olvasok. Ők a legjobb jutalom munkánkért. A cikk linkjét magának Simon Kelley-nek adtam át, és kedves volt válaszolni nekem.

    Ezt a helyet kihasználva szeretném elmondani, hogy a DNS és DHCP kérdésben stratégiánként kezdjük a komplexustól a könnyűig. A Dnsmasq nagyon érvényes megoldás a SME Networks számára, és sokkal könnyebben megvalósítható, mint a BIND + Isc-Dhcp-Server duó. A téma sok olvasó számára kissé technikának tűnhet. Idővel és gyakorlattal rájönnek, hogy ez nem így van. Érdemes tanulmányozni az Infrastructure Server alapelveit, egy címet, amely felölelné a DNS és DHCP szolgáltatásokról írt 6 cikket, az NTP elfelejtése nélkül.

    Gratulálok mindenkinek ... Továbblépünk!

  5.   IWO dijo

    Köszönet Federicónak a Dnsmasq-ról szóló újabb nagyszerű cikkért, amely hatalmas részletességgel és átfogó elmélettel rendelkezik. Ez az eszköz, amelyet már látunk, rendkívül hasznos a rendszergazdák számára.

    NAGY minden, ami a Microsoft DNS-zóna "_msdcs.mordor.fan" fájljának /etc/dnsmasq.conf konfigurációs fájljába történő beillesztésével kapcsolatos, a következő szolgáltatásokat használó SRV-rekordjaival: _gc, _ldap, _kerberos és _kpasswd, amelynek célja: a DNS-lekérdezések megoldásához a Dnsmasq ("local = / mordor.fan /" parancs) mellett a Microsoft DNS ("server = / mordor.fan / 10.10.10.3" parancs) használata a Dnsmasq mellett.

    A GREAT az a példa is, amelyet arra fejlesztettek ki, hogy ahhoz, hogy a Microsoft DNS regisztrálhassa a Windows klienseket az IP-változtatásokkal a LAN-ban, ki kell választania a DNS-konfigurációban a "Dinamikus frissítéseket" "Nem biztonságos és biztonságos" -ként, és azt, hogy ez mit jelent a biztonsági rés sebezhetőségében. minden olyan tartománynév-kiszolgáló biztonsága, amelyet tiszteletben tartanak, legyen az Microsoft vagy UNIX / Linux. Amellett, hogy szükséges a Windows kliens hálózati kártya konfigurációjának módosítása.
    Semmi, hogy minden új bejegyzéssel felveti a megállót! Izgatottan várja a következő cikkeket!

    1.    Federico dijo

      Nagyon köszönöm értékelését és észrevételeit, IWO. Minden publikált cikkemben mindig várom a véleményét, mivel foglalkozása, tudása és gyakorlata alátámasztja. Gratulálok az IWO-nak. A következő cikkben találkozunk

  6.   vadász dijo

    Nagyon jó munka, mint mindig ezeket a drágaköveket feladni a rendszergazdáknak. Köszönöm ezer!

  7.   crespo88 dijo

    Adjon esélyt a Microsoft DNS-ének, még csak nem is engedte, hogy megjelenjen. Nem tudjuk, hogy életben van-e még, és nem is maradt-e szégyene. Kiváló cikk.

  8.   HO2Gi dijo

    Olyan ékszer, amilyet senki más, konzultáció céljából a kedvencek közé ment. Kiváló cikk.

  9.   Federico dijo

    HO2Gi köszönöm az értékelést. Javaslom -és általában MINDENKINEK- látogasson el https://blog.desdelinux.net/redes-computadoras-las-pymes-introduccion/. Újra szerkesztették az összes közzétett bejegyzés és a megvitatandó témák indexével. Üdvözlet és folytassa velünk.

  10.   Paul Andrew Flemmer dijo

    Kiváló dokumentum, mint amely elérhető https://blog.desdelinux.net/bind-active-directory/
    Csak ajánlást szeretnék tenni, és kérem, vegye konstruktív kritikának; A konfiguráció példájára jobb lett volna, ha a 10.10.10.0/24 hálózat használata helyett olyat használ, ahol minden blokknak más-más száma van, például a 192.168.1.0/24 hálózat.
    Ez világosabbá tenné, hogy a hálózati címek hol fordulnak meg fordítva, például amikor hozzá kell adni az ".in-addr.arpa" típusú értékeket
    Köszönjük, hogy ennyi jó minőségű tudást megosztott.
    Üdvözlettel.