בדף הזה מפורטות כמה אפשרויות מתקדמות להגדרת תוספי אבטחה של DNS (DNSSEC) שאפשר להשתמש בהן אם מפעילים DNSSEC לאזורים המנוהלים. האפשרויות האלה כוללות אלגוריתמים שונים לחתימה, דחיית קיום ויכולת להשתמש בסוגי רשומות שנדרש או מומלץ להשתמש בהם ב-DNSSEC.
סקירה כללית של DNSSEC מופיעה במאמר סקירה כללית של DNSSEC.
העברת סמכויות של תת-דומיינים עם חתימת DNSSEC
אפשר להפעיל DNSSEC לתת-דומיינים שהוקצו להם הרשאות אחרי שמפעילים DNSSEC לדומיין הראשי. כדי להפעיל DNSSEC לתת-דומיינים שהוקצו להם הרשאות, צריך קודם ליצור רשומת DS בתחום DNS של Cloud DNS. צריך גם ליצור רשומת NS אחת או יותר.
כדי ליצור רשומות DS לתת-דומיינים שהוקצו להם הרשאות, צריך לקבל את רשומת ה-DS של האזור. אם האזור המוקצה מתארח גם ב-Cloud DNS, אפשר לקבל את רשומת ה-DS מ Google Cloud המסוף או מ-Google Cloud CLI.
המסוף
נכנסים לדף Cloud DNS במסוף Google Cloud .
עוברים לאזור המנוהל שרוצים לראות את רשומת ה-DS שלו.
כדי לראות את רשומת DS של האזור, בפינה השמאלית העליונה של הדף פרטי האזור, לוחצים על הגדרת רשם.
רשומת ה-DS זמינה בדף הגדרות רשם הדומיינים.
כדי ליצור רשומות NS, פועלים לפי ההוראות שבקטע הוספת רשומה.
gcloud
כדי לקבל את המידע על רשומת DS עבור תת-דומיינים שהוקצו להם הרשאות, מריצים את הפקודה הבאה:
gcloud dns dns-keys list --zone SUBDOMAIN_ZONE
מחליפים את
SUBDOMAIN_ZONEבשם של תחום ה-DNS של תת-הדומיין שהוקצה בפרויקט.הפלט אמור להיראות כך:
ID KEY_TAG TYPE IS_ACTIVE DESCRIPTION 0 1234 KEY_SIGNING True 1 12345 ZONE_SIGNING True
כדי לקבל רשומת DS מלאה ואת כל הפרטים של המפתח, צריך את המזהה של מפתח חתימת המפתח (KSK), שבדרך כלל הוא אפס (0). מריצים את הפקודה הבאה:
gcloud dns dns-keys describe --zone SUBDOMAIN_ZONE KSK_ID \ --format "value(ds_record())"
מחליפים את מה שכתוב בשדות הבאים:
-
SUBDOMAIN_ZONE: השם של תחום ה-DNS של תת-הדומיין שהוקצה בפרויקט -
KSK_ID: מספר מזהה ה-KSK, בדרך כלל 0
הפלט אמור להיראות כך:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
-
מעתיקים את הפלט מהפקודה הקודמת כדי להשתמש בו בשלב הבא.
כדי ליצור את רשומות ה-DS להעברת סמכויות מאובטחת, מריצים את הפקודה הבאה כדי להתחיל את העסקה:
gcloud dns record-sets transaction start --zone PARENT_ZONE
מחליפים את
PARENT_ZONEבשם של אזור ה-DNS הראשי בפרויקט שבו אתם יוצרים את הרשומות עבור תת-הדומיין שהוקצה.הפלט אמור להיראות כך:
Transaction started [transaction.yaml].
לאחר מכן, מריצים את הפקודה הבאה כדי להוסיף קבוצת רשומות:
gcloud dns record-sets transaction add --zone PARENT_ZONE \ --ttl TIME_TO_LIVE \ --type DS \ --name subdomain.example.com \ "DS_RECORD_AND_KEY"
מחליפים את מה שכתוב בשדות הבאים:
-
PARENT_ZONE: השם של תחום ה-DNS הראשי בפרויקט -
TIME_TO_LIVE: אורך חיים (TTL) של האזור בשניות, למשל 3600 -
subdomain.example.com: תת-דומיין של שם ה-DNS של האזור -
DS_RECORD_AND_KEY: רשומת ה-DS והמפתח שקיבלתם בשלב 2, כמו44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
הפלט אמור להיראות כך:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb Record addition appended to transaction at [transaction.yaml].
-
כדי להוסיף רשומות NS, משתמשים בפקודה הבאה:
gcloud dns record-sets transaction add --zone PARENT_ZONE \ --ttl TIME_TO_LIVE \ --type NS \ --name subdomain.example.com \
מחליפים את מה שכתוב בשדות הבאים:
-
PARENT_ZONE: השם של תחום ה-DNS הראשי בפרויקט -
TIME_TO_LIVE: אורך חיים (TTL) של האזור בשניות, למשל 3600 -
subdomain.example.com: תת-דומיין של שם ה-DNS של האזור
-
מזינים את ה-RRData הבא:
ns-cloud-e1.googledomains.com. \ ns-cloud-e2.googledomains.com. \ ns-cloud-e3.googledomains.com. \ ns-cloud-e4.googledomains.com.
הפלט אמור להיראות כך:
Record addition appended to transaction at [transaction.yaml].
כדי להפעיל את העסקה, משתמשים בפקודה הבאה:
gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
מחליפים את
EXAMPLE_ZONEבשם של תחום DNS בפרויקט.הפלט אמור להיראות כך:
Executed transaction [transaction.yaml] for managed-zone [dns-example]. Created [https://dns.googleapis.com/dns/v1/projects/example/managedZones/example_zone/changes/42]. ID START_TIME STATUS 42 2019-08-08T23:12:49.100Z PENDING
שימוש באפשרויות מתקדמות לחתימה
כשמפעילים DNSSEC לאזור מנוהל או כשיוצרים אזור מנוהל עם DNSSEC, אפשר לבחור את אלגוריתמי החתימה של DNSSEC ואת סוג השלילה של קיום.
אפשר לשנות את הגדרות ה-DNSSEC (לדוגמה, את האלגוריתם שמשמש לחתימה קריפטוגרפית של רשומות) באזור מנוהל לפני שמפעילים את ה-DNSSEC. אם DNSSEC כבר מופעל באזור מנוהל, כדי לבצע שינויים צריך קודם להשבית את DNSSEC, לבצע את השינויים הנדרשים ואז להשתמש בפקודה הבאה כדי להפעיל מחדש את DNSSEC:
gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on
מחליפים את EXAMPLE_ZONE בשם של תחום DNS בפרויקט.
פרטים נוספים מופיעים במאמר בנושא הפעלת DNSSEC לאזורים מנוהלים קיימים.
הפקודה הבאה מפעילה DNSSEC עם ECDSA של 256 ביט ו-NSEC כדי ליצור את חבילות התגובה הקטנות ביותר שחתומות ב-DNSSEC באמצעות Cloud DNS:
gcloud dns managed-zones update EXAMPLE_ZONE \ --dnssec-state on \ --ksk-algorithm ECDSAP256SHA256 --ksk-key-length 256 \ --zsk-algorithm ECDSAP256SHA256 --zsk-key-length 256 \ --denial-of-existence NSEC
מחליפים את EXAMPLE_ZONE בשם של תחום DNS בפרויקט.
אם מציינים אלגוריתמים או אורכי מפתח של KSK או ZSK, צריך לציין את כולם ואת הארגומנטים שלהם בפקודה:
--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length
אפשר לציין את האפשרות 'שלילת קיום' כ-NSEC או כ-NSEC3 ללא קשר לאלגוריתמים.
בטבלה הבאה מפורטות האפשרויות והארגומנטים של האלגוריתמים הנתמכים. ב-Cloud DNS אין אפשרות להשתמש באלגוריתמים או בפרמטרים אחרים.
| אלגוריתם | אורכי KSK | אורכי ZSK | תגובות |
|---|---|---|---|
| RSASHA256 | 2048 | 1024, 2048 | |
| RSASHA512 | 2048 | 1024, 2048 | לא נתמך באופן נרחב |
| ECDSAP256SHA256 | 256 | 256 | |
| ECDSAP384SHA384 | 384 | 384 | לא נתמך באופן נרחב |
אם לא מציינים אלגוריתם, Cloud DNS משתמש בערכי ברירת המחדל הבאים:
| סוג מפתח | אלגוריתם ברירת המחדל | אורך המפתח שמוגדר כברירת מחדל |
|---|---|---|
| מפתח לחתימת מפתחות (KSK) | RSASHA256 | 2048 |
| מפתח חתימה של אזור (ZSK) | RSASHA256 | 1024 |
ההבדלים באבטחה ובביצועים בין RSASHA256 לבין RSASHA512 הם מינימליים, וגודלי התגובות החתומות זהים. לאורך המפתחות יש חשיבות: מפתחות ארוכים יותר פועלים לאט יותר והתגובות גדולות יותר (אפשר לעיין בניתוחים של גודל התגובה עבור אזור הבסיס וTLD, וגם בניתוח של ביצועים בצד השרת ב-Windows).
התמיכה ב-ECDSA ב-מפענח DNS מוגבלת למערכות חדשות יחסית. מקודדי DNS ישנים שלא יכולים לאמת אזורים עם חתימת ECDSA מחשיבים אותם כלא חתומים, וזה עלול להיות לא מאובטח אם משתמשים בסוגים חדשים של רשומות שמסתמכים על DNSSEC. התמיכה ב-ECDSA של 256 ביט נפוצה בקרב רשמים ורשומות, אבל לא אוניברסלית. רק מעט רשמים ומעט מאוד רשמים תומכים ב-ECDSA של 384 ביט. שימוש ב-ECDSA יכול להיות יעיל אם לא צריך לתמוך בלקוחות ישנים יותר. החתימות קטנות בהרבה ומהירות יותר לחישוב.
מומלץ להימנע משימוש באלגוריתמים שונים למפתחות KSK ו-ZSK באזורים מנוהלים. שימוש כזה מקטין את התאימות ועלול לפגוע באבטחה. יכול להיות שחלק מהמקודדים שמאמתים את DNSSEC לא יצליחו לאמת אזורים עם אלגוריתמים של DNSKEY שלא משמשים לחתימה על כל הרשומות באזור. זה נכון גם אם RFC 6840 מציין ש "אסור להם להתעקש שכל האלגוריתמים ... ב-DNSKEY RRset יפעלו". אם זה לא מדאיג אתכם (רוב הרכיבים לפתרון בעיות אימות פועלים לפי RFC 6840), אתם יכולים להשתמש ב-RSASHA256 עבור KSK וב-ECDSA עבור ZSK אם רשם הדומיינים או רישום TLD לא תומכים ב-ECDSA ואתם צריכים להקטין את גודל התגובה.
NSEC3 הוא סוג ברירת המחדל של אי-קיום; הוא מספק הגנה מוגבלת מפני סורקי אזורים שמנסים לגלות את כל הרשומות באזור שלכם.
ההגדרות של NSEC3PARAM קבועות: NSEC3 opt-out מושבת מטעמי אבטחה,
ויש איטרציה נוספת של גיבוב (hash) (בסך הכול שתיים) עם מלח (salt) של 64 ביט.
NSEC מספק תגובות קטנות יותר, אבל לא הגנה מפני zone walking. שימוש ב-NSEC יכול גם לצמצם את מספר השאילתות לגבי דומיינים שלא קיימים. Google Public DNS ומספר מקודדי DNS אחרים שמאמתים DNSSEC יכולים ליצור תגובות שליליות מרשומות NSEC שנשמרו במטמון בלי לשלוח שאילתה לאזור Cloud DNS שלכם.
RFC 8624 כולל הנחיות נוספות לבחירת אלגוריתם.
שימוש בסוגים חדשים של רשומות DNS באזורים מאובטחים באמצעות DNSSEC
אחרי שהדומיין שלכם יאובטח באופן מלא באמצעות DNSSEC, תוכלו להתחיל להשתמש בכמה סוגים חדשים של רשומות DNS שמסתמכים על האותנטיות והשלמות של אזורים חתומים באמצעות DNSSEC כדי לשפר את האבטחה של שירותים אחרים.
SSHFP
רשומות SSHFP מכילות טביעת אצבע של מפתח ציבורי של שרת SSH שאפליקציות לקוח SSH יכולות להשתמש בה כדי לאמת את שרתי ה-SSH. בדרך כלל, לקוחות SSH דורשים אינטראקציה עם המשתמש כדי לאשר את המפתח הציבורי של השרת בחיבור הראשון, ומציגים אזהרות אם המפתח משתנה. לקוח SSH שמוגדר להשתמש ב-SSHFP תמיד משתמש במפתח ברשומת ה-SSHFP של השרת. רק מפתחות של שרתים ללא רשומת SSHFP נשמרים לשימוש חוזר.
הפורמט של רשומת SSHFP הוא:
- מספר האלגוריתם
- מספר סוג טביעת האצבע
- טביעת האצבע של מפתח השרת
מספרי האלגוריתמים של SSH הם:
- RSA
- חוק ה-DSA
- ECDSA
- ED25519
אלה סוגי טביעות האצבע:
- SHA-1 (הוצא משימוש, רק לצורך תאימות)
- SHA-256
ב-StackExchange יש הצעות ליצירת רשומות SSHFP, ויש כלים ליצירת רשומות כאלה על ידי סריקת שרתים, שימוש בקבצים קיימים של מארחים מוכרים או ניהול הגדרות. דוגמאות וקישורים נוספים זמינים במאמר רשומות SSHFP: DNS שמספק מפתחות ציבוריים של מארחי SSH.
רשומות TLSA ו-DANE
רשומות TLSA מכילות מידע שאפשר להשתמש בו כדי לאמת אישורי X.509 (כמו אישורים שמשמשים את HTTPS) בלי להסתמך על אחת מרשויות האישורים (CA) שמוגדרות מראש שחותמות עליהם.
כך תוכלו להגדיר רשויות CA משלכם וליצור אישורים ל-HTTPS. ההרשאה הזו מאפשרת גם אימות של אישורים לפרוטוקולים כמו SMTP, שבהם בדרך כלל אין תמיכה באפליקציות לרשויות אישורים מהימנות שהוגדרו מראש.
DANE (אימות דומיין של ישויות בעלות שם), כפי שמצוין ב-RFC 6698 וב-RFCs קשורים, משתמש ברשומות TLSA בדרכים ספציפיות כדי לאבטח פרוטוקולים ואפליקציות רבים. ב-IETF Journal וב-Internet Society יש מאמר מבוא שימושי וסקירה כללית על DANE.
HTTPS
DANE מאפשר להגדיר שרתי HTTPS באופן מאובטח באמצעות אישורים שנוצרו עם תשתית CA משלכם על סמך OpenSSL או CFSSL של Cloudflare.
הכלי DANE validator for HTTPS servers של SIDNLabs יכול לעזור לכם לבדוק פריסת DANE עבור HTTPS.
אימות אישור TLS של SMTP (אימייל)
פרוטוקול האימייל SMTP חשוף למתקפות שדרוג לאחור שמשביתות את ההצפנה, ו-DANE מספק דרך למנוע את המתקפות האלה.
באתר של Internet Society יש הדרכה בת שני חלקים על שימוש ב-DANE עבור SMTP עם אישורים אוטומטיים בחינם שזמינים ב-Let's Encrypt, כולל המלצות להימנע משימוש בפורמטים מסוימים של רשומות TLSA עם אישורים של Let's Encrypt:
במאמר טעויות נפוצות אפשר למצוא עצות מצוינות (וכלי לאימות דומיין DANE ל-HTTPS ול-SMTP). כלי האימות של כתובות אימייל בודק גם את DANE.
אימות אישור TLS של XMPP (צ'אט Jabber)
גם שירותים אחרים שמשתמשים ברשומות SRV, כמו XMPP, יכולים להשתמש ב-DANE. בדוגמה של XMPP נעשה שימוש בהגדרת DANE-SRV כפי שמצוין ב-RFC 7673.
שיוך מפתח ציבורי של TXT (OpenPGP / GnuPG)
אפשר להשתמש ברשומות TXT בלי DNSSEC, אבל רשומות TXT שחתומות על ידי DNSSEC מספקות רמת ודאות גבוהה יותר לגבי האותנטיות שלהן. זה חשוב לפרסום מפתחות ציבוריים של OpenPGP (GnuPG) שמבוסס על DNS, שלא נחתמים על ידי גורמים מוכרים כמו רשויות אישורים של X.509.
לדוגמה, אם אליס מפרסמת רשומת TXT כמו זו שבהמשך באזור an.example שחתום ב-DNSSEC, ומארחת עותק של המפתח הציבורי בפורמט ASCII ב-URI שצוין, בוב יכול לחפש מפתח OpenPGP עבור alice@an.example עם אבטחה סבירה (זו לא החלפה של אימות רשת האמון, אבל היא מאפשרת הצפנה ב-OpenPGP עם צדדים לא מוכרים):
alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"
אפשר להשתמש בהוראות האלה כדי ליצור רשומות TXT של מפתח PKA בגרסה 1 (כפי שהן נקראות במאמר פרסום מפתחות ב-DNS).
במדריך המלא לפרסום מפתחות PGP ב-DNS מוסבר איך ליצור רשומות CERT של OpenPGP (אבל Cloud DNS לא תומך ברשומות CERT או OPENPGPKEY).
אם רשמתם את מפתח OpenPGP ב-Keybase.io, לא צריך לארח את המפתח בשרת שלכם. במקום זאת, אפשר להשתמש בכתובת URL כמו https://keybase.io/KEYBASE_USERNAME/key.asc (מחליפים את KEYBASE_USERNAME בשם המשתמש שלכם ב-Keybase.io).
אם העליתם את מפתח OpenPGP לשרת מפתחות, אתם יכולים גם להשתמש במזהה URI מסוג hkp: לשרת המפתחות הזה, כמו hkp://subkeys.pgp.net או hkp://pgp.mit.edu, אבל יכול להיות שמשתמשים שנמצאים מאחורי חומות אש שחוסמות את יציאה 11371 לא יוכלו להגיע אליו (חלק משרתי המפתחות מספקים כתובות URL מסוג HTTP ביציאה 80).
TXT (SPF, DKIM ו-DMARC)
בהמשך מפורטים שלושה סוגים נוספים של רשומות TXT שבהן אפשר להשתמש כדי לאבטח את שירותי האימייל ולמנוע מפיצי ספאם ומנוכלים לשלוח אימיילים שנראים כאילו הם מגיעים מהדומיין שלכם (גם אם הם לא באמת מגיעים ממנו):
SPF: מגדיר את שרתי ה-SMTP (לפי שם הדומיין או כתובת ה-IP) שיכולים לשלוח אימיילים בשם הדומיין.
DKIM: מפרסם קבוצה של מפתחות ציבוריים שמשמשים לאימות של אימייל שנשלח מדומיין, ומגן על הודעות מפני שינוי בזמן ההעברה.
DMARC: מציין מדיניות דומיין ודיווח על אימות SPF ו-DKIM ודיווח על שגיאות.
כדי לוודא שהדומיין שלכם מוגדר בצורה נכונה לשימוש בכל שלושת סוגי הרשומות האלה, אתם יכולים להשתמש בכלי לבדיקת אימות האימייל. כדי לקבל עצות מועילות לגבי הגדרת רשומות SPF, אפשר לעיין במאמר שאלות נפוצות על טעויות נפוצות.
שימוש בסוגים אחרים של קבוצות רשומות שמשופרים על ידי DNSSEC
בנוסף לרשומות TXT, יש עוד כמה סוגים של רשומות שמומלץ להשתמש בהן עם DNSSEC, גם אם הן לא מחייבות זאת.
CAA
רשומות של הרשאה ברשות האישורים (CAA) מאפשרות לכם לקבוע אילו רשויות ציבוריות שמנפיקות אישורים יכולות ליצור אישורי TLS או אישורים אחרים לדומיין שלכם. הבקרה הזו שימושית (ואפקטיבית) במיוחד אם רוצים לוודא שרשות אישורים ציבורית שמנפיקה אישורים עם אימות דומיין (DV) (כמו LetsEncrypt.org) לא תנפיק אישורים לדומיין שלכם.
רשומת CAA טיפוסית היא בפורמט פשוט כמו 0 issue "best-ca.example"
זה, שמאפשר לרשות האישורים best-ca.example (ולא לרשות אישורים אחרת) להנפיק אישורים לשמות בדומיין שבו נמצאת קבוצת רשומות ה-CAA.
אם רוצים לאפשר לכמה רשויות אישורים להנפיק אישורים, צריך ליצור כמה רשומות CAA.
ב-RFC 6844 מפורטים פרטים נוספים על השימוש בסוג של קבוצת רשומות CAA, ומומלץ מאוד להשתמש ב-DNSSEC.
IPSECKEY
אפשר גם להפעיל הצפנה אופורטוניסטית דרך מנהרות IPsec על ידי פרסום רשומות IPSECKEY. להטמעה של strongSwan IPsec VPN יש פלאגין שמשתמש ברשומות IPSECKEY.
בנוסף להצבת רשומות IPSECKEY באזורים הרגילים של העברה, כמו service.example.com, בקטע 1.2 של RFC 4025 נדרש משערי אבטחה לחפש רשומות IPSECKEY באזורים ההפוכים ip6.arpa ו-in-addr.arpa.
תמיכה ב-DNSSEC לאזורים הפוכים היא פחות נפוצה מאשר לאזורים קדימה, ונדרש ספק אינטרנט שמיישם DNSSEC. עם זאת, יש ספקי אינטרנט שיכולים לתמוך ב-DNSSEC להעברות של אזורים הפוכים.
אזורים הפוכים לכתובות IP חיצוניות של מכונות וירטואליות ב-Compute Engine עדיין לא תומכים בהקצאת הרשאות.
המאמרים הבאים
- כדי ליצור, לעדכן, להציג ברשימה ולמחוק אזורים מנוהלים, אפשר לעיין במאמר בנושא ניהול אזורים.
- כדי למצוא פתרונות לבעיות נפוצות שאתם עשויים להיתקל בהן במהלך השימוש ב-Cloud DNS, אפשר לעיין במאמר בנושא פתרון בעיות.
- בסקירה הכללית על Cloud DNS תוכלו לקרוא על Cloud DNS.