📘 תיעוד 47

סוגי רשומות DNS

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

הערה

לכל רשומת DNS יש גודל מרבי בפורמט wire של 4,096 בתים. פורמט wire מתייחס לאופן שבו רשומה מקודדת כשהיא מועברת בפרוטוקול DNS (RFC 1035 ↗︎).

אם יש לכם כמה רשומות עם אותו שם ואותו סוג, האורך המשולב של התוכן שלהן לא יכול לעלות על 8,192 תווים.

#פתרון כתובות IP

לפחות רשומת פתרון כתובת IP אחת נדרשת לכל דומיין ב-Cloudflare. אלה הרשומות היחידות שאפשר לנתב דרך פרוקסי של Cloudflare.

#A ו-AAAA

רשומות A ו-AAAA ↗︎ ממפות שם דומיין לכתובת IPv4 אחת או יותר, או לכתובת IPv6 אחת או יותר.

הרשומות האלה כוללות את השדות הבאים:

• Name: תת-דומיין או קודקוד האזור (@).

  • השם חייב להיות מורכב מתוויות של 63 תווים או פחות (label1.label2.label3), כאשר השם המלא של הדומיין (label1.label2.label3.example.com) אינו עולה על 253 תווים.
  • תוויות DNS יכולות להכיל כל אוקטט (ערך בית). עם זאת, לצורך תאימות לשמות מארח ולאישורי TLS, מומלץ להשתמש רק באותיות, ספרות ומקפים (כלל LDH). זו אינה דרישה של פרוטוקול DNS, כלומר DNS יעבוד גם אם לא תעקבו אחרי המוסכמות האלה.
  • אין דרישה להתחיל באות או לסיים באות או בספרה.
  • קווים תחתונים תקינים ב-DNS ונפוצים ברשומות שירות.

• IPv4/IPv6 address: כתובת שרת המקור שלכם (לא יכולה להיות כתובת IP של Cloudflare ↗︎)

הערה

Cloudflare משתמשת בסימון הקנוני ↗︎ כדי לאחסן רשומות DNS. המשמעות היא שרשומת AAAA עם תוכן fe80::0:0:1 נשמרת ומוחזרת כ-fe80::1, לדוגמה.

סימונים חלופיים של כתובות IPv4 (1.1 עבור 1.0.0.1, לדוגמה) אינם נתמכים ברשומות A.

• TTL: זמן חיים (Time to live), שקובע כמה זמן פותרי DNS צריכים לשמור תשובה במטמון לפני אימות מחדש.
  • אם Proxy Status הוא Proxied, ערך זה מוגדר כברירת מחדל ל-Auto, שהיא 300 שניות.
  • אם Proxy Status הוא DNS Only, אפשר להתאים את הערך.
• Proxy status: לפרטים נוספים, עיינו ברשומות DNS עם פרוקסי.
• Private network routing: לחלק מלקוחות Enterprise יש גם גישה לניתוב רשת פרטית. עבור רשומות A ו-AAAA, התכונה הזו מאפשרת לנתב תעבורת HTTP/HTTPS משמות מארח ציבוריים דרך פרוקסי אל מקורות ברשת הפרטית שלכם.

#דוגמה לקריאת API

בעת יצירת רשומות A או AAAA באמצעות ה-API:

• ה-content של הרשומות הוא כתובת IP (IPv4 עבור A או IPv6 עבור AAAA).
• השדה proxied משפיע על מצב הפרוקסי של הרשומה.

להגדרות שדות, עיינו בתיעוד ה-API (גלוי לאחר בחירת סוג הרשומה תחת מפרט גוף הבקשה).

יצירת רשומת DNS bash

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"type": "A",
		"name": "www.example.com",
		"content": "192.0.2.1",
		"ttl": 3600,
		"proxied": false
	}'

תשובה json

{
	"result": {
		"id": "<ID>",
		"zone_id": "<ZONE_ID>",
		"zone_name": "example.com",
		"name": "www.example.com",
		"type": "A",
		"content": "192.0.2.1",
		"proxiable": true,
		"proxied": false,
		"ttl": 1,
		"locked": false,
		"meta": {
			"source": "primary"
		},
		"comment": null,
		"tags": [],
		"created_on": "2023-01-17T20:37:05.368097Z",
		"modified_on": "2023-01-17T20:37:05.368097Z"
	},
	"success": true,
	"errors": [],
	"messages": []
}

#CNAME

רשומות CNAME ↗︎ ממפות שם דומיין לשם דומיין אחר (קנוני). אפשר להשתמש בהן כדי לפענח סוגי רשומות אחרים שנמצאים בשם הדומיין היעד.

הרשומות האלה כוללות את השדות הבאים:

• Name: תת-דומיין או קודקוד האזור (@).

  • השם חייב להיות מורכב מתוויות של 63 תווים או פחות (label1.label2.label3), כאשר השם המלא של הדומיין (label1.label2.label3.example.com) אינו עולה על 253 תווים.
  • תוויות DNS יכולות להכיל כל אוקטט (ערך בית). עם זאת, לצורך תאימות לשמות מארח ולאישורי TLS, מומלץ להשתמש רק באותיות, ספרות ומקפים (כלל LDH). זו אינה דרישה של פרוטוקול DNS, כלומר DNS יעבוד גם אם לא תעקבו אחרי המוסכמות האלה.
  • אין דרישה להתחיל באות או לסיים באות או בספרה.
  • קווים תחתונים תקינים ב-DNS ונפוצים ברשומות שירות.

• Target: שם המארח שאליו יש לכוון את התעבורה (example.com).

• TTL: זמן חיים (Time to live), שקובע כמה זמן פותרי DNS צריכים לשמור תשובה במטמון לפני אימות מחדש.

  • אם Proxy Status הוא Proxied, ערך זה מוגדר כברירת מחדל ל-Auto, שהיא 300 שניות.
  • אם Proxy Status הוא DNS Only, אפשר להתאים את הערך.

• Proxy status: לפרטים נוספים, עיינו ברשומות DNS עם פרוקסי.

#רשומות CNAME עם פרוקסי

שימו לב להיבטים הבאים, במיוחד לפני שינוי רשומת CNAME ממצב proxied למצב DNS-only או להפך:

• אם שם מארח מיועד לניתוב תעבורה דרך פרוקסי, אפשר להשתמש ברשומות CNAME כדי להצביע על רשומות CNAME אחרות (www.example2.com --> www.example1.com --> www.example.com), אבל הרשומה הסופית חייבת להצביע על שם מארח עם כתובת IP תקינה (ולכן רשומת A או AAAA תקינה). בנוסף, שאילתות לסוגי רשומות אחרים על אותו שם אינן נתמכות.

• Cloudflare משתמשת בתהליך שנקרא השטחת CNAME (CNAME flattening) כדי לספק ביצועים טובים יותר. התהליך הזה תומך בכמה תכונות ויכול לקיים אינטראקציה עם הגדרות שונות שתלויות ברשומות CNAME. עיינו במקטע השטחת CNAME כדי ללמוד עוד על כך.
• אם נתקלתם ברשומת CNAME שאי אפשר לנתב דרך פרוקסי, בדרך כלל בהקשר של ספק CDN אחר, גרסה עם פרוקסי של הרשומה הזו תגרום לשגיאות קישוריות. Cloudflare מונעת במכוון ניתוב של הרשומה הזו דרך פרוקסי כדי להגן עליכם מהגדרה שגויה. עיינו במגבלות פרוקסי לפרטים.

הערה

ערכים מסוימים של רשומות CNAME, כשהתעבורה מנותבת דרך פרוקסי של Cloudflare, יפעילו ניתוב O2O עבור ספק ה-SaaS Shopify. עיינו במדריך ספק Shopify למידע נוסף.

#דוגמה לקריאת API

בעת יצירת רשומות CNAME באמצעות ה-API:

• ה-content של הרשומות הוא שם דומיין מלא ↗︎.
• השדה proxied משפיע על מצב הפרוקסי של הרשומה.

להגדרות שדות, עיינו בתיעוד ה-API (גלוי לאחר בחירת סוג הרשומה תחת מפרט גוף הבקשה).

יצירת רשומת DNS bash

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"type": "CNAME",
		"name": "www.example.com",
		"content": "www.another-example.com",
		"ttl": 3600,
		"proxied": false
	}'

תשובה json

{
	"result": {
		"id": "<ID>",
		"zone_id": "<ZONE_ID>",
		"zone_name": "example.com",
		"name": "www.example.com",
		"type": "CNAME",
		"content": "www.another-example.com",
		"proxiable": true,
		"proxied": false,
		"ttl": 1,
		"locked": false,
		"meta": {
			"source": "primary"
		},
		"comment": null,
		"tags": [],
		"created_on": "2023-01-17T20:37:05.368097Z",
		"modified_on": "2023-01-17T20:37:05.368097Z"
	},
	"success": true,
	"errors": [],
	"messages": []
}

#אימות דוא"ל

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

אם הדומיין שלכם לא משמש לשליחת הודעות דוא"ל, למדו עוד על יצירת רשומות מגבילות ↗︎ מומלצות.

#MX

רשומת mail exchange (MX) נדרשת כדי למסור דוא"ל לשרת דואר.

• תחביר רשומת MX ↗︎
• יצירת רשומת MX

להגדרות שדות, עיינו בתיעוד ה-API (גלוי לאחר בחירת סוג הרשומה תחת מפרט גוף הבקשה).

#DKIM

רשומת DomainKeys Identified Mail (DKIM) מבטיחה את האותנטיות של הדוא"ל באמצעות חתימה קריפטוגרפית על הודעות דוא"ל:

• תחביר רשומת DKIM ↗︎
• יצירת רשומת DKIM

#SPF

רשומת Sender Policy Framework (SPF) מפרטת כתובות IP ודומיינים מורשים שיכולים לשלוח דוא"ל בשם הדומיין שלכם.

• תחביר רשומת SPF ↗︎
• יצירת רשומת SPF

#DMARC

רשומת Domain-based Message Authentication Reporting and Conformance (DMARC) עוזרת להפיק דוחות מצטברים על תעבורת הדוא"ל שלכם ולספק הוראות ברורות לאופן שבו מקבלי דוא"ל צריכים לטפל בהודעות דוא"ל שאינן תואמות.

• תחביר רשומת DMARC ↗︎
• יצירת רשומת DMARC

#רשומות מתמחות

#TXT

רשומת טקסט (TXT) מאפשרת להזין טקסט למערכת ה-DNS.

מכיוון שתוכן רשומות TXT מורכב ממחרוזת טקסט אחת או יותר שמופרדות במרכאות כפולות ("), ייתכן שתופיע שגיאת אימות אם מוסיפים מרכאות לא עקביות (לדוגמה, "this או "these" ones"). ברשומות חדשות, אם שומרים את תוכן ה-TXT בלי מרכאות, Cloudflare תוסיף מרכאות כפולות באופן אוטומטי. לפרטים, ראו מהי רשומת DNS TXT.

ב-Cloudflare, רשומות TXT משמשות לרוב כדי להוכיח בעלות על דומיין לפני הנפקת אישורי SSL/TLS עבור הדומיין שלכם או עבור דומיין Cloudflare for SaaS.

אפשר גם להשתמש ב-TXT כדי ליצור רשומות אימות אימייל, אבל אנחנו ממליצים להשתמש ב-אשף Email security במקום זאת.

להגדרות השדות, ראו את תיעוד ה-API (גלוי לאחר שבוחרים את סוג הרשומה תחת מפרט גוף הבקשה).

#CAA

רשומת Certificate Authority Authorization ‏(CAA) מציינת אילו רשויות אישורים (CAs) מורשות להנפיק אישורים לדומיין.

להגדרות השדות, ראו את תיעוד ה-API (גלוי לאחר שבוחרים את סוג הרשומה תחת מפרט גוף הבקשה).

#SRV

רשומת שירות (SRV) מציינת מארח ויציאה לשירותים מסוימים כמו קול על IP ‏(VOIP), מסרים מיידיים ועוד.

#קריאת API לדוגמה

להגדרות השדות, ראו את תיעוד ה-API (גלוי לאחר שבוחרים את סוג הרשומה תחת מפרט גוף הבקשה).

הרשאות נדרשות לאסימון API

נדרשת לפחות אחת מהרשאות האסימון הבאות:

• DNS Write

יצירת רשומת DNS

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"type": "SRV",
		"name": "_xmpp._tcp.example.com",
		"data": {
				"priority": 10,
				"weight": 5,
				"port": 5223,
				"target": "server.example.com"
		}
	}'

תגובה

{
	"result": {
		"id": "<ID>",
		"zone_id": "<ZONE_ID>",
		"zone_name": "example.com",
		"name": "_xmpp._tcp.example.com",
		"type": "SRV",
		"content": "5 5223 server.example.com",
		"priority": 10,
		"proxiable": false,
		"proxied": false,
		"ttl": 1,
		"locked": false,
		"data": {
			"port": 5223,
			"priority": 10,
			"target": "server.example.com",
			"weight": 5
		},
		"meta": {
			"auto_added": false,
			"managed_by_apps": false,
			"managed_by_argo_tunnel": false,
			"source": "primary"
		},
		"comment": null,
		"tags": [],
		"created_on": "2022-11-08T15:57:39.585977Z",
		"modified_on": "2022-11-08T15:57:39.585977Z"
	},
	"success": true,
	"errors": [],
	"messages": []
}

#SVCB ו-HTTPS

רשומות Service Binding ‏(SVCB) ו-HTTPS Service ‏(HTTPS) מאפשרות לספק ללקוח מראש מידע על האופן שבו עליו להתחבר לשרת, בלי צורך בחיבור HTTP ראשוני בטקסט גלוי.

אם לדומיין שלכם מופעלים HTTP/2 או HTTP/3, יש רשומות DNS עם פרוקסי, והוא גם משתמש ב-Universal SSL, Cloudflare מייצרת אוטומטית רשומות HTTPS תוך כדי, כדי לפרסם ללקוחות איך עליהם להתחבר לשרת.

#שמות עם פרוקסי לעומת שמות DNS בלבד

לשמות עם פרוקסי (ענן כתום), Cloudflare מרכיבה רשומות HTTPS באופן אוטומטי כאשר Universal SSL מופעל. רשומות HTTPS שנוספו ידנית על שמות עם פרוקסי לא מוגשות. Cloudflare משתמשת ברשומות שנוצרות אוטומטית.

אם השבתתם את Universal SSL (לדוגמה, כי אתם משתמשים ב-Advanced Certificates בלבד), Cloudflare לא תייצר רשומות HTTPS לשמות עם פרוקסי. Cloudflare מפרסמת רשומת HTTPS רק לשמות שידוע שיש להם אישור פעיל. פרסום HTTPS לשם בלי אישור יגרום לחיבורים להיכשל.

אם Universal SSL כבוי, Cloudflare לא מייצרת רשומות HTTPS לשמות עם פרוקסי גם אם יש לכם אישור מותאם או Advanced Certificate פעיל. כדי להחזיר את יצירת רשומות ה-HTTPS, הפעילו מחדש את Universal SSL. האישור המותאם או Advanced Certificate עדיין יקבל עדיפות עליו לחיבורים, כמתואר ב-עדיפות אישור ושם מארח. אם צריך להשאיר את Universal SSL כבוי, פנו לתמיכה של Cloudflare.

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

דוגמה: רשומות HTTPS ידניות ומצב פרוקסי

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

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

רשומת ה-HTTPS תוגש כי רשומת ה-A היא DNS בלבד.

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

רשומת ה-HTTPS לא תוגש כי רשומת ה-AAAA עם אותו שם היא עם פרוקסי.

לפרטים ולהקשר נוספים, ראו את פוסט ההכרזה בבלוג ואת RFC 9460.

להגדרות השדות, ראו את תיעוד ה-API (גלוי לאחר שבוחרים את סוג הרשומה תחת מפרט גוף הבקשה).

#PTR

רשומת מצביע (PTR) מציינת את המארחים המורשים לכתובת IP נתונה.

בתוך Cloudflare, רשומות PTR משמשות לחיפושי DNS הפוכים, ועדיף להוסיף אותן ל-אזורים הפוכים.

להגדרות השדות, ראו את תיעוד ה-API (גלוי לאחר שבוחרים את סוג הרשומה תחת מפרט גוף הבקשה).

#SOA

רשומת start of authority ‏(SOA) שומרת מידע על הדומיין, כגון כתובת האימייל של המנהל, מתי הדומיין עודכן לאחרונה ועוד. ראו מהי רשומת DNS SOA לדוגמה.

אם אתם משתמשים ב-Cloudflare עבור ה-DNS הסמכותי שלכם, אין צורך ליצור רשומת SOA. Cloudflare יוצרת רשומה זו באופן אוטומטי כשמתחילים להשתמש בשרתי השמות הסמכותיים של Cloudflare.

בחשבונות Enterprise יש גם אפשרות לשנות את ערכי רשומת ה-SOA ש-Cloudflare תשתמש בהם:

• כברירת מחדל של אזור DNS: הגדירו את ערכי רשומת ה-SOA ש-Cloudflare תשתמש בהם לכל האזורים החדשים שנוספים לחשבון. ראו הגדרת ברירות מחדל של אזור DNS להנחיה צעד אחר צעד.
• לאזורים קיימים: דרסו את ברירות המחדל או את הערכים ש-Cloudflare יצרה תחת DNS record options בדף DNS Records.

ראו את הרשימה הבאה למידע על כל שדה ברשומת SOA:

שדות רשומת SOA

• MNAME: שרת השמות הראשי של האזור. שרתי שמות משניים מקבלים עדכוני אזור משרת השמות שצוין בשדה זה.

• RNAME: כתובת האימייל של המנהל האחראי על האזור.

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

  אימייל	RNAME
  [email protected]	john.example.com
  [email protected]	john\.doe.example.com

• Serial: המספר הסידורי של האזור. שרתי שמות משניים מתחילים העברות אזור אם מספר זה עולה.

• Refresh: הזמן (בשניות) שאחריו שרת שמות משני צריך לשאול את השרת הראשי לגבי רשומת SOA, כדי לזהות שינויים באזור. רלוונטי רק אם DNS NOTIFY (RFC 1996) לא מוגדר.

  ברירת מחדל	מינימום	מקסימום
  10000	600	86400

• Retry: הזמן (בשניות) שאחריו שרת שמות משני צריך לנסות שוב לקבל את המספר הסידורי משרת השמות הראשי אחרי ניסיון שנכשל. כל ערך שצוין לא יכול להיות גדול מ-Refresh.

  ברירת מחדל	מינימום	מקסימום
  2400	600	3600

• Expire: הזמן (בשניות) שאחריו שרת שמות משני צריך להפסיק לענות לשאילתות עבור אזור אם השרת הראשי לא מגיב. כל ערך שצוין לא יכול להיות קטן מ-Refresh.

  ברירת מחדל	מינימום	מקסימום
  604800	86400	2419200

• Record TTL: זמן החיים של רשומת ה-SOA.

  ברירת מחדל	מינימום	מקסימום
  3600	1800	3600

• Minimum TTL: ה-TTL לשמירת תשובות שליליות במטמון. ראו RFC 2308 לפרטים.

  ברירת מחדל	מינימום	מקסימום
  1800	60	86400

הערה

כששואלים את רשומת ה-SOA עצמה, ה-TTL בתשובה הוא הקטן מבין הערכים Record TTL ו-Minimum TTL. לדוגמה, אם Record TTL הוא 3600 ו-Minimum TTL הוא 1800, רשומת ה-SOA מוחזרת עם TTL של 1800.

#NS

רשומת שרת שמות (NS) מציינת באיזה שרת יש להשתמש עבור DNS סמכותי.

צריך להוסיף רשומות NS לטבלת רשומות ה-DNS ב-Cloudflare רק כשמשתמשים ב-הגדרת תת-דומיין או ב-האצלת תת-דומיינים מחוץ ל-Cloudflare.

להגדרות השדות, ראו את תיעוד ה-API (גלוי לאחר שבוחרים את סוג הרשומה תחת מפרט גוף הבקשה).

הערה

שרתי השמות של Cloudflare שהוקצו לכם, שרתי שמות מותאמים, וזמני החיים של שרתי השמות התואמים שלהם, נשלטים דרך מקטעים ייעודיים בדף DNS Records. לפרטים, ראו שרתי שמות.

#מגבלות

ביצירת רשומות NS יש מגבלות על מספר שרתי השמות שאפשר לשייך לשם האצלה יחיד.

לפי תקני DNS שמוגדרים ב-RFC 1912, האצלה לא צריכה לכלול יותר משבעה שמות של שרתי שמות לאותו שם האצלה.

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

• Cloudflare תומכת בעד 10 רשומות NS לכל שם האצלה, אבל מומלץ להשאיר את הקבוצה על שבעה או פחות.
• יצירת יותר מ-10 רשומות NS לאותו שם אינה נתמכת. בקשות שחורגות ממגבלה זו עשויות להידחות או להיכשל באימות.

דוגמה

ניהול DNS עבור example.com:

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

#DS ו-DNSKEY

רשומות DS ו-DNSKEY עוזרות ליישם DNSSEC, שחותם קריפטוגרפית על רשומות DNS כדי למנוע זיוף דומיין.

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

להגדרות השדות, ראו את תיעוד ה-API (גלוי לאחר שבוחרים את סוג הרשומה תחת מפרט גוף הבקשה).

#אחר

Cloudflare תומכת גם בסוגי רשומות אחרים שפחות נפוצים, כגון URI, ‏NAPTR, וסוגי רשומות שקשורים לאישורים (SSHFP, ‏TLSA, ‏SMIMEA ו-CERT). ראו את פוסט הבלוג למידע נוסף.