סקירה כללית על רשומות DNS

בדף הזה מופיעה סקירה כללית של רשומות ורשימה של סוגי רשומות DNS שנתמכים ב-Cloud DNS, כולל סוג הרשומה המותאמת אישית ALIAS של Cloud DNS.

רשומה היא מיפוי בין משאב DNS לבין שם דומיין. לכל רשומת DNS יש סוג (שם ומספר), זמן תפוגה (זמן חיים) ונתונים ספציפיים לסוג.

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

רשומות של כתובות אימייל חלופיות

רשומת ALIAS היא סוג של רשומה בהתאמה אישית ב-Cloud DNS שפועלת כמו רשומת CNAME, אבל אפשר להשתמש בה רק ב-zone apex והיא מגיבה רק לשאילתות של רשומות כתובת (A או AAAA). באופן ספציפי, סוג הרשומה ALIAS ממפה שם דומיין חלופי לשם קנוני, ומשתמש בשם הקנוני כדי לחפש את התשובה. סוג הרשומה הזה שימושי כשצריך התנהגות של CNAME ב-apex. אי אפשר להוסיף רשומת CNAME ב-apex כי היא לא יכולה להתקיים לצד סוג אחר של רשומה, כולל רשומת ה-SOA שנדרשת ב-apex של האזור.

רשומות ALIAS הן ספציפיות ל-Cloud DNS, והן אף פעם לא נחשפות ללקוח חיצוני ששולח שאילתות לתחומי DNS ב-Cloud DNS. מבחינת הלקוח, רשומת ALIAS מופיעה כרשומת A או AAAA רגילה בתגובת ה-DNS. רשומות ALIAS לא תואמות ל-DNSSEC, ולכן אי אפשר להפעיל את DNSSEC באזור עם רשומות ALIAS.

אתם יכולים לנהל רשומות ALIAS כמו כל רשומה אחרת. במאמר ניהול רשומות מוסבר איך לנהל רשומות.

תהליך הטיפול בשאילתות

רשומות חלופיות זמינות רק לאזורים ציבוריים ב-Cloud DNS.

ברשומות CNAME, המפענח אחראי לפענוח השם הקנוני. ברשומות ALIAS, שרת השמות של Cloud DNS פותר את השם הקנוני ומפיק רשומות A או AAAA מסונתזות כדי להחזיר אותן למפענח. רשומות ה-A או ה-AAAA המסונתזות מכילות את השם של רשומת ה-ALIAS עם כתובות ה-IP שנמצאו כתוצאה מהפירוש של יעד רשומת ה-ALIAS. שרתי השמות של Cloud DNS משתמשים במפענחים הרקורסיביים הזמינים של Google כדי לפענח רשומות של כינויים.

אם יעד ה-alias מפנה לקבוצת רשומות משאבים (RRSet) עם כמה כתובות, Cloud DNS מחזיר את כל הרשומות אבל משנה את הסדר שלהן באופן אקראי לפני שהוא מחזיר את רשומת הכתובת המסונתזת. התהליך הזה דומה לאופן שבו Cloud DNS מטפל בתשובות משרתי השמות שלו.

רק רשומות של כתובות מסונתזות במהלך פתרון היעד של רשומת ALIAS. שאילתות של רשומות ALIAS לא מחזירות רשומות CNAME מתווכות שנמצאות בזמן פתרון היעד של רשומת ה-alias. רשומות CNAME שנמצאות באמצעות מעקב CNAME לפני שמגיעים לרשומת ALIAS מוחזרות ללא שינוי. אם הרזולוציה של יעד ה-ALIAS נכשלת, כלומר מוחזר קוד תגובה שהוא לא NOERROR, שרת השמות של Cloud DNS מחזיר ללקוח שלו תגובה מסוג SERVFAIL. אם הרזולוציה מחזירה תגובה מסוג NODATA, שהיא תגובה מסוג NOERROR ללא רשומות של כתובות, שרת השמות של Cloud DNS מחזיר תגובה מסוג NODATA.

כשמפענחים יעדים של רשומות ALIAS, ‏ Cloud DNS לא משתמש ב-EDNS Client Subnet שהלקוח סיפק.

פרמטר אורך חיים (TTL) ושמירה במטמון

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

בדוגמה הבאה מוסבר איך נקבע ה-TTL לרשומות הכתובות המסונתזות.

נניח שהרשומות הבאות מוגדרות באזור מנוהל של Cloud DNS:

example.com.    3600    SOA      ns.com.  admin.example.com. (...)
                86400   NS       ns.com.
                6000    ALIAS    test-cname.example.com.
test-cname      3000    CNAME    address.example.com.
address         5000    A        1.2.3.4

שאילתה לאזור הזה עבור רשומת A ב-example.com מחזירה תשובה שדומה לזו:

QUESTION SECTION
example.com.                  A

ANSWER SECTION
example.com.        3000      A      1.2.3.4

ערכי ה-TTL שמתקבלים במהלך התרגום הם 6,000 (לרשומת ALIAS),‏ 3,000 (לרשומת CNAME) ו-5,000 (לרשומת A). מבין ערכי ה-TTL האלה, 3,000 הוא הקטן ביותר, ולכן הוא מוחזר ברשומת הכתובת המסונתזת.

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

Authoritative answer bit

הביט המוסמך בתגובת ה-DNS מבוסס על השם הראשון בשרשרת (ה-qname המקורי), בלי קשר לשאלה אם הנתונים שמשויכים לשם הזה נמצאים בשרת או אוחזרו באמצעות רזולוציה של רשומת ALIAS.

טיפול בשגיאות

כדי לפתור רשומות ALIAS, ‏Cloud DNS משתמש בשרתי שמות מוסמכים של צד שלישי כדי לקבוע הקצאות DNS ולאחזר נתוני DNS שמתארחים באופן חיצוני. אם Cloud DNS לא יכול לפתור יעד של רשומת ALIAS (תוצאות הפתרון של יעד ALIAS גורמות לערך שגיאה RCODE, כמו NXDOMAIN או REFUSED), הוא מחזיר תגובת SERVFAIL. לדוגמה, אם היעד ALIAS לא קיים או שאי אפשר להגיע לשרתים המוסמכים שלו, Cloud DNS מחזיר את הערך SERVFAIL.

מכיוון ש-SERVFAIL מספק מידע מוגבל על השגיאה, רישום ביומן של Cloud DNS כולל את הערך הספציפי של RCODE שנתקלו בו במהלך פתרון הרשומה של ALIAS, כדי לעזור לכם לפתור שגיאות. איך משתמשים ברישום ביומן ובמעקב ב-Cloud DNS

אם רזולוציית יעד של ALIAS גורמת לתגובה של NODATA (תגובה ריקה עם NOERROR RCODE), אז Cloud DNS מחזיר NODATA. ALIAS רשומות תואמות גם לשאילתות A וגם לשאילתות AAAA, אבל היעד ALIAS יכול להכיל רק סוג רשומה אחד. זו התנהגות צפויה, והיא לא גורמת לתגובה עם ערך שגיאה RCODE.

ייבוא וייצוא של רשומות

אתם יכולים לייבא ולייצא רשומות מקובץ לתיאור תחום DNS של BIND או מקובץ YAML, ואליהם.

רשומות ALIAS לא נתמכות בקובצי BIND כי סוג הרשומה ALIAS הוא לא סוג רגיל של רשומת DNS. ‫Cloud DNS מזהה את הרשומות האלה, אבל יכול להיות שתוכנות DNS אחרות שתואמות ל-BIND לא יזהו אותן.

רשומות ALIAS מיוצאות לקובצי YAML, ספציפיים ל-Cloud DNS, בפורמט הבא:

kind: dns#resourceRecordSet
name: DNS Name
rrdatas: RR Data
ttl: TTL
type: ALIAS

אפשר לייבא ל-Cloud DNS רשומות ALIAS מקובץ YAML בפורמט שלמעלה.

אבטחה ופרטיות

שרתי שמות ציבוריים של Cloud DNS פותרים את יעד ה-ALIAS בשבילכם, אבל אתם צריכים לוודא שהגדרתם את יעד ה-ALIAS בצורה נכונה. יעד ALIAS שגוי עלול לגרום לכך שהרשומות הציבוריות לא יפעלו כמו שצריך או יחזירו כתובות IP לא רצויות.

מעקב אחרי אזורים מנוהלים

ב-Cloud DNS אפשר לתעד ביומן את כל השאילתות לאזורים מנוהלים באמצעות Logging. שדה אופציונלי alias_query_response_code זמין ביומן שאילתות ה-DNS כדי לתעד מידע על הסטטוס של תרגום השם של ALIAS, כי המידע הזה לא זמין בתגובת ה-DNS.

לפרטים נוספים, ראו צפייה ביומנים.

השדה alias_query_response_code מוגדר רק אם השאילתה נפתרת באמצעות רשומת ALIAS. הערך NoError מציין שרשומת ה-ALIAS נפתרה בהצלחה, וכל ערך אחר מייצג את השגיאה. הערך SERVFAIL יכול לייצג כל אחת מהבעיות הבאות:

  • שרת השמות של היעד לא נגיש
  • הזמן הקצוב לפתרון היעד הסתיים לפני שנמצאה תשובה
  • אימות ה-DNSSEC נכשל

בשדה qtype ברשומות ביומן אין אפשרות ALIAS. אם שאילתת A או AAAA נענית באמצעות רשומת ALIAS, השדה qtype נשאר A או AAAA.

סוגי רשומות DNS נתמכים

‫Cloud DNS תומך בסוגי הרשומות הבאים.

סוג הרשומה Enter
A

כתובת ה-IP המספרית של המארח, בפורמט עשרוני עם נקודות של IPv4. סוג הרשומה A ממפה כתובת IPv4 לשם דומיין וקובע לאן הבקשות לשם הדומיין מופנות, למשל 192.0.2.91.

AAAA

כתובת ה-IP המספרית של המארח, בפורמט הקסדצימלי של IPv6. סוג הרשומה AAAA (quad A) ממפה כתובת IPv6 לשם דומיין וקובע לאן מופנות הבקשות לשם הדומיין, לדוגמה 2001:db8::8bd:1002.

ALIAS (גרסת טרום-השקה (Preview))

רשומת Alias (גרסת טרום-השקה (Preview)), שממפה שם דומיין חלופי לשם קנוני בראש האזור. רשומת כינוי נקראת גם רשומת ANAME או CNAME flattening.

אפשר להגדיר רשומות חלופיות באמצעות ה-CLI של gcloud או Cloud DNS API. אי אפשר להגדיר רשומות חלופיות באמצעות מסוף Google Cloud .

רשומת כינוי נקראת גם רשומת ANAME או שיטוח CNAME.

CAA

רשויות האישורים שמורשות להנפיק אישורים לדומיין הזה, לדוגמה, ca.example.net.

כדי לוודא שרשויות אישורים לא מורשות לא מנפיקות אישורים לדומיין שלך, צריך ליצור סוג רשומה של CAA.

CNAME

כינוי ה-DNS של רשומת A – לדוגמה, ftp.example.com הוא כינוי DNS של www.example.com. בדוגמה הזו, ftp.example.com הוא שירות שקיים באותו שרת כמו www.example.com. קישורים שמפנים אל ftp.example.com מקבלים את רשומת ה-A של www.example.com.

אפשר גם להשתמש בסוג הרשומה CNAME כדי להפנות לשם דומיין אחר לגמרי. לדוגמה, altostrat.com הוא כינוי DNS של www.example.com.

לפעמים, שרת שמות מגיב עם רשומת CNAME ורשומת A שאליה מפנה הערך של ה-CNAME. ההתנהגות הזו נקראת CNAME chasing.

אם נתקלתם בבעיות ביצירת רשומת CNAME, קראו את המאמר רשומת CNAME שמוגדרת באזור פרטי לא פועלת .

DNSKEY

המפתח הציבורי של DNSSEC שבו משתמשים המפענחים כדי לאמת את האותנטיות של הרשומות באמצעות מפתחות ZSK ו-KSK.

לדוגמה, 7200 IN DNSKEY 256 3 8 AwEAAarQO0FTE/l6LEKFlZllJIwXuLGd3q5d8S8NH+ntOeIMN81A5wAI.

בדוגמה הזו, 7200 הוא ה-TTL,‏ 256 הוא הייצוג העשרוני של הדגלים DNSKEY,‏ 3 הוא מחוון הפרוטוקול של DNSSEC, ו-8 הוא האלגוריתם הקריפטוגרפי RSA/SHA-256 שמשמש למפתח.

אפשר להוסיף את סוג הרשומה הזה רק באזור ציבורי שמופעלים בו תוספי DNSSEC, שנמצא במצב Transfer. מידע נוסף זמין במאמר ניהול ההגדרות של DNSSEC.

DS

טביעת האצבע של מפתח DNSSEC לאזור מאובטח שהוקצה.

לדוגמה, 7200 IN DS 31523 5 1 c8761ba5defc26ac7b78e076d7c47fa9f86b9fba. בדוגמה הזו, 7200 הוא ה-TTL,‏ 31523 הוא תג המפתח, 5 הוא האלגוריתם ו-1 הוא סוג התקציר.

אפשר להוסיף את סוג הרשומה הזה רק באזור ציבורי. סוג הרשומה הזה לא מפעיל את DNSSEC לאזור שהוקצה, אלא אם מפעילים את DNSSEC לאזור הזה. תוספי DNSSEC לא מופעלים כברירת מחדל באזורים.

HTTPS

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

לדוגמה, 1 . alpn=h2, h3 כאשר 1 הוא עדיפות השירות (SvcPriority) שהיא 0 עבור כינויים ו- 1-65535 עבור תיאורי שירות, . הוא TargetName ("." אם הוא זהה לשם הבעלים), ו-alpn=h2, h3 הם הפרמטרים של השירות (SvcParams) המורכבים מזוגות מפתח/ערך המתארים את נקודת הקצה של היעד, מופרדים ברווחים.

סוג הרשומה HTTPS מבוסס על סוג הרשומה הכללי יותר SVCB, ומשתמש באותו פורמט ערך.

IPSECKEY

נתוני שער של מנהרת IPsec ומפתחות ציבוריים ללקוחות שתומכים ב-IPsec כדי להפעיל הצפנה אופורטוניסטית.

לדוגמה, 10 1 2 192.0.2.1 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt==, כאשר 10 הוא הקדימות, עם ערכים נמוכים יותר בעלי עדיפות גבוהה יותר, 1 הוא סוג השער, 2 הוא סוג האלגוריתם ו-192.0.2.1 הוא השער.

מידע נוסף זמין ב-RFC 4025.

MX

מספר עדיפות ושם DNS של שרת דואר שמקבל אימיילים בשם הדומיין שלכם.

לדוגמה: 1 mail.example.com., כאשר 1 הוא מספר ההעדפה.

שרתי SMTP מעדיפים שרתים עם מספרי עדיפות נמוכים יותר, כאשר 0 הוא מספר העדיפות הנמוך ביותר שאפשר להזין.

רשומת ה-MX שמזינים חייבת להסתיים בנקודה (.).

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

לדוגמה, כדי להפנות את האימייל לחשבון Google Workspace, צריך להזין את הפרטים הבאים: 1 SMTP.GOOGLE.COM.

NAPTR

כללי ההצבעה של רשות השמות שמשמשים למיפוי שמות משאבים אחידים (URN) על ידי אפליקציות של מערכת Dynamic Delegation Discovery System‏ (DDDS). סוג הרשומה NAPTR משמש אפליקציות DDDS להמרה או להחלפה של ערך אחד בערך אחר כדי למצוא URN.

בדוגמה, 100 10 "u" "sip+E2U" "!^.*$!sip:information@example.com!i ." 100 הוא הסדר שבו צריך לעבד את רשומות ה-NAPTR,‏ 10 הוא ההעדפה שמציינת את סדר העיבוד כשלרשומות יש ערכי סדר זהים, "u" הוא דגל ששולט בהיבטים של השכתוב והפירוש של השדות ברשומה, ""sip+E2U הם שירותים, ו-"!^.*$!sip:information@example.com!i" הוא הביטוי הרגולרי (RegEx) שמכיל ביטוי חלופי שמוחל על המחרוזת המקורית שמוחזקת על ידי הלקוח כדי ליצור את החיפוש הבא של הדומיין. לבסוף, הערך . הוא ההחלפה, שהיא שם הדומיין הבא שצריך לשלוח לו שאילתה בהתאם לערכים הפוטנציאליים שנמצאו בשדה הדגלים.

מידע נוסף זמין ב-RFC 3403.

NS

שם ה-DNS של שרת השמות המוסמך שמספק שירותי DNS לדומיין או לתת-הדומיין. רשומות ה-NS צריכות להתאים לשרתי השמות של האזור, למשל ns-1.example.com.

PTR

שם הדומיין שמוגדר במלואו (FQDN) או השם הקנוני של הדומיין שממופה לכתובת IP, לדוגמה server-1.example.com.

סוג הרשומה PTR משמש בדרך כלל לחיפושים הפוכים.

SOA

רשומת Start of Authority, שמציינת מידע מהימן על תחום DNS. רשומת SOA נוצרת בשבילכם כשאתם יוצרים את האזור המנוהל. אפשר לשנות את הרשומה לפי הצורך (לדוגמה, אפשר לשנות את המספר הסידורי למספר שרירותי כדי לתמוך בניהול גרסאות לפי תאריך).

לדוגמה, ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com 1 21600 3600 259200 300 כאשר ns-cloud-c1.googledomains.com. הוא ה-MNAME, cloud-dns-hostmaster.google.com הוא ה-RNAME, 1 הוא ה-SERIAL,‏ 21600 הוא ה-REFRESH, 3600 הוא ה-RETRY,‏ 259200 הוא ה-EXPIRE, ו- 300 הוא ה-MINIMUM.

מידע נוסף זמין במאמר RFC 1035.

SPF

סוג הרשומה SPF הוצא משימוש. במקום זאת, צריך להשתמש ברשומות TXT שמתחילות ב-v=spf1. רשומות מסוג SPF לא נמצאות בשימוש בתוכנות אימייל מודרניות.

SRV

הנתונים שמציינים את המיקום (שם המארח ומספר היציאה) של שרתים בשירות מסוים.

לדוגמה, 0 1 587 mail.example.com כאשר 0 הוא העדיפות של המארח המטורגט, 1 הוא המשקל ו-587 הוא מספר היציאה.

מידע נוסף זמין במאמר RFC 2782.

SSHFP

טביעת אצבע של SSH ללקוחות SSH כדי לאמת את המפתחות הציבוריים של שרתי SSH.

לדוגמה, 2 1 123456789abcdef67890123456789abcdef67890 כאשר 2 הוא מספר האלגוריתם של שרת ה-SSH,‏ 1 הוא מספר סוג טביעת האצבע, ו- 123456789abcdef67890123456789abcdef67890 הוא טביעת האצבע.

SVCB

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

לדוגמה, 0 alias-target.example.com כאשר 0 הוא עדיפות השירות (SvcPriority) שהיא 0 עבור כינויים ו-1-65535 עבור תיאורי שירות.

למקורות HTTPS, אפשר לעיין בסוג הרשומה של HTTPS.

TLSA

פרטי שיוך האישורים של DNS-based Authentication of Named Entities (DANE) TLSA.

רשומת TLSA מכילה מידע שמשמש לאימות אישורי X.509 (כמו אישורים שמשמשים את HTTPS) בלי להסתמך על אחת מרשויות האישורים (CA) שהוגדרו מראש וחתמו עליהם.

לדוגמה, 1 1 2 92003ba34942dc74152e2f2c408d29ec. בדוגמה הזו, הערך הראשון 1 הוא מזהה הפרוטוקול של DNSSEC, הערך השני 1 הוא המפתח הציבורי, והערך 2 הוא האלגוריתם הקריפטוגרפי RSA/SHA-256 שמשמש למפתח.

השתמשו בסוג הרשומה הזה רק אם הפעלתם את DNSSEC באזור.

TXT

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

רשומת TXT יכולה להכיל מחרוזת טקסט אחת או יותר. האורך המקסימלי של כל מחרוזת הוא 255 תווים. אם נתוני הרשומה גדולים מ-255 בייטים, צריך לחלק את הרשומה למחרוזות של 255 בייטים ולתחום כל מחרוזת במירכאות, לדוגמה: "String one 255 bytes" "String two 255 bytes".

סוכני דואר וסוכני תוכנה אחרים משרשרים כמה מחרוזות.

תוחמים כל מחרוזת במירכאות, לדוגמה, "Hello world" "Bye world".

בכל רשומת TXT יש מגבלת תווים של 1,000. אם אתם צריכים להגדיל את המגבלה הזו, פנו Google Cloud לתמיכה.

המאמרים הבאים