הקדמה
DNS, או מערכת השמות הדומיין, היא לעיתים קשה מאוד בהקשר של למידה כיצד להגדיר אתרי אינטרנט ושרתים. הבנת כיצד DNS פועלת תעזור לך לאבחן בעיות בהגדרת גישה לאתרים שלך ותאפשר לך להרחיב את ההבנה שלך על מה שקורה מאחורי הקלעים.
במדריך זה, נדון במספר מושגים יסודיים בתחום DNS שיעזרו לך להתחיל בהגדרת DNS שלך. לאחר שתסיים את המדריך הזה, אתה צריך להיות מוכן להגדרת שם הדומיין שלך עם DigitalOcean או להקים שרת DNS משלך.
לפני שנתפס בידיים ונקים את השרתים שלך כדי לפתור את הדומיין שלך או להגדיר את הדומיינים שלנו בלוח הבקרה, בואו נבין כמה מושגים בסיסיים על כיצד כל זה בכלל פועל.
מונחי דומיין
צריך להתחיל עם הגדרת המונחים שלנו. בעוד שחלק מהנושאים האלה ידועים מהקשרים השונים, ישנם הרבה מונחים המשמשים בשיחה על שמות דומיין ו-DNS שלא משתמשים בהם כל כך הרבה בתחום אחר של המחשבים.
התחל קל:
מערכת שם התחום
מערכת שם התחום, הידועה יותר כ "DNS", היא המערכת ברשת שמאפשרת לנו לפתור שמות ידידותיים לאנשים לכתובות IP ייחודיות.
שם התחום
A domain name is the human-friendly name that we are used to associating with an internet resource. For instance, “google.com” is a domain name. Some people will say that the “google” portion is the domain, but we can generally refer to the combined form as the domain name.
ה-URL "google.com" משוייך לשרתים שבבעלות חברת Google Inc. מערכת שם התחום מאפשרת לנו להגיע לשרתי Google כאשר אנו מקלידים "google.com" בדפדפנים שלנו.
כתובת IP
כתובת IP היא מיקום של רשת שאפשר להתקשר אליו. על כל כתובת IP להיות ייחודית ברשת שלה. כאשר אנו מדברים על אתרי אינטרנט, הרשת היא כל האינטרנט.
IPv4, הצורה הנפוצה ביותר של כתובות, כתובה כארבע סטים של מספרים, כל סט יכול להכיל עד שלוש ספרות, עם כל סט מופרד בנקודה. לדוגמה, "111.222.111.222" יכול להיות כתובת IP IPv4 תקינה. עם DNS, אנו ממפים שם לכתובת הזאת כך שאין לך לזכור סט מספרים מורכב לכל מקום שתרצה לבקר ברשת.
דומיין עליון
A top-level domain, or TLD, is the most general part of the domain. The top-level domain is the furthest portion to the right (as separated by a dot). Common top-level domains are “com”, “net”, “org”, “gov”, “edu”, and “io”.
דומיינים עליונים נמצאים בראש תודר הדומיינים. גורמים מסוימים מוענקים בקרה ניהולית על דומיינים עליונים על ידי ICANN (החברה לאיזור ולשמות מוקצים לאינטרנט). לאחר מכן, גורמים אלו יכולים להפיץ דומיינים תחת הדומיין העליון, כל זאת בדרך כלל דרך סוחרי דומיינים.
מארחים
בתוך דומיין, בעל הדומיין יכול להגדיר מארחים אישיים, אשר מתייחסים למחשבים או שירותים נפרדים הנגישים דרך הדומיין. לדוגמה, רוב בעלי הדומיין מאפשרים גישה לשרתי האינטרנט שלהם דרך הדומיין העיקרי (example.com) וגם דרך ההגדרה "www" (www.example.com).
ניתן להגדיר מארחים אחרים תחת הדומיין הכללי. ניתן לקבל גישה ל-API דרך מארח "api" (api.example.com) או ניתן לקבל גישה ל-FTP על ידי הגדרת מארח בשם "ftp" או "files" (ftp.example.com או files.example.com). שמות המארחים יכולים להיות שרירותיים כל עוד הם ייחודיים לדומיין.
תת-דומיין
A subject related to hosts are subdomains.
עבודת DNS נעשית בהיררכיה. TLDs יכולים להכיל רבות דומיינים תחתיהם. לדוגמה, ה־TLD "com" מכיל את "google.com" ואת "ubuntu.com" תחתיו. מילת "תת־דומיין" מתייחסת לכל דומיין שהוא חלק מדומיין גדול יותר. במקרה זה, ניתן לומר ש־"ubuntu.com" הוא תת־דומיין של "com". בדרך כלל זה נקרא פשוט הדומיין או החלק "ubuntu" נקרא דומיין רמה שנייה, שקוראים לו SLD.
באופן דומה, כל דומיין יכול לשלוט ב"תת־דומיינים" שנמצאים מתחתיו. זה בדרך כלל מה שאנו מתכוונים כאשר אנו מדברים על תת־דומיינים. לדוגמה, תת־דומיין עבור מחלקת ההיסטוריה של בית הספר שלך יכול להיות "www.history.school.edu". החלק "history" הוא תת־דומיין.
ההבדל בין שם מארח לבין תת־דומיין הוא ששם המארח מגדיר מחשב או משאב, בעוד שתת־דומיין מרחיב את הדומיין האב. זו שיטה לחלוקה של הדומיין עצמו.
בין אם מדובר בתת־דומיינים או במארחים, ניתן לראות כי החלקים השמאליים ביותר של הדומיין הם המפורטים ביותר. זהו אופן עבודת ה־DNS: מהכי מפורט לכי פחות מפורט במהלך קריאה משמאל לימין.
שם דומיין מוכן לשימוש מוחלט
A fully qualified domain name, often called FQDN, is what we call an absolute domain name. Domains in the DNS system can be given relative to one another, and as such, can be somewhat ambiguous. A FQDN is an absolute name that specifies its location in relation to the absolute root of the domain name system.
זה אומר שהוא מפרט כל תחום הורה כולל ה־TLD. FQDN תקין מסתיים בנקודה, מציין את שורש ההיררכיה של DNS. דוגמה ל־FQDN היא "mail.google.com.". לפעמים תוכנה שקוראת FQDN אינה דורשת את הנקודה הסופית, אך הנקודה בסופו נדרשת כדי להיתאם לתקני ICANN.
שרת שמות
A name server is a computer designated to translate domain names into IP addresses. These servers do most of the work in the DNS system. Since the total number of domain translations is too much for any one server, each server may redirect request to other name servers or delegate responsibility for a subset of subdomains they are responsible for.
שרתי שמות יכולים להיות "מורשים", המקנים תשובות לשאילתות על תחומים שבשלטון שלהם. אחרת, הם עשויים לפנות לשרתים אחרים, או לשרת העתקים מקובצי שמות של שרתים אחרים.
קובץ אזור
A zone file is a simple text file that contains the mappings between domain names and IP addresses. This is how the DNS system finally finds out which IP address should be contacted when a user requests a certain domain name.
קבצי אזור ממוקמים בשרתי שמות ובדרך כלל מגדירים את המשאבים הזמינים בתחום ספציפי, או המקום שבו ניתן לקבל את המידע הזה.
רשומות
בתוך קובץ האזור, שומרים רשומות. בצורתה הפשוטה ביותר, רשומה היא בסך הכול מיפוי יחיד בין משאב ושם. אלו יכולים למפתח את שם התחום לכתובת IP, להגדיר את שרתי השמות לתחום, להגדיר את שרתי הדואר לתחום, וכו'.
איך עובד DNS
עכשיו שאתה מכיר חלק מהמונחים המעורבים עם DNS, איך המערכת פועלת בפועל?
המערכת היא פשוטה מאוד ברמה גבוהה, אך מורכבת מאוד כאשר אתה מתבונן בפרטים. בכל זאת, בסך הכול זו תשתית אמינה מאוד שהייתה חיונית לקידום האינטרנט כפי שאנו מכירים אותו היום.
שרתי שורש
כפי שאמרנו לעיל, DNS הוא, בליבו, מערכת היררכית. בראש המערכת נמצאים מה שנקראים "שרתי שורש". אלה השרתים נשלטים על ידי ארגונים שונים והם מוסמכים על ידי ICANN (הרשות להקצאת שמות ומספרים באינטרנט).
יש כיום 13 שרתי שורש בפעולה. אך, מאחר שישנה מספר לא נתפס של שמות לפתירה בכל דקה, כל אחד מהשרתים הללו מרובה למעשה. הדבר המעניין במערכה זו הוא שכל אחד מהמראות של שרת שורש יחולק לו את אותו כתובת IP. כאשר בקשות מועברות לשרת שורש מסוים, הבקשה תועבר למראה הקרוב ביותר של אותו שרת שורש.
מה עושות שרתי השורשים האלו? שרתי השורשים עוסקים בבקשות למידע על דומיינים ממשקעים עליונים. אז אם נקבל בקשה עבור משהו ששרת שמות ברמה נמוכה לא יכול לפתור, נעשה שאילתה לשרת השורשים עבור הדומיין.
שרתי השורשים לא ידעו באמת איפה הדומיין מתארח. בכל זאת, הם יוכלו להפנות את הבקשן לשרתי השמות שמטפלים בדומיין עם הממשק העליון שבקש.
אז אם בקשה עבור "www.wikipedia.org" נשלחת לשרת השורשים, השרת השורשים לא ימצא את התוצאה ברשומות שלו. הוא יבדוק את קבצי האזור שלו על רישום התואם "www.wikipedia.org". הוא לא ימצא אחד.
במקום זאת, הוא ימצא רישום עבור ה-TLD "org" ויתן לישות המבקשת את כתובת השרת השמות שאחראי על כתובות "org".
שרתי TLD
הבקשן אז שולח בקשה חדשה לכתובת ה-IP (שניתן לו על ידי שרת השורשים) שאחראית על דומיין הממשק העליון של הבקשה.
לכן, כדי להמשיך את הדוגמה שלנו, הוא ישלח בקשה לשרת השמות שאחראי על הכרת דומיינים "org" כדי לראות האם הוא יודע איפה "www.wikipedia.org" ממוקם.
שוב, הבקשן יחפש את "www.wikipedia.org" בקבצי האזור שלו. הוא לא ימצא את רישום זה בקבציו.
אך תמצא רשומת רשום את כתובת ה-IP של שרת השמות אחראי עבור "wikipedia.org". זה מתקרב רבות יותר לתשובה שאנו רוצים.
שרתי שמות ברמת הדומיין
בנקודה זו, הבקשן יש לו את כתובת ה-IP של השרת שמות האחראי לידע את הכתובת האמיתית של המשאב. הוא שולח בקשה חדשה לשרת השמות ושואל, שוב, אם הוא יכול לפתור "www.wikipedia.org".
שרת השמות בודק את קבצי האזור שלו ומגלה שיש לו קובץ אזור הקשור ל-"wikipedia.org". בתוך קובץ זה, קיימת רשומה עבור המארח "www". רשומה זו מספרת את כתובת ה-IP היכן ממוקם מארח זה. שרת השמות מחזיר את התשובה הסופית לבקשן.
מהו שרת שמות מפרש?
בסצנריו הנ"ל, התייחסנו ל"בקשן". מהו הבקשן במצב זה?
ברוב המקרים, הבקשן יהיה מה שאנו קוראים "שרת שם מפתר". שרת שם מפתר הוא שרת שמוגדר לשאול שאלות משרתים אחרים. בגדר יסוד, זהו תיווך עבור משתמש המזין תוצאות שאילתות קודמות לשיפור מהירות ומכיר את כתובות השרתים הראשיים כדי להיות מסוגל ל"פתור" בקשות שנעשות עבור דברים שהוא עדיין לא מכיר.
בגדר בסיסית, משתמש רגיל יהיה לו כמה שרתי שם מפתר מוגדרים במערכת המחשב שלו. כללית, שרתי השם המפתרים מסופקים על ידי ספקי שירותי האינטרנט או על ידי ארגונים אחרים. לדוגמה, גוגל מספק שרתי DNS מפתרים שבאפשרותך לשאול שאלות. אלו יכולים להיות מוגדרים במחשב שלך באופן אוטומטי או באופן ידני.
כאשר אתה מקליד כתובת URL בסרגל הכתובות של הדפדפן שלך, המחשב שלך מחפש תחילה לראות אם הוא יכול למצוא באופן מקומי את מיקום המשאב. הוא בודק את קובץ "hosts" במחשב ומספר מקומות נוספים. לאחר מכן הוא שולח את הבקשה לשרת שם המפתר ומחכה לקבלת כתובת ה-IP של המשאב.
שרת השם המפתר אז בודק את המטמון שלו למענה. אם הוא לא מוצא אותו, הוא עובר דרך השלבים המפורטים למעלה.
שרתי שם מפתר מדחיקים בגדר בקשות לסופי המשתמש. הלקוחות פשוט צריכים לדעת לשאול את שרתי השם המפתרים איפה ממוקם משאב ולהיות בטוחים שהם יבדקו ויחזירו את התשובה הסופית.
קבצי אזור
התייחסנו בתהליך שלמעלה לרעיון של "קבצי אזור" ו"רשומות".
קבצי אזור הם הדרך שבה שרתי שמות שומרים מידע על הדומיינים שהם מכירים. כל דומיין ששרת שמות מכיר נשמר בקובץ אזור. רוב הבקשות שמגיעות לשרת שם ממוצע לא משהו שיהיה לשרת קבצי אזור עבורו.
אם הוא מוגדר לטפל בשאילתות רקורסיביות, כמו שרת שמות המפרט, הוא ימצא את התשובה ויחזיר אותה. אחרת, הוא יספק לצד המבקש את המקום הבא לחיפוש.
ככל שיש לשרת שמות יותר קבצי אזור, הוא יוכל לענות באופן מוסמך על יותר בקשות.
A zone file describes a DNS “zone”, which is basically a subset of the entire DNS naming system. It generally is used to configure just a single domain. It can contain a number of records which define where resources are for the domain in question.
משתנה האזור ($ORIGIN) של האזור הוא פרמטר השווה לרמת הרשות הגבוהה ביותר באופן ברירת מחדל.
לכן אם קובץ אזור משמש לתצורת הדומיין "example.com.", יתבצע קביעת $ORIGIN ל-example.com..
משתנה זה מוגדר בחלק העליון של קובץ האזור או ניתן להגדיר אותו בקובץ הגדרות של השרת DNS המתייחס לקובץ האזור. בכל מקרה, הפרמטר הזה מתאר את מהות האזור שבו יהיה רשאי.
באופן דומה, משתנה הזמן לחיים ($TTL) מגדיר את "הזמן לחיים" של המידע שהוא מספק. בגדר העקרונית, זהו מונה. שרת שמות זיכרון מטמון יכול להשתמש בתוצאות ששאלו בעבר כדי לענות על שאלות עד שערך ה-TTL מסתיים.
סוגי רישומים
בתוך קובץ האזור, יכולים להיות רבים סוגי רישומים שונים. נדבר על חלקם הנפוצים יותר (או סוגי הרישומים החובה) כאן.
רישומי SOA
רישום נקודת השלטון, או SOA, הוא רישום חובה בכל קובץ אזור. זה חייב להיות הרישום הראשון בקובץ (אם כי המפרטים $ORIGIN או $TTL עשויים להופיע מעל). זה גם אחד הרישומים המורכבים ביותר להבנה.
רישום נקודת השלטון נראה משהו כמו זה:
domain.com. IN SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; expiry period
1h ; negative TTL
)
בואו נסביר מהו כל חלק:
-
domain.com.: זהו שורש האזור. מציין כי הקובץ הוא עבור התחוםdomain.com.. לעתים תראה זאת מוחלף עם@, שהוא סתם מציין מקום שמחליף את תוכן משתנה ה־$ORIGINשלמדנו עליו למעלה. -
IN SOA: החלק "IN" מציין אינטרנט (ויהיה נוכח ברוב הרשומות). ה-SOA הוא האינדיקטור שזהו רשומת תחילת הרשות.
-
ns1.domain.com.: מגדיר את השרת שם הראשי עבור תחום זה. שרתי שמות יכולים להיות בסיסיים או משניים, ואם נקבע DNS דינמי אחד מהשרתים צריך להיות "בסיסי", שמתבצע כאן. אם לא הגדרתם DNS דינמי, אז זהו פשוט אחד משרתי השמות הבסיסיים שלכם. -
admin.domain.com.: זהו כתובת הדואר האלקטרוני של המנהל עבור אזור זה. ה"@" מוחלף בנקודה בכתובת הדואר האלקטרוני. אם חלק השם של כתובת הדואר האלקטרוני מכיל נקודה כלשהי בדרך כלל, זה מוחלף ב"\" בחלק זה ([email protected]מתבצע ל-your\name.domain.com). -
12083: זהו מספר הסידרה עבור קובץ האזור. בכל פעם שאתה עורך קובץ אזור, עליך להגדיל מספר זה כדי שקובץ האזור יפוצה בצורה תקינה. השרתים המשניים יבדקו האם מספר הסידרה של השרת הראשי עבור אזור נתון הוא גדול מהקובץ שיש להם במערכת שלהם. אם כן, הם יבקשו את קובץ האזור החדש, אחרת, הם ימשיכו לשרת את הקובץ המקורי.
-
3h: זהו מרווח הרענון עבור האזור. זהו כמות הזמן שהשרת המשני ימתין לפני שהוא מבצע בדיקה של השרת הראשי לשינויים בקובץ האזור.
-
30m: זהו מרווח הניסיון מחדש עבור אזור זה. אם השרת המשני לא יצליח להתחבר לשרת הראשי כאשר פרק הרענון מסתיים, הוא יחכה זמן זה וינסה שוב לפרוט את השרת הראשי.
-
3w: זהו פרק התפוגה. אם שרת השם המשני לא הצליח ליצור קשר עם השרת הראשי למשך זמן זה, הוא כבר לא יחזיר תגובות כמקור מורשה עבור אזור זה.
-
1h: זהו זמן הזנח שבו שרת השמות ישמור בידיוק תקלה אם הוא לא ימצא את השם המבוקש בקובץ זה.
A and AAAA Records
שני הרשומות האלו מטרתן למפה מארח לכתובת IP. רשומת "A" משמשת למפה מארח לכתובת IP IPv4, בעוד שרשומות "AAAA" משמשות למפה מארח לכתובת IPv6.
התבנית הכללית של הרשומות היא:
host IN A IPv4_address
host IN AAAA IPv6_address
כך שמאז רשומת ה־SOA שלנו קראה לשרת ראשי בשם "ns1.domain.com", נצטרך למפות זאת לכתובת IP מאחר ו"ns1.domain.com" נמצא בתוך האזור ""domain.com" שהקובץ הזה מגדיר.
הרשומה יכולה להיראות משהו כמו זה:
ns1 IN A 111.222.111.222
שים לב שאין לנו צורך לספק את השם המלא. אנחנו יכולים פשוט לספק את המארח, בלי ה־FQDN, והשרת DNS ימלא את השאר עם ערך ה־$ORIGIN. בכל זאת, נוכל באותו המידה להשתמש ב־FQDN המלא אם נרצה להיות סמנטיים:
ns1.domain.com. IN A 111.222.111.222
ברוב המקרים, כאן תגדירו את שרת האינטרנט שלכם כ "www":
www IN A 222.222.222.222
כדאי גם לציין לאן מקור הדומיין מפנה. ניתן לעשות זאת כך:
domain.com. IN A 222.222.222.222
היינו יכולים להשתמש ב־"@" כדי להתייחס לדומיין הבסיסי במקום:
@ IN A 222.222.222.222
יש לנו גם אפשרות לפתור כל דבר שתחתיו דומיין זה שלא מוגדר באופן ספציפי לשרת זה גם. ניתן לעשות זאת עם התו הכוכבי:
* IN A 222.222.222.222
כל אלה עובדים גם עם רשומות AAAA לכתובות IPv6.
רשומות CNAME
רשומות CNAME מגדירות כינוי עבור שם קנוני לשרת שלך (שהוגדר על ידי רשומת A או AAAA).
לדוגמה, נוכל להשתמש ברשומת שם A המגדירה את המארח "server1" ולאחר מכן להשתמש ב "www" ככינוי עבור המארח הזה:
server1 IN A 111.111.111.111
www IN CNAME server1
היזהרו כי התעודפויות אלו מתקשורת עם איבוד ביצועים מסוימים מאחר והן מחייבות שאילתת נוספת לשרת. ברוב המקרים, אפשר להשיג את אותו התוצאה על ידי שימוש ברשומות A או AAAA נוספות.
מקרה אחד שבו מומלץ להשתמש ב- CNAME הוא לספק תז עבור משאב מחוץ לאזור הנוכחי.
רשומות MX
רשומות MX משמשות להגדרת ההחלפות של הדואר שמשמשות עבור התחום. זה עוזר להודעות הדואר האלקטרוני להגיע לשרת הדואר שלך בצורה נכונה.
בניגוד לרבים מסוגי הרשומות האחרות, רשומות הדואר לרוב לא ממפות מאחסן למשהו, מאחר והן מתייחסות לאזור המלא. לכן, הן נראות כמו זו:
IN MX 10 mail.domain.com.
שימו לב שאין שם מאחסן בתחילת הרשומה.
כמו כן, שימו לב שישנה מספר נוסף שם. זהו מספר העדיפות המסייע למחשבים להחליט אילו שרת לשלוח דואר אליו במקרה שישנם מספר שרתי דואר מוגדרים. מספרים נמוכים יש להם עדיפות גבוהה.
רשומת MX כללית צריכה להפנות בדרך כלל אל מאחסן שמוגדר על ידי רשומת A או AAAA, ולא אחד שמוגדר על ידי CNAME.
אז, נניח שיש לנו שני שרתי דואר. יהיה עלינו להגדיר רשומות שנראות כך:
IN MX 10 mail1.domain.com.
IN MX 50 mail2.domain.com.
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
בדוגמה זו, מאחסן "mail1" הוא שרת ההחלפות המועדף לדואר האלקטרוני.
אפשר גם לכתוב זאת כך:
IN MX 10 mail1
IN MX 50 mail2
mail1 IN A 111.111.111.111
mail2 IN A 222.222.222.222
רשומות NS
סוג רשומה זה מגדיר את שרתי השמות שמשמשים באזור זה.
יתכן ותתעצבן, "אם קובץ האזור נמצא בשרת השמות, למה זה צריך להתייחס אל עצמו?". חלק ממה שהופך את DNS למוצלח כל כך הוא הרמות המרובות של מטמון. סיבה אחת להגדרת שרתי השמות בתוך קובץ האזור היא שקובץ האזור עשוי להישרת בעזרת עותק מטמון בשרת שמות אחר. יש סיבות אחרות לצורך בהגדרת שרתי השמות בשרת השמות עצמו, אך לא נכנס אליהן כאן.
כמו רשומות MX, אלו הם פרמטרים כלליים לאזור, ולכן הם לא מקבלים מארחים. בדרך כלל, הם נראים כך:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
עליך להגדיר לפחות שני שרתי שמות בכל קובץ אזור כדי להפעיל אותו בצורה תקינה אם יש בעיה עם שרת אחד. רוב תוכנות שרת DNS תוכנת מחשבה כי קובץ אזור הוא לא תקין אם יש רק שרת שמות יחיד.
כתמיד, כלול את המיפוי עבור המארחים עם רשומות A או AAAA:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
ns1 IN A 111.222.111.111
ns2 IN A 123.211.111.233
יש הרבה סוגי רשומות נוספים שניתן להשתמש בהם, אך אלו כנראה הם הסוגים הנפוצים ביותר שתקרא עליהם.
רשומות PTR
הרשומות PTR משמשות להגדיר שם הקשור לכתובת IP. רשומות PTR הן הפוכות של רשומת A או AAAA. רשומות PTR ייחודיות בכך שהן מתחילות בשורש .arpa ומועברות לבעלי כתובות ה-IP. רישויי האינטרנט האזוריים (RIRs) ניהלים את העברת הכתובות IP לארגונים וספקי שירותים. רישויי האינטרנט האזוריים כוללים את APNIC, ARIN, RIPE NCC, LACNIC, ו-AFRINIC.
הנה דוגמה לרשומת PTR עבור 111.222.333.444:
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
דוגמה לרשומת PTR עבור כתובת IPv6 מציגה את הפורמט בניבל של ההפוך של שרת DNS של Google, 2001:4860:4860::8888.
8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.
כלי שורת הפקודה dig עם הדגל -x ניתן לשימוש כדי לחפש את השם ההפוך של DNS של כתובת IP.
הנה דוגמה לפקודת dig. תוספת ה-+short מוסיפה כדי להפחית את הפלט לשם ההפוך של DNS.
הפלט של פקודת dig למעלה יהיה שם הדומיין ברשומת PTR עבור כתובת ה-IP:
google-public-dns-b.google.com.
שרתים באינטרנט משתמשים ברשומות PTR כדי להציב שמות דומיין ברשומות לוג, לקבל החלטות טיפול בדואר זבל מושכלות, ולהציג פרטים קלים לקריאה על מכשירים אחרים.
השרתים לשליחת דוא"ל הנפוצים ביותר יבדקו את רשומת ה-PTR של כתובת ה-IP שהם מקבלים את הדוא"ל ממנה. אם כתובת ה-IP מקורית אינה מכילה רשומת PTR המשוייכת אליה, ייתכן כי ההודעות שנשלחות תיטפלנה כדואר זבל ותוחרף. לא חשוב ששם הדומיין המלא (FQDN) ב- PTR יתאים לשם הדומיין של הדוא"ל שנשלח. החשוב הוא קיום רשומת PTR תקפה עם רשומת ה-A המתאימה והמתאימה.
רכיבי הרשת ברשת האינטרנט בדרך כלל מקבלים רשומות PTR המתאימות למיקומם הפיזי. לדוגמה, ניתן לראות הפניות ל 'NYC' או 'CHI' עבור נתב בניו יורק סיטי או בשיקגו. זה מועיל בעת ביצוע traceroute או MTR ובסקירת נתיב תנועת האינטרנט.
רוב ספקי השירותים המציעים שרתים מיועדים או שירותי VPS יאפשרו ללקוחות להגדיר רשומת PTR עבור כתובת ה-IP שלהם. DigitalOcean תשייך באופן אוטומטי את רשומת ה-PTR של כל Droplet כאשר ה-Droplet מקבל שם של שם דומיין. השם של ה-Droplet מוקצה במהלך היצירה וניתן לערוך אותו מאוחר יותר באמצעות דף ההגדרות של לוח הבקרה של ה-Droplet.
הערה: חשוב שה-FQDN ברשומת PTR יש לה רשומת A המתאימה והמתאימה. לדוגמה: 111.222.333.444 מכיל PTR של server.example.com ו-server.example.com היא רשומת A שמצביעה על 111.222.333.444.
רשומות CAA
רשומות CAA משמשות לציון אילו רשויות האישור (CAs) מורשות להנפיק אישורי SSL/TLS עבור הדומיין שלך. מזה ה-8 בספטמבר 2017 כל ה-CAs נדרשות לבדוק את הרשומות הללו לפני שהן מנפיקות אישור. אם לא נמצאת רשומה, כל CA יכולה להנפיק אישור. במקרה אחר, רק ה-CAs המסוימות יכולות להנפיק אישורים. רשומות CAA יכולות להיות מיושמות על מארחים יחידים או על דומיינים שלמים.
דוגמה לרשומת CAA מופיעה להלן:
example.com. IN CAA 0 issue "letsencrypt.org"
המארח, IN, וסוג הרשומה (CAA) הם שדות DNS רגילים. המידע הספציפי ל-CAA מעלה הוא החלק 0 issue "letsencrypt.org". הוא מורכב משלושה חלקים: דגלים (0), תגי (issue), וערכים ("letsencrypt.org").
- דגלים הם מספרים שמציינים איך צריך לטפל בתגים שלא הובנו על ידי CA. אם הדגל הוא
0, הרשומה תתעלם. אם1, ה-CA חייבת לסרב להנפיק את האישור. - תגים הם מחרוזות שמציינות את מטרת הרשומה של CAA. כרגע, יכולים להיות תגי
issueלאישור CA ליצור אישורים עבור שם מארח מסוים,issuewildלאישורים מכלליים, אוiodefלהגדרת כתובת URL שבה CAs יכולות לדווח על הפרות מדיניות. - ערכים הם מחרוזת הקשורה לתגית של הרשומה. עבור
issueו־issuewildזה כמעט תמיד יהיה הדומיין של ה־CA שאתה מעניק לו את ההרשאה. עבורiodefזה יכול להיות כתובת ה־URL של טופס יצירת קשר, או קישורmailto:למשוב בדוא"ל.
אתה יכול להשתמש ב־dig כדי לאחזר רשומות CAA באמצעות האפשרויות הבאות:
למידע מפורט נוסף על רשומות CAA, תוכל לקרוא את RFC 6844, או את המדריך שלנו איך ליצור ולנהל רשומות CAA באמצעות DNS של DigitalOcean
מסקנה
כעת אמור לך להיות בעל מושג די טוב על איך עובד DNS. למרות שהרעיון הכללי נראה נוח להבנה כאשר אתה מכיר את האסטרטגיה, זה עדיין דבר שיכול להיות קשה למנהלים לא מנוסים להפוך למעשה.
לסקירה כללית ראה איך להגדיר דומיינים בפאנל השליטה של DigitalOcean.