Dnsmasq i Active Directory - Xarxes PIME

Índex general de la sèrie: Xarxes de Ordinadors per a les PIMES: Introducció

Hola amics !. Per comprendre i seguir correctament aquest article és imprescindible la lectura dels seus antecessors:

En ells s'expliquen conceptes teòrics i pràctics als quals no farem referència a aquest. Canviarem de distribució en l'exercici actual cap Debian 8.6 «Jessie» i continuarem amb els mateixos paràmetres que fem servir en BIND i Active Directory®.

  • El procediment descrit en aquest post, també és vàlid per a CentOS 7. El fitxer de configuració / etc / dnsmasq és el mateix. El declaro perquè considero innecessari confeccionar un article a part per dnsmasq i Active Directory® basat en CentOS. Per sort, els directoris relatius a la documentació i configuració, són els mateixos,
  • El Dnsmaq és una creació de Simon Kelley

Límits sobre l'ús de l'dnsmasq

Per la seva importància repetim els LÍMITS que suporta el dnsmasq -ejecuten man dnsmasq- el qual reflecteix exactament el següent:

LÍMITS

  • Els valors per omissió per a límits de recursos són generalment conservadors, i apropiats per a ús en dispositius tipus encaminador encrustrado amb processadors lents i poca memòria. En maquinari més  capáz, és possible incrementar els límits, i suportar molts mes clients. El següent s'aplica a dnsmasq-2.37: versions prèvies no escalaven tan bé.
  • Dnsmasq és capaç de suportar amb DNS i DHCP a almenys mil (1,000) clients. Els temps d'arrendament no han de ser molt curts (menys d'una hora). El valor de -dns-forward-max pot ser augmentat: comenci amb l'equivalent a el nombre de clients i Augmenteu si sembla lent el DNS. Cal notar que el rendiment DNS depèn també dels servidors DNS upstream. La mida de la memòria cau DNS pot ser incrementat: el límit obligatori és 10,000 noms i el predeterminat (150) és molt baix. El enviar-li un SIGUSR1 a dnsmasq fa que bitacore informació que és útil per afinar la mida de memòria cau. Veure la secció NOTES per detalls.
  • El servidor TFTP incorporat és capáz de suportar diverses transferències simultànies d'arxius: el límit absolut està relacionat amb el nombre de file-handles permesos a un procés i l'habilitat de l'sys-tem call select () a suportar nombres grans de file-handles. Si el límit és fixat massa alt amb -tftp-max serà de-escalat i el límit real serà bitacoreado a l'inici. Cal notar que més transferències són possibles quan el mateix arxiu és enviat què quan cada transrència envia un arxiu diferent. És possible utilitzar dnsmasq per negar publicitat web fent servir una llista de servidors de banners ben coneguts, tots resolviendose a 127.0.0.1 o 0.0.0.0 a / etc / hosts o en un arxiu hosts addicional. La llista pot ser molt llarga. Dnsmasq ha estat provat exitósamente amb un milió de noms. Aquest mida del fitxer necessita un CPU de 1GHz i aproximadament 60MB de RAM.
  • Dnsmasq és capaç de suportar amb DNS i DHCP a almenys mil (1,000) clients.

Instal·lem i configurem a Jessie i a l'dnsmasq

Partirem d'una instal·lació nova i neta d'un servidor basat en Debian 8 «Jessie». O sigui, el sistema operatiu sense interfície gràfica cap o un altre paquet instal·lat. Els paràmetres de la xarxa seran els mateixos que utilitzem en l'article BIND i Active Directory®:

Nom de domini mordor.fan Xarxa LAN 10.10.10.0/24 ===================================== ========================================== Servidors Adreça IP Propòsit (servidors amb SO Windows) ================================================ ===============================
sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2
mamba.mordor.fan. 10.10.10.4 Servidor d'arxius Windows
dns.mordor.fan 10.10.10.5 Servidor dnsmasq sobre Jessie
darklord.mordor.fan. 10.10.10.6 Proxy, passarel·la i tallafocs sobre Kerios troll.mordor.fan. 10.10.10.7 Bloc basat en ... no recordo shadowftp.mordor.fan. 10.10.10.8 Servidor FTP blackelf.mordor.fan. 10.10.10.9 Servei e-mail complet blackspider.mordor.fan. 10.10.10.10 Servei WWW palantir.mordor.fan. 10.10.10.11 Xat en Openfire per a Windows Reial CNAME ============================== sauron ad-dc mamba fileserver Darklord proxyweb troll bloc shadowftp ftpserver blackelf mail blackspider www palantir Openfire

Configuracions inicials de servidor 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 # The following lines are desirable for IPv6 capable hosts :: 1 localhost ip6-localhost ip6-loopback ff02 :: 1 ip6-allnodes ff02 :: 2 ip6-allrouters

root @ dns: ~ # nano / etc / network / interfaces
# This file descrius the network interfaces available on your system # and how to activate them. For more information, see interfícies (5). source /etc/network/interfaces.d/* # The loopback network interface interlocutòria el iface el inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 10.10.10.5 netmask 255.255.255.0 network 10.10.10.0 broadcast 10.10.10.255. 10.10.10.1 passarel·la 127.0.0.1 # dns- * options are implemented by the resolvconf package, if installed dns-nameservers XNUMX dns-search mordor.fan

Instal·lem el dnsmasq i htop

root @ dns: ~ # aptitude install dnsmasq htop

Després d'instal·lar el paquet htop podem comprovar els consums de CPU i memòria de l'equip. Només estava consumint uns 71 megues de RAM. Si volem baixar encara més el consum, podem instal·lar el paquet SSMTP -senzill MTA- que al seu torn purga el paquet exim4 que Debian sempre instal·la per defecte i que realment no necessitem d'acord amb l'ús que donarem a aquest servidor:

root @ dns: ~ # aptitude install ssmtp
root @ dns: ~ # aptitude purge ~ c
root @ dns: ~ # aptitude clean
root @ dns: ~ # aptitude autoclean
root @ dns: ~ # systemctl reboot

Després de reiniciar l'ordinador, el consum és el següent: Dnsmasq i Active Directory

Sota, no ?. Continuem endavant.

Indiquem que el dnsmasq consulti -a més- a l'Microsft® DNS

Per provar les possibles configuracions de l'dnsmasq en l'equip dns.mordor.fan, Hem d'incloure una declaració que indiqui que es consulti a l'Microsoft DNS de servidor sauron.mordor.fan. Ho podem fer incloent la directiva server = / mordor.fan / 10.10.10.3 a l'arxiu dnsmasq.conf -com veurem més endavant- o addicionant la línia servidor de noms 10.10.10.3 a l'arxiu /etc/resolv.conf. Com encara no hem configurat a l'dnsmasq acord amb les nostres necessitats, vam triar la segona forma:

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

Ja podem resoldre consultes DNS

Amb la configuració per defecte de l'dnsmasq que aporta el seu arxiu principal /etc/dnasmq.conf, I amb el declarat a l'arxiu /etc/resolv.conf de l'propi servidor «dns«, Qualsevol client connectat a la LAN -i que tingui declarat com a servidor DNS a dns.mordor.fan- podrà resoldre consultes DNS a costa de l'Microsoft® DNS per ara ...

  • Molt important és comprovar la velocitat de resposta de l'dnsmasq a l'fer gala de la seva condició de Reenviador per la sola inclusió de la IP 10.10.10.3 en el seu arxiu /etc/resolv.conf.

Des del meu estació de treball administrativa i suport de tota la parafernàlia mitjançant la qual escric, executo:

buzz @ sysadmin: ~ $ cat /etc/resolv.conf 
# Generated by NetworkManager domain mordor.fan nameserver 10.10.10.5

buzz @ sysadmin: ~ $ nslookup
> dns
Server: 10.10.10.5 Address: 10.10.10.5 # 53 Name: dns.mordor.fan Address: 10.10.10.5

> sauró
Server: 10.10.10.5 Address: 10.10.10.5 # 53

Non-authoritative answer:
Name: sauron.mordor.fan Address: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
Server: 10.10.10.5 Address: 10.10.10.5 # 53 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan canonical name = sauron.mordor.fan. Name: sauron.mordor.fan Address: 10.10.10.3

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

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

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

> mail
Server: 10.10.10.5 Address: 10.10.10.5 # 53 Non-authoritative answer: mail.mordor.fan canonical name = blackelf.mordor.fan. Name: blackelf.mordor.fan Address: 10.10.10.9> exit

buzz @ sysadmin: ~ $

Observem en detall els següents aspectes:

  • dns.mordor.fan respon directament les consultes DNS que pugui resoldre d'acord amb la configuració actual de la seva dnsmasq. Sinó les pot resoldre funciona com Reenviador i li pregunta a la IP 10.10.10.3 si pot respondre a la consulta. Quan se li pregunta per la IP de l'equip «dns«, Respon ell directament. Quan se li pregunta a l'dnsmasq ¿qui és «sauró«,?, Fa reenviament a la 10.10.10.3 -no pot respondre directament doncs encara no ho té registrat- qui li retorna una Resposta No Autoritària correcta.
  • Quan se li pregunta qui és «03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan«?, Fa reenviament novament i en aquesta ocasió rep una resposta Autoritària de l'Microsoft® DNS.
  • L'alta velocitat de resposta de l'dnsmasq per a qualsevol tipus de consulta.

Són petits detalls que fan gran un amor ;-).

Diferències fonamentals entre dnsmasq i BIND integrats amb un Active Directory®

Efectuem un parell de consultes DNS sobre els registre SOA y NS de l'domini mordor.fan, A cada un dels servidors de nom involucrats:

buzz @ sysadmin: ~ $ host -t SOA mordor.fan 10.10.10.3
Using domain server: Name: 10.10.10.3 Address: 10.10.10.3 # 53 Àlies: 
mordor.fan has SOA rècord sauron.mordor.fan. hostmaster.mordor.fan. 56 900 600

buzz @ sysadmin: ~ $ host -t SOA mordor.fan 10.10.10.5
Using domain server: Name: 10.10.10.5 Address: 10.10.10.5 # 53 Àlies: 
mordor.fan has SOA rècord sauron.mordor.fan. hostmaster.mordor.fan. 56 900 600

buzz @ sysadmin: ~ $ host -t NS mordor.fan 10.10.10.5
Using domain server: Name: 10.10.10.5 Address: 10.10.10.5 # 53 Àlies: 
mordor.fan name server sauron.mordor.fan.

buzz @ sysadmin: ~ $ host -t NS mordor.fan 10.10.10.3
Using domain server: Name: 10.10.10.3 Address: 10.10.10.3 # 53 Àlies: 
mordor.fan name server sauron.mordor.fan.

Les respostes són idèntiques -el que és lògic- doncs sempre respon sauron.mordor.fan. davant d'una consulta DNS sobre registres SOA o NS, tot i que sembli que respon el dns.mordor.fan. No obstant això difereix del que s'ha vist en l'article BIND i Active Directory® on havíem suprimit del tot la funcionalitat de l'Microsoft® DNS. En aquest article TOTS els consultes DNS sobre l'Espai de Noms de l'Domino mordor.fan les responia el BIND, perquè així ho configurem, i perquè el BIND si respon consultes SOA y NS a més de que permet l'esquema Màster - Slave, Transferència de Zones, etcètera, i per tant és un servidor DNS mes complet - complex.

Que potser aquestes siguin les diferències principals entre el DNS de l'dnsmasq i el BIND ... però, el BIND -sempre pot haver un o més peros- no té un servidor DHCP que s'integra perfectament amb un servidor DNS en un sol daemond, I sense necessitat de claus TSIG, arxius de configuracions, bases de dades de Zones, etcètera, com hem vist en articles anteriors.

  • Crec que a aquesta altura, els Benvolguts Lectors s'hauran adonat que no odi a l'BIND ni prefereixo a l'dnsmasq abans que el BIND. Futures discussions a l'respecte són una total pèrdua de temps, ja que té a veure molt amb necessitats, exigències, gustos, preferències i ... cada solució té el seu encant ;-).
  • En escenaris similars, que cadascú instal·lat i configurat el programari de la seva preferència i que mes conegui i que tot li funcioni com espera.

Avantatges de la combinació dnsmasq + Active Directory®

Amb aquesta combinació tenim el ventall complet de respostes a consultes DNS i un eficaç mitjà d'arrendament d'adreces IP per a la nostra LAN PIME. Com veurem més endavant, funciona correctament per a qualsevol situació pel que fa a si l'equip està unit o no a l'Controlador de Domini de l'Microsoft Active Directory®. A més, disposem d'un servidor DNS i DNS Reenviador per excel·lència, més un servidor DHCP molt ràpid. I tot amb poca demanda de recursos. Voleu més ?.

És possible dnsmasq + BIND?

Definitivament SI. Encara recomano s'instal·lin en equips diferents perquè no hi hagi xocs pel tan estimat port 53 de l'servei DNS. Potser i vegem alguna cosa a l'respecte quan arribem a l'AD-DC basat en Samba 4. Qui sap ?.

Tipus sobre el Dnamasq

  • Els arxius imprescindibles de treball perquè el dnsmasq brindi els serveis DHCP i DNS en una LAN són: /etc/dnsmasq.conf, / Etc / hosts, /var/lib/misc/dnsmasq.leases i /etc/resolv.conf. l'arxiu dnsmasq.leases es crea quan deixa les seves primera adreça IP.
  • Un altre arxiu de treball que pot utilitzar és / Etc / ethers. D'existir aquest arxiu, la directiva read-ethers declarada a l'arxiu de configuració, li indica a l'dnsmasq que ho llegeixi. És molt útil quan relacionem adreces MAC / noms de hosts per a determinats propòsits.
  • El servei DNS es pot desactivar completament mitjançant la directiva port = 0 en el dnsmasq.conf.
  • El servei DHCP per a una o més interfícies de xarxa es pot desactivar mitjançant directives -una per cada línia- no-dhcp-interfície = eth0, no-dhcp-interfície = eth1, I així successivament. Molt útil quan estiguem davant d'un equip amb 2 -o més- interfícies de xarxa i volem es brindi el servei DHCP només per una d'elles o per cap. Per descomptat que, si deshabilitem el servei DHCP per totes les interfícies, deixarem només en funcionament a el servei DNS. Si deshabilitem tots dos serveis, llavors per què necessitem a l'dnsmasq ?. 😉
  • Per declarar a altres servidors de Nom de Domini DNS que no siguin públics o externs a la LAN -com el cas de l'Microsoft DNS- ho fem mitjançant la directiva server = / nom de l'domini / IP de servidor DNS a l'arxiu /etc/dnsmasq.conf. exemple: server = / mordor.fan / 10.10.10.3.
  • Per indicar a l'dnsmasq que les consultes sobre els dominis locals siguin respostes només des de l'arxiu / Etc / hosts o mitjançant la seva DHCP, hem d'afegir la directiva local = / localnet / a l'arxiu principal de la seva configuració. exemple: local = / mordor.fan /.
  • Per configurar correctament l'arxiu /etc/resolv.conf - resolutor suggerim la lectura del seu manual mitjançant la comanda man resolv.conf. Si instal·len el Debian 8.6 «Jessie» trobaran que està ben redactat en llengua hispana.
  • El dnsmasq no utilitza arxius de Zones per respondre a consultes directes o inverses.
  • Per conèixer el significat de cada camp «especial»Que s'utilitza en la declaració d'un Registre de Recurs SRV, ha de consultar BIND i Active Directory®. La sintaxi dels registres SRV a l'arxiu /etc/dnsmasq.conf és la següent:
    srv-host = , , , ,

Els Lectors que vulguin conèixer més, si us plau llegeixin amb deteniment l'arxiu original /etc/dnsmasq.conf o els documents que hi ha al directori / Usr / share / doc / dnsmasq-base.

root @ dns: ~ # ls -l / usr / share / doc / dnsmasq-base /
total 128 -RW-r - r-- 1 root root 883 may maig 5 copyright -RW-r - r-- 2015 root root 1 may maig 36261 changelog.archive.gz -RW-r - r-- 5 root root 2015 may maig 1 changelog.Debian.gz -RW-r - r-- 11297 root root 5 may maig 2015 changelog.gz -RW-r - r-- 1 root root 26014 maig maig 5 DBus-interfície. gz -RW-r - r-- 2015 root root 1 maig maig 2084 doc.html drwxr-xr-x 5 root root 2015 febrer 1 4297:5 examples -RW-r - r-- 2015 root root 2 maig 4096 19 FAQ.gz -RW-r - r-- 17 root root 52 maig maig 1 README.Debian -RW-r - r-- 9721 root root 5 may maig 2015 setup.html

Configurem a l'dnsmasq i a l'Resoldre

Prendrem com a guia inicial -canviant els noms i altres, és clar- l'arxiu de configuració emprat en l'article «Dnsmasq a CentOS 7.3".

No oblidem el següent pas:

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

Adreces IP fixes

Les direccions dels servidors o equips que requereixin d'una IP fixa -tant IPv4 com a IPv6- es declaren a l'arxiu / Etc / hosts:

[Root @ dns ~] # nano / etc / hosts
127.0.0.1 localhost # The following lines are desirable for IPv6 capable hosts :: 1 localhost ip6-localhost ip6-loopback ff02 :: 1 ip6-allnodes ff02 :: 2 ip6-allrouters # servidors i equips amb 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

Creiem l'arxiu /etc/dnsmasq.conf

[Root @ dns ~] # nano /etc/dnsmasq.conf
# ------------------------------------------------- ------------------ # OPCIONESGENERALES # ----------------------------- -------------------------------------- domain-needed # No passar noms sense la part de l'domini bogus-priv # no passar direccions en l'espai no encaminament expand-hosts # Adiciona automàticament el domini a l'host interfície = eth0 # interface.  OJO amb la Interface # except-interfície = eth1 # NO escoltar per aquesta NIC strict-order # Ordre en què consulta l'arxiu /etc/resolv.conf # Inclogui moltes més opcions de configuració # mitjançant un arxiu o ubicant els arxius # de configuració addicionals en un directori # conf-file = / etc / dnsmasq.more.conf conf-dir = / etc / dnsmasq.d # Relatius a l'Nom de l'domini domain = mordor.fan # Nom de l'domini # el Servidor de Temps és 10.10.10.1. 10.10.10.1 address = / time.windows.com / XNUMX # Envia una opció buida de la valor WPAD.  Es requereix perquè # es comportin bé els clients Windos 7 i posteriors.  ;-) dhcp-option = 252, "\ n" # Arxiu on declararem els HOSTS que seran "banejats" addn-hosts = / etc / banner_add_hosts # Consultar a l'Microsoft® DNS "sauron" si és que # el deixem en funcionament server = / mordor.fan / 10.10.10.3 # Les consultes sobre els dominis locals seran respostes # des / etc / hosts o mitjançant DHCP local = / mordor.fan / # Les consultes sobre registres PTR o Inverses, seran respostes # pels servidors "dns" i "sauron" en aquest ordre server = / 10.10.10.in-addr.arpa / 10.10.10.5 server = / 10.10.10.in-addr.arpa / 10.10.10.3 # ------- -------------------------------------------------- ---------- # REGISTROSCNAMEMXTXT # ------------------------------------- ------------------------------ # Aquest tipus de registre requereix d'una entrada # a l'arxiu / etc / hosts # ex: 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 # REGISTRES MX # Retorna un registre MX amb el nom "mordor.fan" amb destinació # a l'equip blackelf.mordor.fan i prioritat de 10 mx-host = mordor.fan, mail. mordor.fan, 10 # el destí per defecte per als registres MX que es creïn # utilitzant l'opció localmx serà: mx-target = mail.mordor.fan # Retorna un registre MX apuntant a l'mx-target per a TOTES # les màquines locals localmx # Registres TXT. 

dhcp-lease-max = 222 # Quantitat màxima d'adreces a arrendar
                        # Per defecte són 150
# Rang IPV6 # dhcp-range = 1234 ::, ra-only # Opcions per al RANG # OPCIONS 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 Servers dhcp-option = 19,1, mordor.fan # DNS nom de camp 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, Mórdor # NIS nom de camp # dhcp-option = 45,10.10.10.3 # NIS Server # dhcp-option = 73,10.10.10.3 # WINS # dhcp-option = 46,8 # Datagrames NetBIOS # dhcp-option = XNUMX # Finger Server # dhcp-option = XNUMX # Node NetBIOS dhcp-authoritative # DHCP Autoritari a la subnet # ------------- -------------------------------------------------- ---- # --------------------------------------------- ---------------------- # LOGGING tail -f / var / log / syslog o journalctl -f # ------------ -------------------------------------------------- ----- log-queries # ----------------------------------------- -------------------------- # Re gistres A i SRV corresponents a l'Active Directory # ----------------------------------------- --------------------------
# Registres 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

# Registre CNAME de la Zona d'el Microsoft DNS _msdcs.mordor.fan
cname=03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan,sauron.mordor.fan

# Registres SRV
# srv-host = , , , ,

# Global Catalog # Zona _msdcs.mordor.fan de l'Microsoft DNS
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
# Zona mordor.fan de l'Microsoft DNS
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 modificat i privat d'un Active Directory
# Zona _msdcs.mordor.fan de l'Microsoft DNS
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
# Zona mordor.fan de l'Microsoft DNS
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 modificat i privat d'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

# FI de l'arxiu /etc/dnsmasq.conf
# ------------------------------------------------- ------------------

Creiem l'arxiu / 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 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: syntax check OK.

[Root @ dns ~] # systemctl restart dnsmasq.service 
[Root @ dns ~] # systemctl estatus dnsmasq.service

Modifiquem l'arxiu /etc/resolv.conf - Resoldre

root @ dns: ~ # nano /etc/resolv.conf 
domain mordor.fan search mordor.fan

Per què no tenim declarades les habituals línies a l'arxiu resolv.conf?. Perquè declarem en el dnsmasq.conf les següents directives:

# Consultar a l'Microsoft® DNS "sauron" si és que # el deixem en funcionament
server = / mordor.fan / 10.10.10.3

# Les consultes sobre els dominis locals seran respostes # des / etc / hosts o mitjançant DHCP
local = / mordor.fan /

# Les consultes sobre registres PTR o Inverses, seran respostes # pels servidors "dns" i "sauron" en aquest ordre
server = / 10.10.10.in-addr.arpa / 10.10.10.5 server = / 10.10.10.in-addr.arpa / 10.10.10.3

Consultes des sysadmin.mordor.fan

l'arxiu /etc/resolv.conf d'aquest equip és:

buzz @ sysadmin: ~ $ cat /etc/resolv.conf
# Generated by NetworkManager search mordor.fan nameserver 10.10.10.5
buzz @ sysadmin: ~ $ host -t A spynet4.microsoft.com
spynet4.microsoft.com has address 127.0.0.1

buzz @ sysadmin: ~ $ host -t A www.download.windowsupdate.com
www.download.windowsupdate.com has address 127.0.0.1

brunzit@sysadmin: ~ $ dig dns
buzz @ sysadmin: ~ $ dig dns.mordor.fan
;; QUESTION SECTION:; dns.mordor.fan. IN A ;; ANSWER SECTION: 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
_ldap._tcp.gc._msdcs.mordor.fan has SRV rècord 0 0 3268 sauron.mordor.fan.

buzz @ sysadmin: ~ $ dig _ldap._tcp.gc._msdcs.mordor.fan
;; QUESTION SECTION:; _ldap._tcp.gc._msdcs.mordor.fan. IN A ;; ANSWER SECTION: _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

I d'aquesta forma, totes les consultes necessitem

Dnsmasq + Active Directory® + Clients Microsoft Windows

Canvi de nom d'un client Microsoft Windows

seven.mordor.fan arrendar la 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

Canviem el nom de l' «07:00»-Que no està unit a l'Domini de l'Active Directory- per«eucaliptus«. Després de l'canvi i el reinici comprovem:

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

La història dels canvis les podem veure des de «sysadmin»:

buzz @ sysadmin: ~ $ host -t A seven
seven.mordor.fan has address 10.10.10.115

Després de el canvi de nom

buzz @ sysadmin: ~ $ host -t A seven
seven has no A rècord

buzz @ sysadmin: ~ $ host -t A eucaliptus
eucaliptus.mordor.fan has address 10.10.10.115

Consultes des del client eucaliptus.mordor.fan

Microsoft Windows [versió 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C: \ Users \ buzz> nslookup
Default Server: dns.mordor.fan Address: 10.10.10.5

> sauron
Server: dns.mordor.fan Address: 10.10.10.5 Name: sauron.mordor.fan Address: 10.10.10.3

> mordor.fan
Server: dns.mordor.fan Address: 10.10.10.5 Name: mordor.fan Address: 10.10.10.3

> eucaliptus
Server: dns.mordor.fan Address: 10.10.10.5 Name: eucaliptus.mordor.fan Address: 10.10.10.115

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan
Server: dns.mordor.fan Address: 10.10.10.5 Name: sauron.mordor.fan Address: 10.10.10.3 Àlies: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> Set type = SRV
> _kerberos._udp.mordor.fan
Server: dns.mordor.fan Address: 10.10.10.5 _kerberos._udp.mordor.fan SRV service location: 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
Server: dns.mordor.fan Address: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan SRV service location: priority = 0 weight = 0 port = 389 SVR hostname = sauron .mordor.fan sauron.mordor.fan internet address = 10.10.10.3

> sortir

C: \ Users \ buzz>

Registre dels clients Windows en el Microsoft DNS

Clients Windows no units a l'Domini de l'Active Directory®

Hem de comprovar si es registren correctament al Microsoft DNS, les adreces IP arrendades pels diferents clients Windows des del dnsmasq. pot influir la forma en que activem les Actualitzacions dinàmiques - dynamic updates en les Zones de l'Microsoft® DNS de l'Active Directory®. Partim de la configuració per defecte de l'Microsoft DNS el qual permet només les Actualitzacions Dinàmiques Segures - Dynamic updates -> Secure only, En cadascuna de les seves Zones.

Observem que el client amb l'actual FQDN eucaliptus.mordor.fan no està unit a l'Domini de l'Active Directory (oa un Samba4 AD-DC), i constitueix una excepció a la regla de Microsoft que «només els clients registrats en El meu Domini tindran permís a La meva Mecanisme d'Actualització -que Jo només conec- per registrar-se a El meu DNS«. Sort que el Samba4 AD-DC ens ensenya alguna cosa a l'respecte.

eucaliptus.mordor.fan arrendar la IP 10.10.10.115:

buzz @ sysadmin: ~ $ host -t A eucaliptus
eucaliptus.mordor.fan has address 10.10.10.115

Canviem el seu nom pel de «Caoba«, Reiniciem el Windows 7, i veiem que passa quan preguntem pels noms«eucaliptus»i«Caoba»A cada un dels DNS, primer a l'Microsoft DNS i després a l'dnsmasq:

buzz @ sysadmin: ~ $ host -t A eucaliptus.mordor.fan 10.10.10.3
Using domain server: Name: 10.10.10.3 Address: 10.10.10.3 # 53 Àlies: 

Host eucaliptus.mordor.fan not found: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t A caoba.mordor.fan 10.10.10.3
Using domain server: Name: 10.10.10.3 Address: 10.10.10.3 # 53 Àlies: 

Host caoba.mordor.fan not found: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t A eucaliptus.mordor.fan 10.10.10.5
Using domain server: Name: 10.10.10.5 Address: 10.10.10.5 # 53 Àlies: 

Host eucaliptus.mordor.fan not found: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t A caoba.mordor.fan 10.10.10.5
Using domain server: Name: 10.10.10.5 Address: 10.10.10.5 # 53 Àlies: 

caoba.mordor.fan has address 10.10.10.115

Podem canviar el nom de el client Windows 7 que no està unit a l'Domini mordor.fan de l'Active Directory® quantes vegades vulguem, que l'Microsoft DNS no s'assabenta d'aquests canvis ni que existeix tal client. És possible que s'hagi de només al fet que tenim seleccionada l'opció  Dynamic updates -> Secure only en cada zona de l'Micorosft DNS ?.

Perquè el Senyor Microsoft DNS s'assabenti dels canvis, hem de seleccionar Dynamic updates -> Nonsecure and secure. Aquesta opció, Benvolguts Lectors, implica una significativa vulnerabilitat de la seguretat de qualsevol Servidor de Noms de Domini que es respecti, sigui de Microsft® o UNIX® / Linux. El Microsoft DNS adverteix sobre la vulnerabilitat perquè a la fi no és més que un BIND modificat i privatitzat per oferir-nos «Seguretat a canvi de Obscuridad«. Si no, ¿per què recomana guardar en el seu famós Registre totes les configuracions i registres DNS del seu Microsoft DNS quan estem implementant un Active Directory® ?. A més d'admetre les actualitzacions no segures al Microsoft DNS, és necessària la modificació següent en la configuració de la targeta de xarxa de client Windows 7:

comprovem:

buzz @ sysadmin: ~ $ host -t A caoba.mordor.fan 10.10.10.3
Using domain server: Name: 10.10.10.3 Address: 10.10.10.3 # 53 Àlies: caoba.mordor.fan has address 10.10.10.115

buzz @ sysadmin: ~ $ host 10.10.10.115 10.10.10.3
Using domain server: Name: 10.10.10.3 Address: 10.10.10.3 # 53 Àlies: 115.10.10.10.in-addr.arpa domain name pointer caoba.mordor.fan.

buzz @ sysadmin: ~ $ host -t A caoba 10.10.10.5
Using domain server: Name: 10.10.10.5 Address: 10.10.10.5 # 53 Àlies: caoba.mordor.fan has address 10.10.10.115

buzz @ sysadmin: ~ $ host 10.10.10.115 10.10.10.5
Using domain server: Name: 10.10.10.5 Address: 10.10.10.5 # 53 Àlies: 115.10.10.10.in-addr.arpa domain name pointer caoba.mordor.fan.

Ara si. Que bonic sincronisme per dos servidors DNS no sincronitzats per cap mitjà !, no ?.

Clients Windows units a l'Domini de l'Active Directory®

Unim el client caoba.mordor.fan a l'Domini, no sense abans eliminar la modificació que vam fer en la configuració de la targeta de xarxa, si és que en algun moment la vam fer per comprovar res més del punt de el capítol anterior. També esborrem l'entrada de «Caoba»En el Microsoft® DNS, i retornem les Actualitzacions Dinàmiques al seu punt d'origen de «secure only«. De passada, és vàlid reiniciar el servei de l'Microsoft® DNS.

Després d'unit a l'Domini, i malgrat tots els nostres esforços, el client «Caoba»No apareix registrat en el Microsoft DNS. Fins declarem en el dnsmasq.conf -de manera temporal- que el primer servidor DNS és 10.10.10.3.

Microsoft Windows [versió 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C: \ Users \ saruman> ipconfig / all

Windows IP Configuration Host Name. . . . . . . . . . . . : CAOBA Primary DNS Suffix. . . . . . . : Mordor.fan Node Type. . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : Mordor.fan Ethernet adapter Local Area Connection: Connection-specific DNS Suffix. : Mordor.fan Description. . . . . . . . . . . : Intel (R) PRO / 1000 MT Network Connection Physical Address. . . . . . . . . : 00-0C-29-D6-14-36 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled. . . . : Yes Link-local IPv6 Address. . . . . : Fe80 :: 352: b954: 7eba: 963e% 12 (Preferred) IPv4 Address. . . . . . . . . . . : 10.10.10.115 (Preferred) Subnet Mask. . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : Saturday, February 25, 2017 8:19:05 AM Lease Expires. . . . . . . . . . : Saturday, February 25, 2017 4:20:36 PM Default Gateway. . . . . . . . . : 10.10.10.253 DHCP Server. . . . . . . . . . . : 10.10.10.5 DHCPv6 IAID. . . . . . . . . . . : 251661353 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-20-3B-69-81-00-0C-29-D6-14-36

   DNS Servers. . . . . . . . . . . : 10.10.10.3
                                       10.10.10.5
   NetBIOS over TCPIP. . . . . . . . : Enabled Tunnel adapter isatap.mordor.fan: Mitjana State. . . . . . . . . . . : Mitjana disconnected Connection-specific DNS Suffix. : Mordor.fan Description. . . . . . . . . . . : Microsoft ISATAP Adapter Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled. . . . : Yes Tunnel adapter Local Area Connection * 9: Mitjana State. . . . . . . . . . . : Mitjana disconnected Connection-specific DNS Suffix. : Descripció. . . . . . . . . . . : Microsoft Teredo Tunneling Adapter Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled. . . . : Yes

C: \ Users \ saruman>

buzz @ sysadmin: ~ $ host -t A caoba.mordor.fan 10.10.10.3
Using domain server: Name: 10.10.10.3 Address: 10.10.10.3 # 53 Àlies: Host caoba.mordor.fan not found: 3 (NXDOMAIN)

brunzit@sysadmin: ~ $ host -t A caoba.mordor.fan
caoba.mordor.fan has address 10.10.10.115
  • De l'única manera que es registra el client «Caoba»Al Microsft® DNS és modificant la seva targeta de xarxa com es va indicaró en la imatge anterior, És a dir, declarant explícitament que: el sufix DNS per a la connexió és mordor.fan, que registri la direcció de la connexió al DNS, i que utilitzi el sufix DNS declarat a l'registrar la connexió.
buzz @ sysadmin: ~ $ host -t A caoba.mordor.fan 10.10.10.3
Using domain server: Name: 10.10.10.3 Address: 10.10.10.3 # 53 Àlies: caoba.mordor.fan has address 10.10.10.115

buzz @ sysadmin: ~ $ host -t A caoba.mordor.fan
caoba.mordor.fan has address 10.10.10.115
Canviem el nom de «caoba" a "cedre»
buzz @ sysadmin: ~ $ host -t A caoba.mordor.fan 10.10.10.3
Using domain server: Name: 10.10.10.3 Address: 10.10.10.3 # 53 Àlies: Host caoba.mordor.fan not found: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t A cedro.mordor.fan 10.10.10.3
Using domain server: Name: 10.10.10.3 Address: 10.10.10.3 # 53 Àlies: cedro.mordor.fan has address 10.10.10.115

buzz @ sysadmin: ~ $ host -t A caoba.mordor.fan 10.10.10.5
Using domain server: Name: 10.10.10.5 Address: 10.10.10.5 # 53 Àlies: Host caoba.mordor.fan not found: 3 (NXDOMAIN)

buzz @ sysadmin: ~ $ host -t A cedro.mordor.fan 10.10.10.5
Using domain server: Name: 10.10.10.5 Address: 10.10.10.5 # 53 Àlies: cedro.mordor.fan has address 10.10.10.115

I tot normal, com li agrada als clients Microsoft® i a l'Microsoft® DNS que siguin les coses.

Treballem amb el Microsoft DHCP i el Microsoft DNS

Benvolguts Lectors, aquest capítol està fora de el context d'un bloc dedicat a l'Programari Lliure. Consulteu l'ajuda de Microsoft. No creuen ?. 😉

Conclusions

Hi ha diverses formes de treballar el Microsoft DNS quan fem que convisqui en una Xarxa PIME amb el dnsmasq. Entre elles esmentarem només les següents:

  • Aturar totalment el servei Microsoft DNS en l'equip on s'estigui executant, indicant després que l'inici de l'servei està inhabilitat. Desmarcar en la configuració de la targeta de xarxa de cada client Microsoft l'opció que Registri la direcció de la connexió al DNS. Eliminar de l'arxiu /etc/dnsmasq.conf la directiva server = / mordor.fan / 10.10.10.3. notes:
    • Tot i que no es respongui a les consultes sobre els registres SOA y NS, La xarxa funcionarà correctament, així com la unió dels diferents clients -Microsoft® i Linux- a l'Domini de l'Active Directory®.
    • Té l'avantatge que en la LAN PIME només hi haurà un Servidor de Noms de Domini -mascle machote- i serà el dnsmasq. ;-). D'altra banda, s'elimina la possibilitat que ocorrin inconsistències entre els registres DNS emmagatzemats al Microsoft DNS i els disponibles mitjançant el dnsmasq.
  • Deixar en funcionament el Microsoft DNS perquè respongui només les consultes DNS sobre els registres SOA i NS. Notas:
    • Modificar la configuració de la targeta de xarxa de cada client Windows, desmarcant l'opció que Registri la direcció de la connexió al DNS.
    • pensem que aquesta solució és un malbaratament de recursos.
  • Configura els serveis com hem vist al llarg de tot l'article, el qual mostra una solució més de l'agradi de la filosofia Microsoft -que no FreeBSD / Linux- Ok ?.

Resum

  • La proposta de l'Microsoft® DNS és molt tancada. No deixa cap espai per a altres solucions que no estiguin d'acord a la seva hermètica filosofia.
  • La Mare Naturalesa ens ensenya que existim en un univers divers. El normal és tenir una LAN mixta, en moviment cap al Programari Lliure, i rica en vida i varietat.
  • Tal sembla que per Microsoft, els clients que no s'uneixin a la seva Filosofia són uns Marginats, i per tant, no ha molestar-se a tenir-los en consideració.
  • Que difícil és treballar amb Programari Privat !. Prefereixo passar una mica de treball configurant Programari Lliure i ser veritablement Lliure, ¡carai !.

«El Millor Criteri de la Veritat és la Pràctica».


Deixa el teu comentari

La seva adreça de correu electrònic no es publicarà. Els camps obligatoris estan marcats amb *

*

*

  1. Responsable de les dades: Miguel Ángel Gatón
  2. Finalitat de les dades: Controlar l'SPAM, gestió de comentaris.
  3. Legitimació: El teu consentiment
  4. Comunicació de les dades: No es comunicaran les dades a tercers excepte per obligació legal.
  5. Emmagatzematge de les dades: Base de dades allotjada en Occentus Networks (UE)
  6. Drets: En qualsevol moment pots limitar, recuperar i esborrar la teva informació.

  1.   Zodiac Carburus va dir

    Magnífic article que has escrit, Federico!

  2.   Juliol Lleó va dir

    Tremendo article meu estimat. I el resum és del millor XD
    Sldos;

  3.   llangardaix va dir

    No crec haver vist a l'internet (en llenguatge espanyol) una guia més completa i detallada per sysadmin, la feina que estàs fent en Xarxes per a Pimes és per emmarcar.

    Si bé el treball és ardu i arribar a aquest nivell de detall és qüestió de moltes hores, crec que estàs creant un punt de referència que serà utilitzat en la mesura que es vagi coneixent per una gran quantitat de SysAdmin que tenen en els teus articles la clau mestra per a moltes de les activitats a què s'enfronta a diaios.

    En quan a dnsmasq i activi directory, crec no haver tingut l'oportunitat mai de treballar amb tots dos, però en el meu laboratori a falta d'algun client windows, tot sembla haver quedat bé, i no és per menys amb aquest excel·lent pas a pas.

    Rescatar la teva frase «Que difícil és treballar amb Programari Privat !. Prefereixo passar una mica de treball configurant Programari Lliure i ser veritablement Lliure, ¡carall!. »... Anem que d'a poc això de passar una mica de treball configurant programari lliure es va saltant en temps, més que tot per documentació com la teva i de molta altra gent, com també amb la constant humanització de programari lliure.

    Enhorabona fic ... Seguim endavant.

  4.   federico va dir

    Zodiac: Les teves paraules són al·licient per a seguir escrivint. No ho dubtis, moltes bones hores - natges són necessàries per escriure un modest article com aquest.

    Julio León: Salutacions per a tu també, estimat juliol. Tant de bo i continuïs amb nosaltres en la sendera de conèixer una mica més sobre Programari Lliure.

    Llangardaix: Els dies i hores dedicats ben valen la pena quan llegeixo comentaris com els d'aquest post. Són la millor recompensa per la nostra feina. A el propi Simon Kelley li vaig passar l'enllaç de l'article i va tenir la gran amabilitat de respondre'mi.

    Vull aprofitar aquest espai per dir que en el tema DNS i DHCP vam començar -per estratègia- del que complex al que és fàcil. El dnsmasq és una molt vàlida solució per a les Xarxes PIME, i és molt més fàcil d'implementar que la dupla BIND + Isc-dhcp-Server. Pot ser que a molts lectors li sembli una mica tècnic el tema. Amb el temps i l'pràctica s'adonaran que no és així. Bé val la pena estudiar els Principis d'un Servidor d'Infraestructura, títol que abastaria als 6 articles escrits sobre els serveis DNS i DHCP, sense oblidar a l'NTP.

    Enhorabona a tots ... Seguim endavant!

  5.   IWO va dir

    Gràcies Federico per un altre gran article amb tremend detall i àmplia teoria sobre dnsmasq, eina que ja veiem que és summament útil per als sysadmins.

    GENIAL tot el relacionat amb la inserció al seu arxiu de configuració /etc/dnsmasq.conf de la Zona «_msdcs.mordor.fan» de l'Microsoft DNS per mitjà dels seus registres SRV que fan servir els serveis: _gc, _ldap, _kerberos i _kpasswd amb l'objectiu d'utilitzar el Microsoft DNS (instrucció «server = / mordor.fan / 10.10.10.3») a més de l'dnsmasq (instrucció «local = / mordor.fan /») per resoldre consultes DNS.

    BONÍSSIM també l'exemple desenvolupat que perquè el Microsoft DNS registri els clients Windows amb canvis d'IP a la LAN, cal seleccionar en la configuració de l'DNS, les «Dynamic updates» com «Nonsecure and secure» i el que això implica en la vulnerabilitat de la seguretat de qualsevol Servidor de Noms de Domini que es respecti, sigui de Microsoft o UNIX / Linux. A més de ser necessària la modificació en la configuració de la targeta de xarxa de client Windows.
    ! Res que amb cada nou post puges la parada! Esperant ansiosament els sgtes articles!

    1.    federico va dir

      Gràcies mil per la teva avaluació i comentari, IWO. A cada article que va publicar, sempre espero la teva opinió, ja que està avalada per la teva ocupació, coneixements i pràctica. Enhorabona IWO. Ens veurem en el proper article

  6.   caçador va dir

    Molt bon treball fic, com sempre publicant aquestes joies per sysadmins. Gràcies mil!

  7.   crespo88 va dir

    Dóna-li un chance a el DNS de Microsoft, no has deixat ni que tregui el cap. No sabem si segueix viu o tan sols si vergonya li queda. Excel·lent article.

  8.   HO2Gi va dir

    Una joia com cap, guardat en favorits per a consultes. Excel·lent article.

  9.   federico va dir

    Gràcies HO2Gi per la teva valoració. Et recomano -i en general a tots- visites https://blog.desdelinux.net/redes-computadoras-las-pymes-introduccion/. Es va editar novament amb un índex de tots els posts publicats i els temes per tractar. Salutacions i continua amb nosaltres.

  10.   Pau Andrés Flemmer va dir

    Excel·lent document a l'igual que l'disponible a https://blog.desdelinux.net/bind-active-directory/
    Només vull fer-li una recomanació, i si us plau prengui-ho com una crítica constructiva; per exemplificar la configuració hagués estat millor que en comptes d'utilitzar la xarxa 10.10.10.0/24 utilitzés una on cada bloc tingués diferents nombres, com ara la xarxa 192.168.1.0/24.
    Això faria veure més clar els punts on les direccions de xarxa van en forma inversa, com per exemple quan cal agregar valors de l'tipus «.in-addr.arpa»
    Li agraeixo compartir tant coneixement de bona qualitat.
    Salutacions cordials.