Dnsmasq и Active Directory - МСП мрежи

Общ индекс на поредицата: Компютърни мрежи за МСП: Въведение

Здравейте приятели!. За да разберете и следвате правилно тази статия е съществен четене на своите предшественици:

Те обясняват теоретични и практически концепции, на които няма да се позоваваме в тази. Ще променим разпределението през текущата година на Debian 8.6 "Джеси" и ще продължим със същите параметри, които използваме в BIND и Active Directory®.

  • Процедурата, описана в тази публикация, е валидна и за CentOS 7. Конфигурационният файл / etc / dnsmasq е същият. Декларирам го, защото считам за ненужно да се прави отделна статия за Dnsmasq и Active Directory® базиран на CentOS. За щастие директориите, свързани с документацията и конфигурацията, са еднакви, 😉
  • Dnsmaq е творение на Саймън Кели

Ограничения за използването на Dnsmasq

Поради важността му повтаряме ГРАНИЦИ който поддържа Dnsmasq -run човек dnsmasq- което отразява екзактаменте следващият:

ГРАНИЦИ

  • Стойностите по подразбиране за ограниченията на ресурсите обикновено са консервативни и подходящи за използване на устройства от типа рутер. заседнал с бавни процесори и малко памет. В хардуера повече  способни, е възможно да увеличите лимитите и да подкрепите много повече клиенти. Следното се отнася за dnsmasq-2.37: предишните версии не те се изкачиха толкова добре.
  • Dnsmasq е способен да поддържа DNS и DHCP поне една хиляда (1,000) клиенти. Сроковете за наем не трябва да бъдат твърде кратки (по-малко от един време). Стойността на –dns-forward-max може да бъде увеличена: започнете с еквивалента на броя на клиентите и да го увеличите, ако DNS. Имайте предвид, че производителността на DNS също зависи от сървърите DNS нагоре по веригата. Размерът на DNS кеша може да бъде увеличен: ограничението Необходими са 10,000 150 имена, а по подразбиране (1) е много ниско. Изпращането на SIGUSRXNUMX до dnsmasq прави bitacore информация, която е Полезно за фина настройка на размера на кеша. За подробности вижте раздела ЗАБЕЛЕЖКИ.
  • Вграденият TFTP сървър може да поддържа множество трансфери едновременни файлове: абсолютната граница е свързана с броя на манипулаторите на файлове, разрешени за даден процес и възможността на sys‐tem call select (), за да поддържа голям брой манипулатори на файлове. Ако лимитът е зададен твърде висок с –tftp-max, той ще бъде де-мащабиран и действителният лимит ще бъде тактиран при стартиране. Имайте предвид, че повече трансфери са възможни, когато се изпраща един и същ файл какво, когато всеки трансferencia изпраща различен файл. Възможно е да използвате dnsmasq, за да откажете уеб рекламирането, като използвате списък с добре познати банерни сървъри, всички разрешаващи до 127.0.0.1 или 0.0.0.0 в / etc / hosts или в допълнителен файл за хостове. Списъкът може бъдете много дълги. Dnsmasq е успешно тестван с милион имена. Този размер на файла се нуждае от 1 GHz процесор и приблизително60MB RAM.
  • Dnsmasq е способен да поддържа DNS и DHCP поне една хиляда (1,000) клиенти.

Нека инсталираме и конфигурираме Jessie и Dnsmasq

Ще започнем с нова и чиста инсталация на сървър, базиран на Debian 8 "Джеси". С други думи, операционната система без инсталиран графичен интерфейс или друг пакет. Мрежовите параметри ще бъдат същите като тези, използвани в статията BIND и Active Directory®:

Име на домейн mordor.fan LAN мрежа 10.10.10.0/24 ==================================== == =========================================== Сървъри IP адрес Цел (Сървъри с ОС Windows ) ================================================== = ================================
sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2
mamba.mordor.fan. 10.10.10.4 Файлов сървър на Windows
dns.mordor.fan 10.10.10.5 DnsMasq сървър на Jessie
darklord.mordor.fan. 10.10.10.6 Прокси, шлюз и защитна стена на Kerios troll.mordor.fan. 10.10.10.7 Блог, базиран на ... не мога да си спомня shadowftp.mordor.fan. 10.10.10.8 FTP сървър blackelf.mordor.fan. 10.10.10.9 Пълна услуга за електронна поща blackspider.mordor.fan. 10.10.10.10 WWW услуга palantir.mordor.fan. 10.10.10.11 Чат на Openfire за Windows Real CNAME ============================== sauron ad-dc mamba файлов сървър darklord proxyweb troll blog shadowftp ftpserver blackelf поща blackspider www palantir openfire

Първоначални настройки на 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 # Следните редове са желателни за IPv6 поддържащи хостове :: 1 localhost ip6-localhost ip6-loopback ff02 :: 1 ip6-allnodes ff02 :: 2 ip6-allrouters

root @ dns: ~ # nano / etc / network / interfaces
# Този файл описва мрежовите интерфейси, налични във вашата система # и как да ги активирате. За повече информация вижте интерфейси (5). source /etc/network/interfaces.d/* # Мрежовият интерфейс за обратна връзка auto lo iface lo inet loopback # Основният мрежов интерфейс allow-hotplug eth0 iface eth0 inet статичен адрес 10.10.10.5 netmask 255.255.255.0 мрежа 10.10.10.0 излъчване 10.10.10.255. 10.10.10.1 шлюз 127.0.0.1 # dns- * опциите се реализират от пакета resolvconf, ако са инсталирани dns-nameservers XNUMX dns-search mordor.fan

Нека инсталираме Dnsmasq и htop

root @ dns: ~ # aptitude инсталирайте dnsmasq htop

След инсталиране на пакета htop можем да проверим процесора и консумацията на памет на оборудването. Консумираше само около 71 мегабайта RAM. Ако искаме да намалим още повече потреблението, можем да инсталираме пакета SSMTP -прост MTA- което от своя страна продухва опаковката exim4 че Debian винаги се инсталира по подразбиране и че наистина нямаме нужда според употребата, която ще дадем на този сървър:

root @ dns: ~ # aptitude инсталирайте ssmtp
root @ dns: ~ # изчистване на способността ~ c
root @ dns: ~ # aptitude clean
root @ dns: ~ # aptitude autoclean
root @ dns: ~ # systemctl рестартиране

След рестартиране на компютъра консумацията е както следва: Dnsmasq и Active Directory

Ниско, нали? Да продължим.

Нека посочим, че Dnsmasq също се консултира с DNS на Microsft®

За да тествате възможните Dnsmasq конфигурации на вашия компютър dns.mordor.fan, ние трябва да включим изявление, което показва, че Microsoft DNS на сървъра е консултиран sauron.mordor.fan. Можем да го направим, включително директивата сървър = / mordor.fan / 10.10.10.3 в архива dnsmasq.conf -как ще видим по-късно- или добавяне на реда сървър 10.10.10.3 в архива / И т.н. / resolv.conf. Тъй като все още не сме конфигурирали Dnsmasq според нашите нужди, ние избираме втория начин:

root @ dns: ~ # nano /etc/resolv.conf
домейн mordor.fan
сървър 127.0.0.1
сървър 10.10.10.3

Вече можем да разрешаваме DNS заявки

С конфигурацията по подразбиране на Dnsmasq, предоставена от основния му файл /etc/dnasmq.conf, и с това, което е декларирано във файла / И т.н. / resolv.conf от самия сървър «DNS«, Всеки клиент, свързан към LAN-и който е декларирал като DNS сървър dns.mordor.fan- можете да разрешавате DNS заявки за сметка на Microsoft® DNS за сега…

  • Много е важно да се провери скоростта на реакция на Dnsmasq, когато се показва състоянието му като експедитор само чрез включване на IP 10.10.10.3 във вашия файл / И т.н. / resolv.conf.

От моята административна работна станция и поддръжката на всички принадлежности, чрез които пиша, стартирам:

buzz @ sysadmin: ~ $ cat /etc/resolv.conf 
# Генерирано от домейн NetworkManager mordor.fan сървър за имена 10.10.10.5

buzz @ sysadmin: ~ $ nslookup
> DNS
Сървър: 10.10.10.5 Адрес: 10.10.10.5 # 53 Име: dns.mordor.fan Адрес: 10.10.10.5

> Саурон
Сървър: 10.10.10.5 Адрес: 10.10.10.5 # 53

Неавторитетен отговор:
Име: sauron.mordor.fan Адрес: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
Сървър: 10.10.10.5 Адрес: 10.10.10.5 # 53 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan канонично име = sauron.mordor.fan. Име: sauron.mordor.fan Адрес: 10.10.10.3

> 10.10.10.3
Сървър: 127.0.0.1 Адрес: 127.0.0.1 # 53 3.10.10.10.in-addr.arpa name = sauron.mordor.fan.

> 10.10.10.9
Сървър: 127.0.0.1 Адрес: 127.0.0.1 # 53 9.10.10.10.in-addr.arpa name = blackelf.mordor.fan.

> 10.10.10.5
Сървър: 127.0.0.1 Адрес: 127.0.0.1 # 53 5.10.10.10.in-addr.arpa name = dns.mordor.fan.

> поща
Сървър: 10.10.10.5 Адрес: 10.10.10.5 # 53 Неавторитетен отговор: mail.mordor.fan канонично име = blackelf.mordor.fan. Име: blackelf.mordor.fan Адрес: 10.10.10.9> изход

buzz @ sysadmin: ~ $

Нека разгледаме по-отблизо следните аспекти:

  • dns.mordor.fan директно отговаря на DNS заявки, които може да разреши според вашите текущи настройки на Dnsmasq. Ако не можете да ги разрешите, това работи като експедитор и пита IP 10.10.10.3 дали може да отговори на заявката. Когато бъдете попитани за IP на оборудването «DNS«, Той отговаря директно. Когато Dnsmasq бъде попитан кой е «Саурон",?, направи спедиция с 10.10.10.3 -Не можете да отговорите директно, защото все още не сте го регистрирали- който връща верен неавторитарен отговор.
  • На въпрос кой е «03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan"?, направи спедиция отново и този път получавате авторитетен отговор от Microsoft® DNS.
  • Високата скорост на реакция на Dnsmasq за всеки тип заявка.

Те са малки детайли, които правят любовта страхотна ;-).

Основни разлики между Dnsmasq и BIND, интегрирани с Active Directory®

Нека изпълним няколко DNS заявки в записите SOA y NS на домейна mordor.фен, към всеки от участващите сървъри на имена:

buzz @ sysadmin: ~ $ host -t SOA mordor.fan 10.10.10.3
Използване на сървър на домейн: Име: 10.10.10.3 Адрес: 10.10.10.3 # 53 Псевдоними: 
mordor.fan има SOA запис sauron.mordor.fan. hostmaster.mordor.fan. 56 900 600 86400 3600 XNUMX

buzz @ sysadmin: ~ $ host -t SOA mordor.fan 10.10.10.5
Използване на сървър на домейн: Име: 10.10.10.5 Адрес: 10.10.10.5 # 53 Псевдоними: 
mordor.fan има SOA запис sauron.mordor.fan. hostmaster.mordor.fan. 56 900 600 86400 3600 XNUMX

buzz @ sysadmin: ~ $ host -t NS mordor.fan 10.10.10.5
Използване на сървър на домейн: Име: 10.10.10.5 Адрес: 10.10.10.5 # 53 Псевдоними: 
сървър за имена на mordor.fan sauron.mordor.fan.

buzz @ sysadmin: ~ $ host -t NS mordor.fan 10.10.10.3
Използване на сървър на домейн: Име: 10.10.10.3 Адрес: 10.10.10.3 # 53 Псевдоними: 
сървър за имена на mordor.fan sauron.mordor.fan.

Отговорите са идентични - което е логично - защото винаги отговори sauron.mordor.fan. преди DNS заявка за записи SOA o NS, Въпреки че изглеждат какво отговаря dns.mordor.fan. Въпреки това се различава от това, което се вижда в статията BIND и Active Directory®, където бяхме напълно премахнали функционалността на Microsoft® DNS. В тази статия ВСИЧКИ DNS заявки за Domino пространство на имена mordor.фен BIND им отговори, защото ние го конфигурирахме по този начин и защото BIND отговаря на запитвания SOA y NS освен че позволява схемата Господар - роб, Zone transfer и т.н., и следователно това е по-пълен DNS сървър - сложен.

Може би това са основните разлики между DNS на Dnsmasq и BIND ... но BIND - винаги може да има едно или повече, но няма DHCP сървър, който да се интегрира безпроблемно с DNS сървър в един демонд, и без необходимост от TSIG ключове, конфигурационни файлове, бази данни на зони и т.н., както видяхме в предишни статии.

  • Мисля, че до този момент, Уважаеми читатели, ще осъзнаете, че не мразя BIND, нито предпочитам Dnsmasq пред BIND. Бъдещите дискусии за него са пълна загуба на време, тъй като има много общо с нуждите, исканията, вкусовете, предпочитанията и .... всяко решение има своя чар ;-).
  • В подобни сценарии всеки инсталира и конфигурира софтуера по свой избор и за който знае повече. и че всичко работи както се очаква.

Предимства на комбинацията Dnsmasq + Active Directory®

С тази комбинация имаме пълната гама от отговори на DNS запитвания и ефективно средство за наемане на IP адреси за нашата МСП LAN. Както ще видим по-късно, той работи правилно за всяка ситуация относно това дали компютърът е свързан към Microsoft® Active Directory® Domain Controller. Освен това имаме DNS и DNS сървър експедитор par excellence, плюс много бърз DHCP сървър. И всичко това с малко търсене на ресурси. Искаш ли още?

Възможно ли е Dnsmasq + BIND?

Определено да. Въпреки че препоръчвам те да бъдат инсталирани на различни компютри, така че да няма сблъсъци поради много обичания порт 53 на DNS услугата. Може би и ще видим нещо по въпроса, когато стигнем до базиран на Samba AD-DC 4. Кой знае?

Съвети за Dnamasq

  • Основните работни файлове за Dnsmasq за предоставяне на DHCP и DNS услуги в LAN са: /etc/dnsmasq.conf, / Etc / hosts, /var/lib/misc/dnsmasq.leasesИ / И т.н. / resolv.conf. Файлът dnsmasq.leases създава се, когато наемете първия си IP адрес.
  • Друг файл за работа, който можете да използвате, е / и т.н. / етери. Ако такъв файл съществува, директивата четец-етери деклариран в конфигурационния файл, казва на Dnsmasq да го прочете. Много е полезно, когато се свързваме MAC адреси / имена на хостове за определени цели.
  • DNS услугата може да бъде напълно деактивирана с помощта на директивата порт = 0 в dnsmasq.conf.
  • DHCP услугата за един или повече мрежови интерфейси може да бъде деактивирана чрез директиви-един за всяка линия- no-dhcp-interface = eth0, no-dhcp-interface = eth1, и така нататък. Много полезно, когато сме пред екип с 2 или повече мрежови интерфейси и искаме DHCP услугата да се предоставя само от един от тях или от никой. Разбира се, ако деактивираме DHCP услугата за всички интерфейси, ще оставим само DNS услугата да работи. Ако деактивираме и двете услуги, тогава защо се нуждаем от Dnsmasq? 😉
  • За да декларирате пред други DNS сървъри на имена на домейни, че Не. са публични или външни за LAN - както в случая с Microsoft DNS - ние го правим чрез директивата сървър = / име на домейн / IP на DNS сървър в архива /etc/dnsmasq.conf, например: сървър = / mordor.fan / 10.10.10.3.
  • За да кажете на Dnsmasq, че на запитвания за локални домейни се отговаря само от файла / Etc / hosts или чрез вашия DHCP, трябва да добавим директивата local = / localnet / в основния файл на вашата конфигурация. Пример: местно = / mordor.fan /.
  • За да конфигурирате правилно файла / И т.н. / resolv.conf - резолвера предлагаме да прочетете ръководството му с помощта на командата човек резолют.конф. Ако инсталирате Debian 8.6 "Jessie", ще откриете, че той е добре написан на испански.
  • Dnsmasq не използва файлове със зони, за да отговаря на директни или обратни заявки.
  • Да знаем значението на всяко поле «специален»Това се използва в декларацията на SRV Resource Record, трябва да се консултирате BIND и Active Directory®. Синтаксисът на SRV записите във файла /etc/dnsmasq.conf Това е както следва:
    srv-хост = , , , ,

Читатели, които искат да знаят повече, моля, прочетете внимателно оригиналния файл /etc/dnsmasq.conf или съществуващи документи в директорията / usr / share / doc / dnsmasq-base.

root @ dns: ~ # ls -l / usr / share / doc / dnsmasq-base /
общо 128 -rw-r - r - 1 корен корен 883 5 май 2015 авторско право -rw-r - r - 1 корен корен 36261 5 2015 май 1 changelog.archive.gz -rw-r - r - 11297 корен корен 5 2015 май 1 г. changelog.Debian.gz -rw-r - r– 26014 корен корен 5 2015 май 1 г. changelog.gz -rw-r - r– 2084 корен root 5 2015 май 1 DBus-интерфейс. Gz -rw- r - r - 4297 корен корен 5 2015 май 2 г. doc.html drwxr-xr-x 4096 корен корен 19 февруари 17 52:1 примери -rw-r - r - 9721 корен корен 5 2015 май 1 FAQ.gz -rw -r - r - 4180 корен root 5 2015 май 1 README.Debian -rw-r - r - 12019 корен root 5 2015 май XNUMX setup.html

Нека конфигурираме Dnsmasq и Resolver

Ще вземем като първоначално ръководство - смяна на имена и т.н., разбира се - конфигурационния файл, използван в статията «Dnsmasq на CentOS 7.3".

Нека не забравяме следващата стъпка:

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

Фиксирани IP адреси

Адресите на сървърите или оборудването, които изискват фиксиран IP-двата IPv4 като IPv6- са декларирани във файла / Etc / hosts:

[root @ dns ~] # nano / etc / hosts
127.0.0.1 localhost # Следните редове са желателни за IPv6 поддържащи хостове :: 1 localhost ip6-localhost ip6-loopback ff02 :: 1 ip6-allnodes ff02 :: 2 ip6-allrouters # Сървъри и компютри с фиксирани IP адреси. 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

Нека създадем файла /etc/dnsmasq.conf

[root @ dns ~] # nano /etc/dnsmasq.conf
# ------------------------------------------------- ------------------ # ОБЩИ ОПЦИИ # ---------------------------- - ---------------------------------------необходим домейн # Не предавайте имена без домейна част фалшив-priv # Не предавайте адреси в нерутирано пространство expand-hosts # Автоматично добавяне на домейн към интерфейса на хоста = eth0 # Интерфейс.  ВНИМАНЕТЕ на интерфейса # освен-интерфейс = eth1 # НЕ слушайте този NIC строг ред # Поръчка, в която се консултирате с файла /etc/resolv.conf # Включете много повече опции за конфигуриране # чрез файл или като намерите конфигурацията файлове допълнителни в директория # conf-file = / etc / dnsmasq.more.conf conf-dir = / etc / dnsmasq.d # Относно домейн Име домейн = mordor.fan # Име на домейн # Сървърът на времето е 10.10.10.1. 10.10.10.1 address = / time.windows.com / XNUMX # Изпраща празна опция от стойността на WPAD.  Изисква се за # Windos 7 и по-нови клиенти, за да се държат правилно.  ;-) dhcp-option = 252, "\ n" # Файл, в който ще декларираме ХОСТОВЕ, които ще бъдат "забранени" addn-hosts = / etc / banner_add_hosts # Консултирайте се с Microsoft® DNS сървъра "sauron", ако # позволим run server = / mordor.fan / 10.10.10.3 # На запитвания за локални домейни ще се отговаря # от / etc / hosts или чрез локален DHCP = / mordor.fan / # На запитвания за PTR или обратни записи ще се отговаря # от сървърите " dns "и" sauron "в този ред сървър = / 10.10.10.in-addr.arpa / 10.10.10.5 сървър = / 10.10.10.in-addr.arpa / 10.10.10.3 # ------- - ------------------------------------------------- - --------- # REGISTROSCNAMEMXTXT # ------------------------------------- - ----------------------------- # Този тип регистрация изисква запис # във файла / etc / hosts #, напр .: 10.10.0.7. 10 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 # Връща MX запис с името "mordor.fan", предназначен # за екипа на blackelf.mordor.fan и приоритет 10 mx-host = mordor.fan, поща. mordor.fan, XNUMX # Дестинацията по подразбиране за MX записи, които се създават # с помощта на опцията localmx ще бъде: mx-target = mail.mordor.fan # Връща MX запис, сочещ към mx-target за ВСИЧКИ # локални локални mx машини # TXT записи. 

dhcp-lease-max = 222 # Максимален брой адреси за отдаване под наем
                        # по подразбиране е 150
# IPV6 Обхват # dhcp-range = 1234 ::, ra-only # Опции за 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 сървъри dhcp-option = 19,1, mordor.fan # 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 # NetBIOS дейтаграми # dhcp-option = XNUMX # Finger Server # dhcp-option = XNUMX # NetBIOS възел dhcp-авторитетен # Авторитетен DHCP в подмрежата # ------------- -------------------------------------------------- ---- # --------------------------------------------- ---------------------- # LOGGING tail -f / var / log / syslog или journalctl -f # ------------ -------------------------------------------------- ----- регистрационни заявки # ----------------------------------------- -------------------------- # Re A и SRV записи, съответстващи на Active Directory # ----------------------------------------- --------------------------
# Записи A
адрес = / gc._msdcs.mordor.fan / 10.10.10.3 адрес = / DomainDnsZones.mordor.fan / 10.10.10.3 адрес = / ForestDnsZones.mordor.fan / 10.10.10.3

# Microsoft DNS Zone CNAME запис _msdcs.mordor.fan
cname=03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan,sauron.mordor.fan

# SRV записи
# srv-хост = , , , ,

# Глобален каталог # Microsoft DNS зона _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 зона 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 на Active Directory
# Microsoft DNS зона _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 зона 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 модифициран и частен от 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

# END на файла /etc/dnsmasq.conf
# ------------------------------------------------- ------------------

Нека създадем файла / etc / banner_add_host

[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 изтегляне.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: проверка на синтаксиса ОК.

[root @ dns ~] # systemctl рестартирайте dnsmasq.service 
[root @ dns ~] # systemctl статус dnsmasq.service

Нека модифицираме файла /etc/resolv.conf - Resolver

root @ dns: ~ # nano /etc/resolv.conf 
домейн mordor.fan търсене

Защо нямаме обичайните редове, декларирани във файла resolve.conf? Защото декларираме в dnsmasq.conf следните директиви:

# Консултирайте се с Microsoft® DNS сървъра "sauron", ако # го оставим да работи
сървър = / mordor.fan / 10.10.10.3

# На запитвания за локални домейни ще се отговаря # от / etc / hosts или чрез DHCP
местно = / mordor.fan /

# На запитвания за PTR или обратни записи ще се отговори # от "dns" и "sauron" сървърите в този ред
сървър = / 10.10.10.in-addr.arpa / 10.10.10.5 сървър = / 10.10.10.in-addr.arpa / 10.10.10.3

Заявки от sysadmin.mordor.fan

Файлът / И т.н. / resolv.conf от този екип е:

buzz @ sysadmin: ~ $ cat /etc/resolv.conf
# Генерирано от NetworkManager search mordor.fan nameserver 10.10.10.5
buzz @ sysadmin: ~ $ host -t До spynet4.microsoft.com
spynet4.microsoft.com има адрес 127.0.0.1

buzz @ sysadmin: ~ $ host -t До www.download.windowsupdate.com
www.download.windowsupdate.com има адрес 127.0.0.1

бръмча@sysadmin: ~ $ dig dns
buzz @ sysadmin: ~ $ dig dns.mordor.fan
;; РАЗДЕЛ НА ВЪПРОСА ;; dns.mordor.fan. В ;; СЕКЦИЯ ОТГОВОР: dns.mordor.fan. 0 В 10.10.10.5

buzz @ sysadmin: ~ $ host -t SRV _ldap._tcp.gc._msdcs
buzz @ sysadmin: ~ $ host -t SRV _ldap._tcp.gc._msdcs.mordor.fan
_ldap._tcp.gc._msdcs.mordor.fan има SRV запис 0 0 3268 sauron.mordor.fan.

buzz @ sysadmin: ~ $ dig _ldap._tcp.gc._msdcs.mordor.fan
;; ВЪПРОСЕН РАЗДЕЛ :; _ldap._tcp.gc._msdcs.mordor.fan. В ;; ОТГОВОР СЕКЦИЯ: _ldap._tcp.gc._msdcs.mordor.fan. 0 В А 10.10.10.3

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

И по този начин колко консултации се нуждаем

Dnsmasq + Active Directory® + Microsoft® Windows клиенти

Преименуване на клиент на Microsoft® Windows

седем.mordor.fan нает IP адрес:

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

Нека преименуваме «седем»-Което не е присъединено към домейна на Active Directory- от«евкалипт«. След промяната и рестартирането проверяваме:

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

Историята на промените може да се види от "sysadmin":

buzz @ sysadmin: ~ $ host -t Седем
seven.mordor.fan има адрес 10.10.10.115

След смяната на името

buzz @ sysadmin: ~ $ host -t Седем
седем няма А запис

buzz @ sysadmin: ~ $ host -t Евкалипт
eucaliptus.mordor.fan има адрес 10.10.10.115

Заявки от клиента eucaliptus.mordor.fan

Microsoft Windows [Version 6.1.7601]
Авторско право (c) 2009 Microsoft Corporation. Всички права запазени.

C: \ Users \ buzz> nslookup
Сървър по подразбиране: dns.mordor.fan Адрес: 10.10.10.5

> саурон
Сървър: dns.mordor.fan Адрес: 10.10.10.5 Име: sauron.mordor.fan Адрес: 10.10.10.3

> mordor.fan
Сървър: dns.mordor.fan Адрес: 10.10.10.5 Име: mordor.fan Адрес: 10.10.10.3

> евкалипт
Сървър: dns.mordor.fan Адрес: 10.10.10.5 Име: eucaliptus.mordor.fan Адрес: 10.10.10.115

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
Сървър: dns.mordor.fan Адрес: 10.10.10.5 Име: sauron.mordor.fan Адрес: 10.10.10.3 Псевдоними: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> тип тип = SRV
> _kerberos._udp.mordor.fan
Сървър: dns.mordor.fan Адрес: 10.10.10.5 _kerberos._udp.mordor.fan Местоположение на услугата SRV: приоритет = 0 тегло = 0 порт = 88 svr име на хоста = sauron.mordor.fan sauron.mordor.fan интернет адрес = 10.10.10.3. XNUMX

> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan
Сървър: dns.mordor.fan Адрес: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan SRV местоположение на услугата: приоритет = 0 тегло = 0 порт = 389 svr хост = sauron .mordor.fan sauron.mordor.fan интернет адрес = 10.10.10.3

> излез

C: \ Потребители \ вести>

Регистрация на клиенти на Windows в Microsoft® DNS

Клиенти на Windows, които не са присъединени към домейна на Active Directory®

Трябва да проверим дали IP адресите, наети от различните клиенти на Windows от Dnsmasq, са правилно регистрирани в Microsoft® DNS. Може да повлияе начина, по който включваме динамичните актуализации - Динамични актуализации в Microsoft® DNS зони на Active Directory®. Започваме от конфигурацията по подразбиране на Microsoft DNS, която позволява само сигурни динамични актуализации - Динамични актуализации -> Само сигурно, във всяка от неговите Зони.

Имайте предвид, че клиентът с текущата FQDN eucalyptus.mordor.fan Не. е прикрепен към домейна на Active Directory (или Samba4 AD-DC) и е изключение от правилото на Microsoft, че «Само клиенти, регистрирани в моя домейн, ще имат разрешение чрез механизма ми за актуализиране - който аз само знам - да се регистрират в моя DNS«. За щастие Samba4 AD-DC ни учи на нещо по въпроса.

евкалипт.мордор.вентилатор нает IP 10.10.10.115:

buzz @ sysadmin: ~ $ host -t Евкалипт
eucaliptus.mordor.fan има адрес 10.10.10.115

Нека променим името му на «махагон«, Нека рестартираме Windows 7 и да видим какво се случва, когато поискаме имената«евкалипт»Y«махагон»За всеки от DNS, първо за DNS на Microsoft и след това за Dnsmasq:

buzz @ sysadmin: ~ $ host -t A eucaliptus.mordor.fan 10.10.10.3
Използване на сървър на домейн: Име: 10.10.10.3 Адрес: 10.10.10.3 # 53 Псевдоними: 

Хост eucaliptus.mordor.fan не е намерен: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t Махагон.mordor.fan 10.10.10.3
Използване на сървър на домейн: Име: 10.10.10.3 Адрес: 10.10.10.3 # 53 Псевдоними: 

Домакин махагон.mordor.fan не е намерен: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t A eucaliptus.mordor.fan 10.10.10.5
Използване на сървър на домейн: Име: 10.10.10.5 Адрес: 10.10.10.5 # 53 Псевдоними: 

Хост eucaliptus.mordor.fan не е намерен: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t Махагон.mordor.fan 10.10.10.5
Използване на сървър на домейн: Име: 10.10.10.5 Адрес: 10.10.10.5 # 53 Псевдоними: 

mahogany.mordor.fan има адрес 10.10.10.115

Можем да променим името на клиента на Windows 7, че Не. е прикачен към домейна mordor.фен на Active Directory® толкова пъти, колкото искаме, че Microsoft® DNS не е разбрал за тези промени или че такъв клиент съществува. Възможно ли е да е само защото сме избрали опцията  Динамични актуализации -> Само сигурно във всяка зона на DNS на Micorosft?

За да може г-н Microsoft® DNS да знае за промените, трябва да изберем Динамични актуализации -> Несигурни и сигурни. Тази опция, уважаеми читатели, предполага значителна уязвимост на сигурността на всеки сървър на имена на домейни, който се спазва, било то Microsft® или UNIX® / Linux. Microsoft® DNS предупреждава за уязвимостта, тъй като в крайна сметка не е нищо повече от модифициран и приватизиран BIND, който ни предлага «Сигурност за мрака«. Ако не, защо препоръчвате да спестите от известния си регистрация всички DNS настройки и записи на вашия Microsoft® DNS, когато внедряваме Active Directory®? В допълнение към поддържането на несигурни актуализации на Microsoft® DNS, се изисква следната модификация в конфигурацията на клиентска мрежова карта на Windows 7:

Да проверим:

buzz @ sysadmin: ~ $ host -t Махагон.mordor.fan 10.10.10.3
Използване на сървър на домейн: Име: 10.10.10.3 Адрес: 10.10.10.3 # 53 Псевдоними: caoba.mordor.fan има адрес 10.10.10.115

buzz @ sysadmin: ~ $ хост 10.10.10.115 10.10.10.3
Използване на сървър на домейн: Име: 10.10.10.3 Адрес: 10.10.10.3 # 53 Псевдоними: 115.10.10.10.in-addr.arpa указател на име на домейн mahogany.mordor.fan.

buzz @ sysadmin: ~ $ host -t Махагон 10.10.10.5
Използване на сървър на домейн: Име: 10.10.10.5 Адрес: 10.10.10.5 # 53 Псевдоними: caoba.mordor.fan има адрес 10.10.10.115

buzz @ sysadmin: ~ $ хост 10.10.10.115 10.10.10.5
Използване на сървър на домейн: Име: 10.10.10.5 Адрес: 10.10.10.5 # 53 Псевдоними: 115.10.10.10.in-addr.arpa указател на име на домейн mahogany.mordor.fan.

Да сега. Какъв хубав синхрон за два DNS сървъра, които не са синхронизирани по никакъв начин, нали?

Клиенти на Windows, присъединени към домейн на Active Directory®

Нека обединим клиента махагон.mordor.fan към домейна, но не преди да елиминираме модификацията, която направихме в конфигурацията на вашата мрежова карта, ако в даден момент го направихме, за да проверим точката от предишната глава. Също така изтрийте записа за «махагон»В Microsoft® DNS и върнете динамичните актуализации до началната им точка на «Само сигурно«. Между другото, валидно е да рестартирате услугата Microsoft® DNS.

След като се присъедини към Домена и въпреки всички наши усилия, клиентът «махагон»Не е регистриран в Microsoft® DNS. Дори декларирахме в dnsmasq.conf -temporary- че първият DNS сървър е 10.10.10.3.

Microsoft Windows [Version 6.1.7601]
Авторско право (c) 2009 Microsoft Corporation. Всички права запазени.

C: \ Users \ saruman> ipconfig / всички

Име на хост за конфигуриране на IP на Windows. . . . . . . . . . . . : MAHOGANY Първичен Dns суфикс. . . . . . . : mordor.fan Тип възел. . . . . . . . . . . . : Хибридното IP маршрутизиране е активирано. . . . . . . . : Няма активиран прокси WINS. . . . . . . . : Няма списък за търсене на DNS суфикс. . . . . . : mordor.fan Ethernet адаптер Локална връзка: DNS суфикс за специфична връзка. : mordor.fan Описание. . . . . . . . . . . : Физически адрес на Intel (R) PRO / 1000 MT мрежова връзка. . . . . . . . . : 00-0C-29-D6-14-36 DHCP активиран. . . . . . . . . . . : Да Автоконфигурирането е активирано. . . . : Да Адрес на локален IPv6. . . . . : fe80 :: 352a: b954: 7eba: 963e% 12 (Предпочитан) IPv4 адрес. . . . . . . . . . . : 10.10.10.115 (Предпочитана) Маска на подмрежата. . . . . . . . . . . : 255.255.255.0 Получен лизинг. . . . . . . . . . : Събота, 25 февруари 2017 г. 8:19:05 ч. Лизингът изтича. . . . . . . . . . : Събота, 25 февруари 2017 г. 4:20:36 ч. Шлюз по подразбиране. . . . . . . . . : 10.10.10.253 DHCP сървър. . . . . . . . . . . : 10.10.10.5 DHCPv6 IAID. . . . . . . . . . . : 251661353 DHCPv6 клиент DUID. . . . . . . . : 00-01-00-01-20-3B-69-81-00-0C-29-D6-14-36

   DNS сървъри. , , , , , , , , , , : 10.10.10.3
                                       10.10.10.5
   NetBIOS през Tcpip. . . . . . . . : Активиран тунелен адаптер isatap.mordor.fan: Media State. . . . . . . . . . . : Мултимедия прекъснала връзката специфичен DNS суфикс. : mordor.fan Описание. . . . . . . . . . . : Физически адрес на адаптера на Microsoft ISATAP. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP активиран. . . . . . . . . . . : Няма разрешена автоконфигурация. . . . : Да Тунелен адаптер Локална връзка * 9: Състояние на носителя. . . . . . . . . . . : Мултимедия прекъснала връзката специфичен DNS суфикс. : Описание. . . . . . . . . . . : Физически адрес на адаптер за тунелиране на Microsoft Teredo. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP активиран. . . . . . . . . . . : Няма разрешена автоконфигурация. . . . : И това е

C: \ Потребители \ saruman>

buzz @ sysadmin: ~ $ host -t Махагон.mordor.fan 10.10.10.3
Използване на сървър на домейн: Име: 10.10.10.3 Адрес: 10.10.10.3 # 53 Псевдоними: Хост caoba.mordor.fan не е намерен: 3 (NXDOMAIN)

бръмча@sysadmin: ~ $ host -t Към махагон.mordor.fan
mahogany.mordor.fan има адрес 10.10.10.115
  • Единственият начин за регистриране на клиента «махагон»В Microsft® DNS модифицира вашата мрежова карта, както е посоченоó в предишното изображение, тоест изрично се посочва, че: DNS суфиксът за връзката е mordor.fan, че регистрира адреса на връзката в DNS и че използва декларирания DNS суфикс при регистриране на връзката.
buzz @ sysadmin: ~ $ host -t Махагон.mordor.fan 10.10.10.3
Използване на сървър на домейн: Име: 10.10.10.3 Адрес: 10.10.10.3 # 53 Псевдоними: caoba.mordor.fan има адрес 10.10.10.115

buzz @ sysadmin: ~ $ host -t Махагон.mordor.fan
mahogany.mordor.fan има адрес 10.10.10.115
Нека променим името от „махагон“ на „кедър“
buzz @ sysadmin: ~ $ host -t Махагон.mordor.fan 10.10.10.3
Използване на сървър на домейн: Име: 10.10.10.3 Адрес: 10.10.10.3 # 53 Псевдоними: Хост caoba.mordor.fan не е намерен: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t До cedar.mordor.fan 10.10.10.3
Използване на сървър на домейн: Име: 10.10.10.3 Адрес: 10.10.10.3 # 53 Псевдоними: cedro.mordor.fan има адрес 10.10.10.115

buzz @ sysadmin: ~ $ host -t Махагон.mordor.fan 10.10.10.5
Използване на сървър на домейн: Име: 10.10.10.5 Адрес: 10.10.10.5 # 53 Псевдоними: Хост caoba.mordor.fan не е намерен: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t До cedar.mordor.fan 10.10.10.5
Използване на сървър на домейн: Име: 10.10.10.5 Адрес: 10.10.10.5 # 53 Псевдоними: cedro.mordor.fan има адрес 10.10.10.115

И всичко нормално, както клиентите на Microsoft® и Microsoft® DNS обичат да бъдат нещата.

Нека работим с Microsoft® DHCP и Microsoft® DNS

Уважаеми читатели, тази глава е извън контекста на блог, посветен на свободния софтуер. Вижте помощ за Microsoft®. Те не вярват? 😉

Заключения

Има няколко начина за работа с Microsoft® DNS, когато го накараме да съществува едновременно в МСП мрежа с Dnsmasq. Сред тях ще споменем само следното:

  • Спрете напълно услугата Microsoft® DNS на компютъра, където тя работи, като посочите след това, че стартирането на услугата е деактивирано. Премахнете отметката в конфигурацията на мрежовата карта на всеки клиент на Microsoft® от опцията за регистриране на адреса на връзката в DNS. Премахване от файла /etc/dnsmasq.conf Директива сървър = / mordor.fan / 10.10.10.3. бележки:
    • Дори ако не се отговори на запитвания за записите SOA y NS, мрежата ще работи правилно, както и обединяването на различните клиенти -Microsoft® и Linux- с домейна Active Directory®.
    • Предимството е, че в мрежата за малки и средни предприятия ще има само един сървър за имена на домейни - мъжки мъж - и това ще бъде Dnsmasq. ;-). От друга страна, елиминира се възможността за несъответствия между DNS записите, съхранявани в Microsoft® DNS, и тези, налични чрез Dnsmasq.
  • Оставете Microsoft® DNS да работи, за да отговаряте само на DNS заявки за SOA и NS записи. Вниманиеs:
    • Променете конфигурацията на мрежовата карта на всеки клиент на Windows, като премахнете отметката от опцията за регистриране на адреса на връзката в DNS.
    • Мислим че това решение е загуба на ресурси.
  • Конфигурирайте услугите, както видяхме в статията, която показва решение, по-вкусно от философията на Microsoft® - не FreeBSD / Linux - Добре?

Обобщение

  • Предложението за Microsoft® DNS е много затворено. Не оставя място за други решения, които не са в съответствие с нейната херметична философия.
  • Майката Природа ни учи, че съществуваме в разнообразна Вселена. Нормалното е да имате смесена LAN, преминаваща към свободен софтуер и богата на живот и разнообразие.
  • Изглежда, че за Microsoft® клиентите, които не се присъединяват към Неговата философия, са изгнаници и следователно не трябва да се притесняват да ги вземат предвид.
  • Колко трудно е да работите с частен софтуер! Предпочитам да отделя малко работа за настройване на безплатен софтуер и да бъда наистина безплатен, по дяволите!

"Най-добрият критерий за истината е практиката."


11 коментара, оставете своя

Оставете вашия коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *

*

*

  1. Отговорен за данните: Мигел Анхел Гатон
  2. Предназначение на данните: Контрол на СПАМ, управление на коментари.
  3. Легитимация: Вашето съгласие
  4. Съобщаване на данните: Данните няма да бъдат съобщени на трети страни, освен по законово задължение.
  5. Съхранение на данни: База данни, хоствана от Occentus Networks (ЕС)
  6. Права: По всяко време можете да ограничите, възстановите и изтриете информацията си.

  1.   Зодия Карбур каза той

    Страхотна статия, която сте написали, Федерико!

  2.   Хулио Леон каза той

    Огромна статия, скъпа моя. И обобщението е най-добрият XD
    Слдос;

  3.   лагарто каза той

    Не мисля, че съм виждал по-пълно и подробно ръководство за sysadmin в интернет (на испански език), работата, която правите в Мрежи за МСП, е да подготвите.

    Въпреки че работата е трудна и достигането на това ниво на детайлност е въпрос на много часове, вярвам, че създавате референтна точка, която ще бъде използвана, когато стане известна от голям брой SysAdmin, които имат ключа в учителя за статии много от дейностите, с които се сблъсква всеки ден.

    Що се отнася до dnsmasq и активната директория, мисля, че никога не съм имал възможност да работя и с двете, но в моята лаборатория, при липсата на клиент на windows, всичко изглежда е наред и не е чудно с тази отлична стъпка от стъпка.

    Спасете вашата фраза «Колко трудно е да работите с частен софтуер! Предпочитам да похарча малко работа за конфигуриране на Свободен софтуер и да бъда наистина Свободен, по дяволите! »... Да тръгнем, че харченето на малко работа за конфигуриране на безплатен софтуер прескача с течение на времето, най-вече за документация като вашата и от много други хора, как също с постоянното хуманизиране на свободния софтуер.

    Поздравления FIco ... Продължаваме.

  4.   Федерико каза той

    Зодия: Вашите думи са стимул да продължите да пишете. Не се колебайте, много добри часове - задните части са необходими, за да напишете скромна статия като тази.

    Хулио Леон: Поздрави и за теб, скъпи Хулио. Надяваме се и продължете с нас по пътя на знанието за свободния софтуер.

    Лагарто: Прекараните дни и часове си заслужават, когато чета коментари като тези в тази публикация. Те са най-добрата награда за нашата работа. Предадох връзката към статията на самия Саймън Кели и той беше любезен да ми отговори.

    Искам да се възползвам от това пространство, за да кажа, че в DNS и DHCP въпроса започваме - по стратегия - от сложното към лесното. Dnsmasq е много валидно решение за МСП мрежи и е много по-лесно за изпълнение от дуета BIND + Isc-Dhcp-Server. Темата може да изглежда малко техническа за много читатели. С времето и практиката те ще осъзнаят, че това не е така. Струва си да се изучат Принципите на инфраструктурен сървър, заглавие, което да обхваща 6-те статии, написани за DNS и DHCP услуги, без да се забравя NTP.

    Поздравления за всички ... Продължаваме напред!

  5.   IWO каза той

    Благодаря на Федерико за поредната страхотна статия с огромни подробности и обширна теория за Dnsmasq, инструмент, който вече виждаме, е изключително полезен за sysadmins.

    СТРАХОТНО всичко, свързано с вмъкването на Microsoft DNS зона "_msdcs.mordor.fan" във вашия конфигурационен файл /etc/dnsmasq.conf чрез неговите SRV записи, които използват услугите: _gc, _ldap, _kerberos и _kpasswd с Целта е да се използва Microsoft DNS ("оператор = / mordor.fan / 10.10.10.3" в допълнение към Dnsmasq ("local = / mordor.fan /" израз) за разрешаване на DNS заявки.

    ГОЛЯМ е и разработеният пример, че за Microsoft DNS да регистрира клиенти на Windows с IP промени в LAN, трябва да изберете в DNS конфигурацията, „Динамичните актуализации“ като „Несигурен и защитен“ и какво означава това в уязвимостта на сигурност на всеки сървър за имена на домейни, който се спазва, било то Microsoft или UNIX / Linux. Освен че е необходима модификация в конфигурацията на мрежовата карта на клиента на Windows.
    Нищо, че с всеки нов пост вдигате спирката! Очаквам с нетърпение следващите статии!

    1.    Федерико каза той

      Благодаря ви много за вашата оценка и коментар, IWO. Във всяка статия, която публикувам, винаги чакам вашето мнение, тъй като то се подкрепя от вашата професия, знания и практика. Поздравления IWO. Ще се видим в следващата статия

  6.   dhunter каза той

    Много добра работа, както винаги публикуване на тези скъпоценни камъни за sysadmins. Благодаря хиляда!

  7.   креспо88 каза той

    Дайте шанс на DNS на Microsoft, дори не сте го оставили да се показва. Не знаем дали е все още жив или дори да му е останал срам. Отлична статия.

  8.   HO2Gi каза той

    Бижу като никое друго, запазено в любими за консултация. Отлична статия.

  9.   Федерико каза той

    HO2Gi благодаря за вашата оценка. Препоръчвам ви - и като цяло на ВСИЧКИ - посетете https://blog.desdelinux.net/redes-computadoras-las-pymes-introduccion/. Той беше редактиран отново с индекс на всички публикувани публикации и темите, които ще бъдат обсъдени. Поздрави и продължете с нас.

  10.   Пабло Андрес Флемър каза той

    Отличен документ като този, наличен в https://blog.desdelinux.net/bind-active-directory/
    Просто искам да направя препоръка и моля, приемете я като конструктивна критика; За да илюстрира конфигурацията, би било по-добре, ако вместо да използва мрежата 10.10.10.0/24, беше използвал такава, където всеки блок имаше различни номера, като мрежата 192.168.1.0/24.
    Това би направило по-ясни точките, където мрежовите адреси отиват в обратна посока, например когато трябва да добавите стойности от типа ".in-addr.arpa"
    Благодарим ви, че споделихте толкова много качествени знания.
    С най-добри пожелания.