BIND ו- Active Directory® - רשתות SME

אינדקס כללי של הסדרה: רשתות מחשבים עבור חברות קטנות ובינוניות: מבוא

שלום חברים!. המטרה העיקרית של מאמר זה היא להראות כיצד אנו יכולים לשלב את שירות ה- DNS המבוסס על ה- BIND9 ברשת של מיקרוסופט, נפוץ מאוד בקרב חברות קטנות ובינוניות רבות.

זה נובע מבקשתו הרשמית של חבר המתגורר בלה טיירה דל פואגו -הפוג'יאן- מתמחה ברשתות Microsoft® - אישורים כלולים - להנחות אותך בחלק זה של העברת השרתים שלך לינוקס. העלויות של תמיכה טכנאים שמשלמים ל- Microsoft® כבר בִּלתִי נִסבָּל עבור החברה בה הוא עובד וממנה הוא בעל המניות הראשי שלו.

חבר שלי הפוג'יאן בעל חוש הומור נהדר, ומאז שראה את סדרת שלושה הסרטים «שר הטבעות»הוא נשבה ברבים משמות הדמויות האפלות שלו. לכן, חבר הקורא, אל תתפלאו משמות הדומיין שלכם והשרתים שלכם.

למתחילים בנושא ולפני שתמשיך לקרוא, אנו ממליצים לך לקרוא וללמוד את שלושת המאמרים הקודמים בנושא רשתות קטנות ובינוניות:

• DNS ו- DHCP ב- openSUSE 13.2 "הארלקין"
• DNS ו- DHCP ב- CentOS 7
• DNS ו- DHCP בדביאן 8 "ג'סי"

זה כמו לראות שלושה מתוך ארבעת החלקים של «העולם התחתון»פורסם עד היום, וכי זהו הרביעי.

פרמטרים כלליים

לאחר מספר חילופי דרך דוא"ל, סוף סוף היה לי ברור לגבי הפרמטרים העיקריים של הרשת הנוכחית שלך, שהם:

שם מתחם mordor.fan רשת LAN 10.10.10.0/24 ======================================== ============================================== שרתים כתובת IP מטרה (שרתים עם מערכת הפעלה חלונות) ==================================================== ================================= sauron.mordor.fan. 10.10.10.3 Active Directory® 2008 SR2 mamba.mordor.fan. 10.10.10.4 שרת קבצים של חלונות 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

ביקשתי רשות ל הפוג'יאן לקבוע כינויים רבים ככל שיידרש כדי לנקות את דעתי ונתן לי את אישורו:

אמיתי CNAME ================================ sauron ad-dc mamba fileserver darklord proxyweb troll blog shadowftp ftpserver blackelf mail blackspider www palantir openfire

הכרזתי על כל רשומות ה- DNS החשובות בהתקנתי של Active Directory Windows 2008 שנאלצתי ליישם כדי להנחות אותי ביצירת פוסט זה.

מידע על רשומות SRV ב- Active Directory

המרשמים SRV o מאתר שירותים - שנמצא בשימוש נרחב ב- Microsoft Active Directory - מוגדרים ב- בקשה לתגובות RFC 2782. הם מאפשרים מיקום של שירות המבוסס על פרוטוקול TCP / IP באמצעות שאילתת DNS. לדוגמא, לקוח ברשת מיקרוסופט יכול לאתר את מיקומם של בקרי תחום - בקרי תחום המספקים את שירות LDAP באמצעות פרוטוקול TCP ביציאה 389 באמצעות שאילתת DNS אחת.

זה נורמלי שביערות - יערותועצים - עצים של רשת מיקרוסופט גדולה ישנם מספר בקרי תחום. על ידי שימוש ברשומות ה- SRV באזורים השונים המרכיבים את מרחב שמות הדומיין של אותה רשת, אנו יכולים לשמור על רשימת שרתים המספקים שירותים ידועים דומים, לפי סדר העדפה לפי פרוטוקול התחבורה והנמל של כל אחד מהם. אחד השרתים.

ב בקשה לתגובות RFC 1700 הגדרת שמות סמלים אוניברסליים לשירותים ידועים - שירות ידוע, ושמות כמו «_ Telnet«Wonderful_smtp»לשירותים Telnet y SMTP. אם לא מוגדר שם סמלי עבור שירות ידוע, ניתן להשתמש בשם מקומי או בשם אחר בהתאם להעדפות המשתמש.

מטרת כל תחום «מיוחד»המשמש בהצהרה על רשומת משאבים של SRV הוא כדלקמן:

• תְחוּם: "Pdc._msdcs.mordor.fan.«. שם ה- DNS של השירות אליו מתייחס רשומת SRV. פירוש שם ה- DNS בדוגמה הוא - פחות או יותר- בקר תחום ראשי של האזור _msdcs.mordor.fan.
• שֵׁרוּת: "_Ldap". שם סמלי של השירות הניתן מוגדר על פי בקשה לתגובות RFC 1700.
• פרוטוקול: "_Tcp". מציין את סוג פרוטוקול התחבורה. בדרך כלל יכול לקחת את הערכים _tcp o _udp, למרות-ולמעשה- כל סוג של פרוטוקול תחבורה המצוין ב- בקשה לתגובות RFC 1700. למשל, עבור שירות צ'אט מבוסס פרוטוקול XMPP, לשדה זה יהיה הערך של _xmpp.
• עדיפות"0«. הצהיר על העדיפות או ההעדפה של מארח המציע שירות זה שנראה בהמשך. שאילתות ה- DNS של הלקוחות לגבי השירות המוגדר על ידי רשומת SRV זו, עם קבלת התשובה המתאימה, ינסו ליצור קשר עם המארח הזמין הראשון עם המספר הנמוך ביותר שרשום בשדה. עדיפות. טווח הערכים שדה זה יכול לקחת הוא 0 65535.
• מִשׁקָל"100«. ניתן להשתמש בשילוב עם עדיפות לספק מנגנון איזון עומסים כאשר ישנם מספר שרתים המספקים את אותו השירות. צריך להיות רשומת SRV דומה עבור כל שרת בקובץ ה- Zone, ושמו מוכרז בשדה מארח המציע שירות זה. לפני שרתים עם ערכים שווים בשטח עדיפות, ערך השדה מִשׁקָל ניתן להשתמש בו כרמת העדפה נוספת לקבלת בחירת שרת מדויקת לאיזון עומסים. טווח הערכים שדה זה יכול לקחת הוא 0 65535. אם לא נדרש איזון עומסים, למשל כמו במקרה של שרת יחיד, מומלץ להקצות את הערך 0 כדי להקל על קריאת ה- SRV.
• מספר נמל - נמל"389«. מספר יציאה ב מארח המציע שירות זה המספק את השירות המצוין בשטח שֵׁרוּת. מספר היציאה המומלץ לכל סוג שירות ידוע מצוין ב- בקשה לתגובות RFC 1700, אם כי זה יכול לקחת ערך בין 0 ו65535.
• מארח המציע שירות זה - יעד"מאוורר.סורון.מורדור.«. מציין את FQDN שמזהה באופן חד משמעי את המארח המספק את השירות המצוין על ידי רשומת SRV. סוג רשומה «A»במרחב שמות הדומיינים לכל אחד FQDN מהשרת או המארח המספק את השירות. פשוט יותר, רשומת טיפוסים A באזור / ים הישירים.
  • הערה:
    כדי לציין סמכותית שהשירות שצוין על ידי רשומת SRV אינו מסופק במארח זה, יחיד (.נקודה.

אנו רק רוצים לחזור על כך שפעולה נכונה של רשת או של Active Directory® נשענת במידה רבה על פעולה נכונה של שירות שמות הדומיינים..

רשומות DNS של Active Directory

כדי להפוך את אזורי שרת ה- DNS החדש למבוססים על BIND, עלינו להשיג את כל רשומות ה- DNS מ- Active Directory®. כדי להקל על החיים אנו הולכים לצוות מאוורר.סורון.מורדור -Active Directory® 2008 SR2- ובמסוף ניהול ה- DNS אנו מפעילים את העברת Zone -direct והפוך- עבור האזורים העיקריים המוצהרים בשירות מסוג זה, שהם:

• _msdcs.mordor.fan
• mordor.fan
• 10.10.10.in-addr.harp

לאחר שבוצע השלב הקודם ורצוי ממחשב לינוקס שכתובת ה- IP שלו נמצאת בתחום רשת המשנה המשמשת את רשת Windows, אנו מבצעים:

buzz @ sysadmin: ~ $ dig @ 10.10.10.3 _msdcs.mordor.fan axfr> זמני /rrs._msdcs.mordor.fan
buzz @ sysadmin: ~ $ dig @ 10.10.10.3 mordor.fan axfr> temp / rrs.mordor.fan
buzz @ sysadmin: ~ $ dig @ 10.10.10.3 10.10.10.in-addr.arpa axfr> temp / rrs.10.10.10.in-addr.arpa

• זכור ממאמרים קודמים שכתובת ה- IP של המכשיר מנהל מערכת.desdelinux.אוהד הוא 10.10.10.1 או 192.168.10.1.

בשלוש הפקודות הקודמות אנו יכולים לבטל את האפשרות 10.10.10.3 -שאל את שרת ה- DNS עם כתובת זו- אם אנו מצהירים בתיק / Etc / resolv.conf לשרת ה- IP מאוורר.סורון.מורדור:

buzz@sysadmin:~$ cat /etc/resolv.conf 
# Generated by NetworkManager
search desdelinux.fan
nameserver 192.168.10.5
nameserver 10.10.10.3

לאחר עריכה בזהירות רבה, כמקביל לכל קובץ אזור ב- BIND, נקבל את הנתונים הבאים:

רשומות RR מאזור המקורי _msdcs.mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs._msdcs.mordor.fan 
; מתייחס ל- SOA ו- NS _msdcs.mordor.fan. 3600 ב- SOA sauron.mordor.fan. hostmaster.mordor.fan. 12 900 600 86400 3600 _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; קטלוג עולמי gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; כינויים - במסד הנתונים LDAP המתוקן והפרטי של מדריך פעיל - של SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 IN CNAME sauron.mordor.fan. ; ; LDAP שונה ופרטי של Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS שונה ופרטי מ- Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.

רשומות RR מהאזור המקורי mordor.fan

buzz @ sysadmin: ~ $ cat temp / rrs.mordor.fan 
; מתייחס ל- SOA, NS, MX ולרשומת ה- A שהיא ממפה; שם התחום ל- IP של SAURON; דברים מ- Active Directory mordor.fan. 3600 ב- SOA sauron.mordor.fan. hostmaster.mordor.fan. 48 900 600 86400 3600 mordor.fan. 600 IN A 10.10.10.3 mordor.fan. 3600 IN NS sauron.mordor.fan. mordor.fan. 3600 IN MX 10 blackelf.mordor.fan. _msdcs.mordor.fan. 3600 IN NS sauron.mordor.fan. ; ; חשוב גם A מתעד DomainDnsZones.mordor.fan. 600 IN A 10.10.10.3 ForestDnsZones.mordor.fan. 600 IN A 10.10.10.3; ; קטלוג גלובלי _gc._tcp.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. ; ; LDAP שונה ופרטי של Active Directory _ldap._tcp.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS שונה ופרטי מתוך Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 100 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 IN SRV 0 100 464 sauron.mordor.fan. ; ; רשומות עם כתובות IP קבועות -> שרתי Blackelf.mordor.fan. 3600 IN A 10.10.10.9 blackspider.mordor.fan. 3600 IN 10.10.10.10 darklord.mordor.fan. 3600 IN A 10.10.10.6 mamba.mordor.fan. 3600 IN A 10.10.10.4 palantir.mordor.fan. 3600 ב 10.10.10.11 sauron.mordor.fan. 3600 IN A 10.10.10.3 shadowftp.mordor.fan. 3600 IN 10.10.10.8 troll.mordor.fan. 3600 IN A 10.10.10.7; ; CNAME מתעד את ad-dc.mordor.fan. 3600 ב- CNAME sauron.mordor.fan. blog.mordor.fan. 3600 ב- CNAME troll.mordor.fan. fileserver.mordor.fan. 3600 ב- CNAME mamba.mordor.fan. ftpserver.mordor.fan. 3600 ב- CNAME shadowftp.mordor.fan. mail.mordor.fan. 3600 ב- CNAME balckelf.mordor.fan. openfire.mordor.fan. 3600 ב- CNAME palantir.mordor.fan. proxy.mordor.fan. 3600 ב- CNAME darklord.mordor.fan. www.mordor.fan. 3600 ב- CNAME blackspider.mordor.fan.

רשומות RR מאזור המקורי 10.10.10.in-addr.arpa

buzz @ sysadmin: ~ $ cat temp / rrs.10.10.10.in-addr.arpa 
; מתייחס ל- SOA ו- NS 10.10.10.in-addr.arpa. 3600 ב- SOA sauron.mordor.fan. hostmaster.mordor.fan. 21 900 600 86400 3600 10.10.10.in-addr.arpa. 3600 IN NS sauron.mordor.fan. ; ; רשומות PTR 10.10.10.10.in-addr.arpa. 3600 IN PTR blackspider.mordor.fan. 11.10.10.10.in-addr.arpa. 3600 IN PTR palantir.mordor.fan. 3.10.10.10.in-addr.arpa. 3600 ב PTR sauron.mordor.fan. 4.10.10.10.in-addr.arpa. 3600 ב PTR mamba.mordor.fan. 5.10.10.10.in-addr.arpa. 3600 ב- PTR dnslinux.mordor.fan. 6.10.10.10.in-addr.arpa. 3600 ב PTR darklord.mordor.fan. 7.10.10.10.in-addr.arpa. 3600 בטרול PTR.mordor.fan. 8.10.10.10.in-addr.arpa. 3600 IN PTR shadowftp.mordor.fan. 9.10.10.10.in-addr.arpa. 3600 ב PTR blackelf.mordor.fan.

עד לנקודה זו אנו יכולים לחשוב שיש לנו את הנתונים הדרושים כדי להמשיך בהרפתקה שלנו, לא בלי להתבונן קודם ב TTL ונתונים אחרים שבאופן תמציתי מאוד הפלט והתצפית הישירה על ה- DNS של Microsft® Active Directory® 2008 SR2 64 ביט מספקים לנו.

תמונות של מנהל ה- DNS בסאורון

צוות Dnslinux.mordor.fan.

אם נסתכל מקרוב, אל כתובת ה- IP 10.10.10.5 שום שם לא הוקצה לו בדיוק כדי שייכבש בשם ה- DNS החדש dnslinux.mordor.fan. כדי להתקין את צמד ה- DNS וה- DHCP אנו יכולים להיות מונחים על ידי המאמרים DNS ו- DHCP בדביאן 8 "ג'סי" y DNS ו- DHCP ב- CentOS 7.

מערכת הפעלה בסיסית

חבר שלי הפוג'יאןבנוסף להיותו מומחה אמיתי ב- Microsoft® Windows - יש לו כמה אישורים שהונפקו על ידי אותה חברה - הוא קרא והוציא לפועל כמה מהמאמרים על שולחנות העבודה שפורסמו ב- DesdeLinux., והוא אמר לי שהוא רוצה במפורש פתרון מבוסס דביאן. 😉

כדי לרצות אותך, נתחיל בהתקנה חדשה ונקייה של שרת על בסיס דביאן 8 "ג'סי". עם זאת, מה שנכתוב בהמשך תקף להפצות CentOS ו- openSUSE שאת המאמרים שלהם הזכרנו קודם. BIND ו- DHCP זהים בכל הפצה. שומרי החבילה מוצגים בווריאציות קלות בכל הפצה.

אנו נעשה את ההתקנה כמצוין בסעיף DNS ו- DHCP בדביאן 8 "ג'סי", דואג להשתמש ב- IP 10.10.10.5 והרשת 10.10.10.0/24., עוד לפני קביעת התצורה של ה- BIND.

אנו מגדירים את ה- BIND בסגנון דביאן

/etc/bind/named.conf

את הקובץ /etc/bind/named.conf אנו משאירים אותו כשהוא מותקן.

/etc/bind/named.conf.options

את הקובץ /etc/bind/named.conf.options צריך להשאיר את התוכן הבא:

root @ dnslinux: ~ # cp /etc/bind/named.conf.options /etc/bind/named.conf.options.original

root @ dnslinux: ~ # nano /etc/bind/named.conf.options
אפשרויות {directory "/ var / cache / bind"; // אם יש חומת אש בינך לבין שרת שמות שאתה רוצה // לדבר איתם, ייתכן שיהיה עליך לתקן את חומת האש כדי לאפשר למספר // יציאות לדבר. ראה http://www.kb.cert.org/vuls/id/800113 // אם ספק שירותי האינטרנט שלך סיפק כתובת IP אחת או יותר עבור שרתים // שמות יציבים, סביר להניח שתרצה להשתמש בהם כמעבירים. // בטל את ההערה של החסימה הבאה והוסף את הכתובות המחליפות // את מציין המיקום של all-0. // משלחים {// 0.0.0.0; //}; // ================================================== ====================== $ // אם BIND רושם הודעות שגיאה לגבי פג תוקף מפתח הבסיס, // יהיה עליכם לעדכן את המפתחות. ראה https://www.isc.org/bind-keys // ==================================== ===================================== $

    // אנחנו לא רוצים DNSSEC
        לא מאפשר dnssec;
        //אימות dnssec אוטומטי;

        auth-nxdomain לא; # תואם ל- RFC1035

 // אנחנו לא צריכים להקשיב לכתובות IPv6
        // האזנה ב- v6 {any; };
    להקשיב ב- v6 {none; };

 // לבדיקות מ- localhost ו- sysadmin
    // דרך // לחפור mordor.fan axfr // dig 10.10.10.in-addr.arpa axfr // dig _msdcs.mordor.fan axfr // אין לנו DNS Slave ... עד עכשיו
 העברת הרשאה {localhost; 10.10.10.1; };
};

// רישום BIND
רישום {

        שאילתות ערוץ {
        קובץ "/var/log/named/queries.log" בגירסאות 3 בגודל 1 מ ';
        מידע על חומרה;
        זמן הדפסה כן;
        חומרת הדפסה כן;
        קטגוריית הדפסה כן;
        };

        שגיאת שאילתת ערוץ {
        קובץ "/var/log/named/query-error.log" גרסאות 3 גודל 1m;
        מידע על חומרה;
        זמן הדפסה כן;
        חומרת הדפסה כן;
        קטגוריית הדפסה כן;
        };

                                
שאילתות קטגוריה {
         שאילתות;
         };

שגיאות שאילתת קטגוריה {
         שגיאת שאילתה;
         };

};

• אנו מציגים את לכידת יומני BIND כ- חדש הופעה בסדרת המאמרים בנושא. אנו יוצרים lתיקיה וקבצים הנדרשים עבור ה- רישום של ה- BIND:

root @ dnslinux: ~ # mkdir / var / log / בשם
root @ dnslinux: ~ # touch /var/log/named/queries.log
root @ dnslinux: ~ # touch /var/log/named/query-error.log
root @ dnslinux: ~ # chown -R bind: bind / var / log / named

אנו בודקים את התחביר של הקבצים שהוגדרו

root @ dnslinux: ~ # named-checkconf 
root @ dnslinux: ~ #

/etc/bind/named.conf.local

אנו יוצרים את הקובץ /etc/bind/zones.rfcFreeBSD עם אותו תוכן כפי שצוין ב DNS ו- DHCP בדביאן 8 "ג'סי".

root @ dnslinux: ~ # nano /etc/bind/zones.rfcFreeBSD

את הקובץ /etc/bind/named.conf.local צריך להשאיר את התוכן הבא:

// // בצע כאן תצורה מקומית // // שקול להוסיף כאן את אזורי 1918, אם הם לא משמשים בארגון שלך //
כוללים "/etc/bind/zones.rfc1918"; כוללים "/etc/bind/zones.rfcFreeBSD";

אזור "mordor.fan" {סוג מאסטר; קובץ "/var/lib/bind/db.mordor.fan"; }; אזור "10.10.10.in-addr.arpa" {master master; קובץ "/var/lib/bind/db.10.10.10.in-addr.arpa"; };

אזור "_msdcs.mordor.fan" {סוג מאסטר;
 שמות צ'קים מתעלמים; קובץ "/etc/bind/db._msdcs.mordor.fan"; }; root @ dnslinux: ~ # named-checkconf
root @ dnslinux: ~ #

קובץ אזור mordor.fan

root @ dnslinux: ~ # ננו /var/lib/bind/db.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; 1D סדרתי; רענן 1H; נסה שוב 1W; תפוג 3H); מינימום או; זמן מטמון שלילי לחיות;
; היה זהיר מאוד עם הרשומות הבאות
@ IN NS dnslinux.mordor.fan.
@ IN A 10.10.10.5
@ IN MX 10 blackelf.mordor.fan. @ IN TXT "ברוך הבא ל"הלאן האפל של מורדור";
_msdcs.mordor.fan. ב- NS dnslinux.mordor.fan.
;
dnslinux.mordor.fan. ב 10.10.10.5
; נגמר בזהירות רבה עם הרשומות הבאות;
DomainDnsZones.mordor.fan. ב 10.10.10.3 ForestDnsZones.mordor.fan. ב 10.10.10.3; ; קטלוג כללי _gc._tcp.mordor.fan. 600 IN SRV 0 0 3268 sauron.mordor.fan. _gc._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 3268 sauron.mordor.fan. ; ; LDAP שונה ופרטי של Active Directory _ldap._tcp.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.DomainDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. _ldap._tcp.ForestDnsZones.mordor.fan. 600 IN SRV 0 0 389 sauron.mordor.fan. ; ; KERBEROS שונה ופרטי מ- Active Directory _kerberos._tcp.Default-First-Site-Name._sites.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kerberos._tcp.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kpasswd._tcp.mordor.fan. 600 IN SRV 0 0 464 sauron.mordor.fan. _kerberos._udp.mordor.fan. 600 IN SRV 0 0 88 sauron.mordor.fan. _kpasswd._udp.mordor.fan. 600 IN SRV 0 0 464 sauron.mordor.fan. ; ; רשומות A עם IP קבוע -> שרתים blackelf.mordor.fan. ב 10.10.10.9 blackspider.mordor.fan. ב 10.10.10.10 darklord.mordor.fan. ב 10.10.10.6 mamba.mordor.fan. ב 10.10.10.4 palantir.mordor.fan. ב 10.10.10.11
sauron.mordor.fan. ב 10.10.10.3
shadowftp.mordor.fan. בטרול 10.10.10.8 טרול.mordor.fan. ב 10.10.10.7; ; CNAME מתעד את ad-dc.mordor.fan. ב- CNAME sauron.mordor.fan. blog.mordor.fan. ב- CNAME troll.mordor.fan. fileserver.mordor.fan. ב- CNAME mamba.mordor.fan. ftpserver.mordor.fan. ב- CNAME shadowftp.mordor.fan. mail.mordor.fan. ב- CNAME balckelf.mordor.fan. openfire.mordor.fan. ב- CNAME palantir.mordor.fan. proxy.mordor.fan. ב- CNAME darklord.mordor.fan. www.mordor.fan. ב- CNAME blackspider.mordor.fan.

root @ dnslinux: ~ # named-checkzone mordor.fan /var/lib/bind/db.mordor.fan 
אזור mordor.fan/IN: טעון סדרתי 1 בסדר

הזמנים TTL 600 מכל רושמי ה- SRV נשמור אותם במקרה שנתקין BIND Slave לעתיד. רשומות אלה מייצגות שירותי Active Directory® שקוראים בעיקר נתונים ממסד הנתונים LDAP שלך. מאחר שמסד נתונים זה משתנה לעתים קרובות, יש לשמור על זמני הסינכרון בתכנית DNS - Master - Slave. על פי הפילוסופיה של מיקרוסופט שנצפתה מ- Active Directory 2000 עד 2008, הערך של 600 נשמר עבור סוגים אלה של רשומות SRV.

ل TTL של השרתים עם IP קבוע, הם נמצאים בזמן המוצהר ב- SOA של 3 שעות.

קובץ אזור 10.10.10.in-addr.arpa

root @ dnslinux: ~ # ננו /var/lib/bind/db.10.10.10.in-addr.arpa
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; 1D סדרתי; רענן 1H; נסה שוב 1W; תפוג 3H); מינימום או; זמן מטמון שלילי לחיות; @ IN NS dnslinux.mordor.fan. ; 10 IN PTR blackspider.mordor.fan. 11 ב- PTR palantir.mordor.fan. 3 ב PTR sauron.mordor.fan. 4 ב- PTR mamba.mordor.fan. 5 ב- PTR dnslinux.mordor.fan. 6 ב PTR darklord.mordor.fan. 7 בטרול PTR.mordor.fan. 8 IN PTR shadowftp.mordor.fan. 9 ב PTR blackelf.mordor.fan.

root @ dnslinux: ~ # named-checkzone 10.10.10.in-addr.arpa /var/lib/bind/db.10.10.10.in-addr.arpa 
אזור 10.10.10.in-addr.arpa/IN: טורי סדרתי 1 בסדר

קובץ אזור _msdcs.mordor.fan

בואו ניקח בחשבון את מה שמומלץ בקובץ /usr/share/doc/bind9/README.Debian.gz אודות מיקום הקבצים של אזורי המאסטר שאינם נתונים לעדכונים דינמיים על ידי DHCP.

root @ dnslinux: ~ # nano /etc/bind/db._msdcs.mordor.fan
$ TTL 3H @ IN SOA dnslinux.mordor.fan. root.dnslinux.mordor.fan. (1; 1D סדרתי; רענן 1H; נסה שוב 1W; תפוג 3H); מינימום או; זמן מטמון שלילי לחיות; @ IN NS dnslinux.mordor.fan. ; ; ; קטלוג עולמי gc._msdcs.mordor.fan. 600 IN A 10.10.10.3; ; כינויים - במסד הנתונים LDAP המתוקן והפרטי של מדריך פעיל - של SAURON 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan. 600 IN CNAME sauron.mordor.fan. ; ; LDAP שונה ופרטי של Active Directory _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.gc._msdcs.mordor.fan. 600 IN SRV 0 100 3268 sauron.mordor.fan. _ldap._tcp.pdc._msdcs.mordor.fan. 600 IN SRV 0 100 389 sauron.mordor.fan. ; ; KERBEROS שונה ופרטי מ- Active Directory _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan. _kerberos._tcp.dc._msdcs.mordor.fan. 600 IN SRV 0 100 88 sauron.mordor.fan.

אנו בודקים את התחביר ונוכל להתעלם מהשגיאה שהיא מחזירה, שכן בתצורה של אזור זה בקובץ /etc/bind/named.conf.local אנו כוללים את ההצהרה שמות צ'קים מתעלמים;. האזור יוטען כהלכה על ידי ה- BIND.

root @ dnslinux: ~ # named-checkzone _msdcs.mordor.fan /etc/bind/db._msdcs.mordor.fan 
/etc/bind/db._msdcs.mordor.fan:14: gc._msdcs.mordor.fan: אזור בעלים רע (שמות בדיקה) אזור _msdcs.mordor.fan/IN: טעון סדרתי 1 אישור

root @ dnslinux: ~ # systemctl הפעל מחדש את bind9.service 
root @ dnslinux: ~ # systemctl status bind9.service 
● bind9.service - שרת שם תחום BIND נטען: נטען (/lib/systemd/system/bind9.service; מופעל) Drop-In: /run/systemd/generator/bind9.service.d └─50-insserv.conf- $ named.conf פעיל: פעיל (רץ) מאז יום ראשון 2017 02:12:08 EST; לפני 48 שניות Docs: man: named (38) תהליך: 2 ExecStop = / usr / sbin / rndc stop (code = exited, status = 8 / SUCCESS) PID ראשי: 859 (בשם) CGroup: /system.slice/bind0.service └─864 / usr / sbin / named -f -u bind 9 בפברואר 864:12:08 dnslinux בשם [48]: zone 38.efip864.arpa/IN: טעון סדרתי 3 Feb 6 1:12:08 dnslinux בשם [48 ]: אזור befip38.arpa/IN: נטען סדרתי 864 בפברואר 6 1:12:08 dnslinux בשם [48]: zone 38.efip864.arpa/IN: טעון סדרתי 0 בפברואר 6 1:12:08 dnslinux בשם [48]: אזור 38.efip864.arpa/IN: נטען סדרתי 7 בפברואר 6 1:12:08 dnslinux בשם [48]: אזור mordor.fan/IN: טעון סדרתי 38 בפברואר 864 1:12:08 dnslinux בשם [48]: אזור לדוגמא .org / IN: נטען סדרתי 38 בפברואר 864 1:12:08 dnslinux בשם [48]: אזור _msdcs.mordor.fan/IN: טעון סדרתי 38 בפברואר 864 1:12:08 dnslinux בשם [48]: אזור לא חוקי / IN : נטען סדרתי 38 בפברואר 864 1:12:08 dnslinux בשם [48]: כל האזורים טעונים
12 בפברואר 08:48:38 dnslinux בשם [864]: ריצה

אנו מתייעצים עם ה- BIND

לפני לאחר התקנת DHCP, עלינו לבצע סדרת בדיקות הכוללת אפילו הצטרפות לקוח Windows 7 לתחום mordor.fan מיוצג על ידי Active Directory המותקן במחשב מאוורר.סורון.מורדור.

הדבר הראשון שיש לעשות הוא להפסיק את שירות ה- DNS במחשב מאוורר.סורון.מורדור, והצהיר בממשק הרשת שלך שמעתה ואילך שרת ה- DNS שלך יהיה 10.10.10.5 dnslinux.mordor.fan.

בקונסולה של השרת עצמו מאוורר.סורון.מורדור אנו מבצעים:

Microsoft Windows [נוסח 6.1.7600]
זכויות יוצרים (c) 2009 תאגיד מיקרוסופט. כל הזכויות שמורות.

C: \ משתמשים \ מנהל> nslookup
שרת ברירת מחדל: dnslinux.mordor.fan כתובת: 10.10.10.5

> gc._msdcs
שרת: dnslinux.mordor.fan כתובת: 10.10.10.5 שם: gc._msdcs.mordor.fan כתובת: 10.10.10.3

> mordor.fan
שרת: dnslinux.mordor.fan כתובת: 10.10.10.5 שם: mordor.fan כתובת: 10.10.10.3

> 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs
שרת: dnslinux.mordor.fan כתובת: 10.10.10.5 שם: sauron.mordor.fan כתובת: 10.10.10.3 כינויים: 03296249-82a1-49aa-a4f0-28900f5d256b._msdcs.mordor.fan

> סוג סט = SRV
> _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs
שרת: dnslinux.mordor.fan כתובת: 10.10.10.5 _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mordor.fan SRV serv ice location: עדיפות = 0 משקל = 100 יציאה = 88 שם מארח svr = sauron.mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan כתובת אינטרנט = 10.10.10.3 dnslinux.mordor.fan כתובת אינטרנט = 10.10.10.5
> _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs
שרת: dnslinux.mordor.fan כתובת: 10.10.10.5 _ldap._tcp.18d3360d-8fdb-40cf-a678-d7c420b6d775.domains._msdcs.mordor.fan מיקום שירות SRV: עדיפות = 0 משקל = 100 יציאה = 389 svr host host = sauron .mordor.fan _msdcs.mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan כתובת אינטרנט = 10.10.10.3 dnslinux.mordor.fan כתובת אינטרנט = 10.10.10.5
> יציאה

C: \ משתמשים \ מנהל>

שאילתות DNS מ- מאוורר.סורון.מורדור מספקים.

השלב הבא יהיה ליצור מכונה וירטואלית נוספת עם התקנת חלונות 7. מכיוון שעדיין אין לנו שירות DHCP מותקן, אנו ניתן למחשב בשם «win7»כתובת ה- IP 10.10.10.251. אנו גם מצהירים כי שרת ה- DNS שלך יהיה ה- 10.10.10.5 dnslinux.mordor.fan, וכי תחום החיפוש יהיה mordor.fan. לא נרשום את המחשב הזה ב- DNS מכיוון שנשתמש בו גם לבדיקת שירות DHCP לאחר התקנתו.

לאחר מכן אנו פותחים קונסולה CMD ובזה אנו מבצעים:

Microsoft Windows [נוסח 6.1.7601]
זכויות יוצרים (c) 2009 תאגיד מיקרוסופט. כל הזכויות שמורות.

C: \ משתמשים \ באז> nslookup
שרת ברירת מחדל: dnslinux.mordor.fan כתובת: 10.10.10.5

> mordor.fan
שרת: dnslinux.mordor.fan כתובת: 10.10.10.5 שם: mordor.fan כתובת: 10.10.10.3

> סוג סט = SRV
> _ldap._tcp.DomainDnsZones
שרת: dnslinux.mordor.fan כתובת: 10.10.10.5 _ldap._tcp.DomainDnsZones.mordor.fan מיקום שירות SRV: עדיפות = 0 משקל = 0 יציאה = 389 שם מארח svr = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor .fan כתובת sauron.mordor.fan = 10.10.10.3 dnslinux.mordor.fan כתובת אינטרנט = 10.10.10.5
> _kpasswd._udp
שרת: dnslinux.mordor.fan כתובת: 10.10.10.5 _kpasswd._udp.mordor.fan מיקום שירות SRV: עדיפות = 0 משקל = 0 יציאה = 464 שם מארח = sauron.mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan כתובת אינטרנט = 10.10.10.3 dnslinux.mordor.fan כתובת אינטרנט = 10.10.10.5
> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones
שרת: dnslinux.mordor.fan כתובת: 10.10.10.5 _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.mordor.fan SRV serv ice location: עדיפות = 0 משקל = 0 יציאה = 389 שם מארח = sauron. mordor.fan mordor.fan nameserver = dnslinux.mordor.fan sauron.mordor.fan כתובת אינטרנט = 10.10.10.3 dnslinux.mordor.fan כתובת אינטרנט = 10.10.10.5
> יציאה

C: \ משתמשים \ באז>

שאילתות DNS שנעשו מהלקוח «win7»גם היו מספקים.

ב- Active Directory אנו יוצרים את המשתמש «סרומן«, במטרה להשתמש בו בעת ההצטרפות ללקוח win7 לתחום mordor.fan., בשיטה «ת. ז רשת«, באמצעות שמות משתמש saruman@mordor.fan y administrator@mordor.fan. ההצטרפות הצליחה והוכחה על ידי צילום המסך הבא:

מידע על עדכונים דינמיים ב- Microsoft® DNS ו- BIND

מכיוון שיש לנו שירות DNS שהופסק ב- Active Directory® זה לא היה אפשרי עבור הלקוח «win7»רשום את שמך וכתובת ה- IP שלך ב- DNS זה. הרבה פחות ב dnslinux.mordor.fan מכיוון שלא הצהרנו שום הצהרה אפשר עדכון לכל אחד מהאזורים המעורבים.

וכאן נוצר המאבק הטוב עם חברתי הפוג'יאן. בדוא"ל הראשון שלי על היבט זה הגבתי:

• המאמרים של מיקרוסופט על השימוש ב- BIND וב- Active Directory® ממליצים לאפשר לעדכן, במיוחד את ה- Direct Zone -חדירה- ישירות על ידי לקוחות Windows שכבר הצטרפו לתחום Active Directory.
• זו הסיבה, כברירת מחדל, באזורי ה- DNS של Active Directory® עדכונים דינמיים מאובטחים מותרים על ידי לקוחות Windows שכבר הצטרפו לתחום Active Directory. אם הם לא מאוחדים, הם נמנעים מההשלכות.
• ה- DNS של Active Directory תומך בעדכונים הדינמיים "מאובטח בלבד", "לא מאובטח ומאובטח", או "אף אחד" זהה לאומר NO Updates או None.
• כן באמת הפילוסופיה של מיקרוסופט לא מסכימה שלקוחותיה לא יעדכנו את הנתונים שלהם ב- DNS שלהם, היא לא תשאיר פתוחה אפשרות להשבית עדכונים דינמיים ב- DNS שלהם, אלא אם כן אפשרות זו יישאר למטרות נסתרות יותר.
• מיקרוסופט מציעה "אבטחה" בתמורה לחושך, כמו שאמר לי עמית וחבר שעבר קורסים של תעודות Microsft®. נָכוֹן. בנוסף, אל Fueguino אישר לי את זה.
• לקוח שרוכש כתובת IP באמצעות DHCP המותקן במכונת UNIX® / Linux למשל, לא יוכל לפתור את כתובת ה- IP של שמו. עד שתצטרף לתחום Active Directory, כל עוד Microsoft® או BIND משמשים כ- DNS ללא עדכונים דינמיים מ- DHCP.
• אם אני מתקין DHCP ב- Active Directory® עצמו, עלי להצהיר שהאזורים מתעדכנים על ידי Microsoft® DHCP.
• אם אנו הולכים להשתמש ב- BIND כ- DNS עבור רשת Windows, זה הגיוני ומומלץ להתקין את הצמד BIND-DHCP, כאשר האחרון מעדכן באופן דינמי את ה- BIND והעניין מסתיים.
• בעולם רשתות ה- LAN ב- UNIX® / Linux, מאז שהומצאו עדכונים דינמיים ב- BIND, רק מר DHCP מותר «לַחדוֹר»לגברת BIND עם עדכוניה. הרגיעה שיש בסדר, בבקשה.
• כשאני מצהיר באזור mordor.fan למשל: אפשר עדכון {10.10.10.0/24; };, BIND עצמו מודיע לי בעת התחלה או הפעלה מחדש של:

  • אזור 'mordor.fan' מאפשר עדכונים לפי כתובת IP, שאינה בטוחה

• בעולם ה- UNIX® / Linux הקודש, כל כך רוטב עם DNS אינו קביל.

אתה יכול לדמיין את שאר חילופי הדברים עם חבר שלי הפוג'יאן דרך מיילים, טלגרם צ'אט, שיחות טלפון ששילמו על ידו (כמובן בנאדם, אין לי קילו בשביל זה), ואפילו הודעות דרך יונים מובילות במאה העשרים ואחת!

הוא אפילו איים שלא ישלח לי בן מחיית המחמד שלו, האיגואנה שלו «פטרה»שהוא הבטיח לי במסגרת התשלום. שם באמת נבהלתי. אז התחלתי שוב, אבל מזווית אחרת.

• ה- Active Directory ה"כמעט "שניתן להשיג באמצעות סמבה 4, פותר היבט זה בצורה מופתית, הן כאשר אנו משתמשים ב- DNS הפנימי שלו, והן ב- BIND שחובר לתמיכה באזורי DLZ - Dinamyc אזורים טעונים, או אזורים טעונים באופן דינמי.
• זה ממשיך לסבול מאותו דבר: כאשר לקוח רוכש כתובת IP באמצעות DHCP המותקן ב אחרים במכונת UNIX® / Linux, לא תוכל לפתור את כתובת ה- IP של שמך שלך עד שהוא יצטרף לתחום ה- Samba 4 AD-DC.
• שלב את הצמד BIND-DLZ ו- DHCP באותה מכונה שבה AD-DC סמבה 4 זו עבודה עבור מומחה אמיתי.

הפוג'יאן הוא קרא לי לפרק וצעק עלי: אנחנו לא מדברים AD-DC סמבה 4, אך Microsoft® Active Directory®!. ועניתי בענווה שאני מרוצה מחלק מהמאמרים הבאים שאותם אכתוב.

אז אמרתי לו שההחלטה הסופית על עדכונים דינמיים למחשבי לקוח ברשת שלו הושארה לרצונו החופשי. שאני רק אתן לו את טיפ נכתב לפני בערך אפשר עדכון {10.10.10.0/24; };, ועוד שום דבר. שאני לא אחראי למה שנבע מהפקרות הזאת שכל לקוח Windows - או לינוקס - ברשת שלהם «יחדור»ללא עונש על ה- BIND.

אם היית יודע, ידידי, קורא שזו נקודת הסיום של הקטטה, לא היית מאמין לזה. חבר שלי הפוג'יאן הוא קיבל את הפיתרון - והוא ישלח לי את האיגואנה «פיט«- שעכשיו אני משתף אתכם.

אנו מתקינים ומגדירים את התצורה של DHCP

לפרטים נוספים קראו DNS ו- DHCP בדביאן 8 "ג'סי".

root @ dnslinux: ~ # aptitude התקן שרת isc-dhcp

root @ dnslinux: ~ # nano / etc / default / isc-dhcp-server .... # באילו ממשקים על שרת DHCP (dhcpd) לשרת בקשות DHCP? # הפרד ממשקים מרובים עם רווחים, למשל "eth0 eth1". INTERFACES = "eth0" root @ dnslinux: ~ # dnssec-keygen -a HMAC-MD5 -b 128 -r / dev / urandom -n משתמש dhcp-key
מקש Kdhcp. + 157 + 29836

root @ dnslinux: ~ # חתול Kdhcp-key. +157 + 29836. פרטי
פורמט מפתח פרטי: v1.3 אלגוריתם: 157 (HMAC_MD5) מפתח: 3HT / bg / 6YwezUShKYofj5g == ביטים: AAA = נוצר: 20170212205030 פרסם: 20170212205030 הפעל: 20170212205030

root @ dnslinux: ~ # nano dhcp.key
מפתח dhcp-key {אלגוריתם hmac-md5; סוד "3HT / bg / 6YwezUShKYofj5g =="; };

root @ dnslinux: ~ # install -o root -g bind -m 0640 dhcp.key /etc/bind/dhcp.key
root @ dnslinux: ~ # להתקין -o שורש -g שורש -m 0640 dhcp.key /etc/dhcp/dhcp.key

root @ dnslinux: ~ # nano /etc/bind/named.conf.local
// // בצע כאן תצורה מקומית // // שקול להוסיף כאן את אזורי 1918, אם הם לא משמשים בארגון שלך // כוללים "/etc/bind/zones.rfc1918"; כוללים "/etc/bind/zones.rfcFreeBSD";
// אל תשכח ... שכחתי ושילמתי עם טעויות. ;-)
כוללים "/etc/bind/dhcp.key";


אזור "mordor.fan" {סוג מאסטר;
        אפשר עדכון {10.10.10.3; מקש dhcp-key; };
        קובץ "/var/lib/bind/db.mordor.fan"; }; אזור "10.10.10.in-addr.arpa" {master master;
        אפשר עדכון {10.10.10.3; מקש dhcp-key; };
        קובץ "/var/lib/bind/db.10.10.10.in-addr.arpa"; }; אזור "_msdcs.mordor.fan" {סוג מאסטר; שמות צ'קים מתעלמים; קובץ "/etc/bind/db._msdcs.mordor.fan"; };

root @ dnslinux: ~ # named-checkconf 
root @ dnslinux: ~ #

root @ dnslinux: ~ # nano /etc/dhcp/dhcpd.conf
ביניים בסגנון ddns-update; ddns-updates על; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; התעלם מעדכוני לקוח; מוּסמָך; אפשרות העברת ip כבויה; שם תחום אפשרות "mordor.fan"; כוללים "/etc/dhcp/dhcp.key"; אזור mordor.fan. {ראשית 127.0.0.1; מפתח dhcp-key; } אזור 10.10.10.in-addr.arpa. {ראשית 127.0.0.1; מפתח dhcp-key; } מיקוד מחדש של רשת משותפת {תת רשת 10.10.10.0 מסיכת רשת 255.255.255.0 {נתבי אפשרות 10.10.10.1; מסכת רשת משנה אופציה 255.255.255.0; אפשרות שידור אפשרות 10.10.10.255; שרת שמות מתחם אופציה 10.10.10.5; אפשרות netbios-servers-servers 10.10.10.5; טווח 10.10.10.30 10.10.10.250; }} # END dhcpd.conf

root @ dnslinux: ~ # dhcpd -t
קונסורציום מערכות אינטרנט באינטרנט שרת DHCP 4.3.1 זכויות יוצרים 2004-2014 קונסורציום מערכות אינטרנט. כל הזכויות שמורות. למידע, אנא בקר בכתובת https://www.isc.org/software/dhcp/ קובץ תצורה: /etc/dhcp/dhcpd.conf קובץ מסד נתונים: /var/lib/dhcp/dhcpd. משכיר קובץ PID: / var / run /dhcpd.pid

root @ dnslinux: ~ # systemctl הפעל מחדש את bind9.service 
root @ dnslinux: ~ # systemctl status bind9.service 

root @ dnslinux: ~ # systemctl התחל isc-dhcp-server.service
root @ dnslinux: ~ # systemctl status isc-dhcp-server.service

מה קשור ל בדיקות עם לקוחות, ו שינוי ידני של קבצי Zoneאנו משאירים לך את זה, חבר הקורא, לקרוא אותו ישירות מ DNS ו- DHCP בדביאן 8 "ג'סי"והחל אותו על התנאים שלך בפועל. אכן ביצענו את כל הבדיקות הדרושות והשגנו תוצאות מספקות. כמובן שאנחנו שולחים עותק של כולם אל הפוג'יאן. לא יהיו יותר!

טיפים

כללי

• קבל מידה טובה של סבלנות לפני שתתחיל.
  
• התקן והתקן את ה- BIND תחילה. בדוק הכל וראה את כל הרשומות שהצהרת בכל קובץ משלושת האזורים או יותר, הן מה- Active Directory והן משרת ה- DNS עצמו ב- Linux. אם אפשר, ממכונת לינוקס שאינה מחוברת לתחום, בצע את שאילתות ה- DNS הדרושות ל- BIND.
  
• הצטרף ללקוח Windows עם כתובת IP קבועה לדומיין הקיים ובדוק מחדש את כל הגדרות ה- BIND מלקוח Windows.
• אחרי שאתה ללא ספק בטוח שהתצורה של ה- BIND החדש שלך נכונה לחלוטין, העז להתקין, להגדיר ולהתחיל את שירות DHCP.
• במקרה של שגיאות, חזור על כל ההליך מאפס 0.
• היזהר בהעתקה והדבקה! והמרווחים הנוספים בכל שורה של קבצי ה- name.conf.xxxx
  
• אחר כך הוא לא התלונן - ועוד פחות על ידידי הפוג'י - שהוא לא יעץ כראוי.

טיפים נוספים

• הפרד ומשול.
• ברשת SME זה בטוח ומועיל יותר להתקין BIND סמכותי עבור אזורי ה- LAN הפנימיים שאינו חוזר לאף שרת שורש: רקורסיה לא;.
• ברשת SME הממוקמת תחת ספק גישה לאינטרנט - ספק שירותי אינטרנט, אולי השירותים פרוקסי y SMTP עליהם לפתור שמות דומיינים באינטרנט. הוא דְיוֹנוֹן יש לך אפשרות להכריז על ה- DNS שלך שהוא חיצוני או לא, בזמן שרת דואר מבוסס על פוסט תיקון o MDaemon® אנו יכולים גם להכריז על שרתי ה- DNS בהם נשתמש בשירות זה. במקרים כאלה, כלומר במקרים שאינם מספקים שירותים לאינטרנט ושמתחתם א ספק אינטרנט, אתה יכול להתקין BIND עם משלחים מצביע על ה- DNS של ה- ספק שירותי אינטרנט, ולהצהיר על זה כ- DNS משני בשרתים שצריכים לפתור שאילתות חיצוניות לרשת LAN, אחרת ניתן להכריז עליהם באמצעות קבצי התצורה שלהם.
• אם יש לך אזור מוסמך בכל אחריותךואז עורב תרנגול נוסף:
  • התקן שרת DNS על בסיס NSD, שהוא שרת DNS סמכותי בהגדרתו, המגיב לשאילתות ממחשבים באינטרנט. למידע מסוים מופע יכולת nsd. Protect אנא הגן עליו היטב בכמה שיותר קירות אש. גם חומרה וגם תוכנה. זה יהיה DNS לאינטרנט וזה «קארה»אסור לנו לתת את זה עם מכנסיים נמוכים. 😉
  • מכיוון שמעולם לא ראיתי את עצמי במקרה כזה, כלומר האחראי על אזור המועצה, אצטרך לחשוב טוב מאוד על מה להמליץ ​​על פתרון שמות דומיינים חיצוניים לרשת LAN שלנו עבור השירותים הזקוקים לכך. לקוחות רשת SME לא ממש צריכים את זה. התייעץ עם ספרות מיוחדת, או עם מומחה בנושאים אלה, מכיוון שאני רחוק מלהיות אחד מהם. ברצינות.
  • רקורסיה אינה קיימת בשרתים סמכותיים. בסדר?. במקרה שמישהו יקרה לעשות זאת עם BIND.
• אם כי אנו מציינים במפורש בקובץ /etc/dhcp/dhcpd.conf ההצהרה התעלם מעדכוני לקוח;, אם אנו פועלים על קונסולת מחשבים dnslinux.mordor.fan הסדר journalctl -fאנו נראה זאת בעת הפעלת הלקוח win7.mordor.fan אנו מקבלים את הודעות השגיאה הבאות:

  • 12 בפברואר 16:55:41 dnslinux בשם [900]: לקוח 10.10.10.30 # 58762: עדכון 'mordor.fan/IN' נדחה
    12 בפברואר 16:55:42 dnslinux בשם [900]: לקוח 10.10.10.30 # 49763: עדכון 'mordor.fan/IN' נדחה
    12 בפברואר 16:56:23 dnslinux בשם [900]: לקוח 10.10.10.30 # 63161: עדכון 'mordor.fan/IN' נדחה
    

  • כדי לסלק הודעות אלה, עלינו לעבור לאפשרויות המתקדמות של תצורת כרטיס הרשת ולבטל את הסימון של האפשרות «רשום את כתובות החיבור הזה ב- DNS«. זה ימנע מהלקוח לנסות להירשם בעצמו ב- DNS של לינוקס לנצח ולסיים את הבעיה. מצטער, אבל אין לי עותק של Windows 7 בספרדית. 😉
• כדי לברר את כל השאלות הרציניות - והמטורפות - שלקוח Windows 7 מבצע, עיין ב יומן queries.log שבשביל משהו אנו מצהירים על כך בתצורת BIND. ההזמנה תהיה:

  • root @ dnslinux: ~ # tail -f /var/log/named/queries.log

• אם אינך מאפשר למחשבי הלקוחות שלך להתחבר ישירות לאינטרנט, מדוע אתה זקוק לשרתי ה- Root DNS? זה יקטין משמעותית את תפוקת הפקודה journalctl -f ומזה הקודם, אם שרת ה- DNS הסמכותי שלך עבור האזורים הפנימיים אינו מתחבר ישירות לאינטרנט, דבר שמומלץ מאוד מבחינה ביטחונית.

  root @ dnslinux: ~ # cp /etc/bind/db.root /etc/bind/db.root.original
  root @ dnslinux: ~ # cp / dev / null /etc/bind/db.root

• אם אינך זקוק להצהרה של שרתי השורש, מדוע אתה זקוק לרקורציה - רקורסיה?

  root @ dnslinux: ~ # nano /etc/bind/named.conf.options
  אפשרויות {
   ....
   רקורסיה לא;
   ....
  };

עצות ספציפיות שעדיין אינני ברור בהן

El איש dhcpd.conf אומר לנו את הדברים הבאים בין הרבה דברים רבים אחרים:

        הצהרת ייעול העדכון

            דגל אופטימיזציה לעדכון;

            אם פרמטר אופטימיזציית העדכון אינו נכון עבור לקוח מסוים, השרת ינסה לעדכן DNS עבור לקוח זה בכל פעם שהלקוח יחדש את חוזה השכירות שלו, במקום לנסות רק לעדכן כאשר נראה שהוא נחוץ. זה יאפשר ל- DNS לרפא מחוסר עקביות במסד נתונים ביתר קלות, אך העלות היא ששרת DHCP חייב לבצע עדכוני DNS רבים יותר. אנו ממליצים לקרוא אפשרות זו מופעלת, שהיא ברירת המחדל. אפשרות זו משפיעה רק על ההתנהגות של ערכת עדכון ה- DNS הזמנית, ואין לה כל השפעה על תוכנית עדכון ה- DNS האד-הוק. אם פרמטר זה לא צוין, או שהוא נכון, שרת ה- DHCP יתעדכן רק כאשר פרטי הלקוח ישתנו, הלקוח יקבל חוזה שכירות אחר או שתוקף החכירה של הלקוח יפוג.

התרגום או הפרשנות המדויקים פחות או יותר מותירים לך, קורא יקר.

באופן אישי, זה קרה לי - וזה קרה במהלך הכנת מאמר זה - שכשאני מקשר BIND ל- Active Directory®, זה ממיקרוספט® או סמבה 4, אם אני משנה את שם מחשב לקוח הרשום בתחום Active Directory® או של AD–DC של סמבה 4, הוא שומר על שמו הישן וכתובת ה- IP שלו באזור הישיר, ולא להיפך, שמתעדכן נכון עם השם החדש. במילים אחרות, השמות הישנים והחדשים ממופים לאותה כתובת IP באזור הישיר, ואילו הפוך מופיע רק השם החדש. כדי להבין אותי היטב, עליך לנסות זאת בעצמך.

אני חושב שזה סוג של נקמה כלפי הפוג'יאן -לא לי, בבקשה- על הניסיון להעביר את השירותים שלך ללינוקס.

כמובן שהשם הישן ייעלם כאשר שלו TTL 3600, או הזמן שהכרזנו בתצורת DHCP. אבל אנחנו רוצים שזה ייעלם מיד כפי שזה קורה ב- BIND + DHCP ללא Active Directory דרך.

הפיתרון למצב זה מצאתי על ידי הכנסת ההצהרה עדכון אופטימיזציה כוזב; בסוף החלק העליון של הקובץ /etc/dhcp/dhcpd.conf:

ביניים בסגנון ddns-update; ddns-updates על; ddns-domainname "mordor.fan."; ddns-rev-domainname "in-addr.arpa."; התעלם מעדכוני לקוח;
עדכון אופטימיזציה כוזב;

אם קורא כלשהו יודע יותר על כך, נא להאיר לי. אעריך את זה מאוד.

תקציר

נהנינו מאוד עם זה, נכון? אין סבל מכיוון שיש לנו BIND העובד כשרת DNS ברשת Microsoft®, המציע את כל רשומות ה- SRV ומגיב כראוי לשאילתות ה- DNS שהופנו להם. מצד שני, יש לנו שרת DHCP שמעניק כתובות IP ומעדכן בצורה דינמית את אזורי ה- BIND.

אבל אנחנו לא יכולים לשאול ... כרגע.

אני מקווה שחבר שלי הפוג'יאן היו מאושרים ומרוצים מהצעד הראשון במעבר שלכם ללינוקס כדי להפוך את העלויות הבלתי נסבלות של התמיכה הטכנית של Microsft® לנסבלות.

הערה חשובה

דמות "הפוג'יאן»הוא בדיוני לחלוטין ותוצר של דמיוני. כל דמיון או צירוף מקרים עם אנשים אמיתיים הוא אותו דבר: צירוף מקרים לא רצוני טהור מצדי. יצרתי אותו רק כדי להפוך את הכתיבה והקריאה של מאמר זה לקצת מהנה. עכשיו אם אתה יכול להגיד לי שנושא ה- DNS חשוך. 😉