Í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:
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».
Magnífic article que has escrit, Federico!
Tremendo article meu estimat. I el resum és del millor XD
Sldos;
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.
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!
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!
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
Molt bon treball fic, com sempre publicant aquestes joies per sysadmins. Gràcies mil!
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.
Una joia com cap, guardat en favorits per a consultes. Excel·lent article.
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.
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.