בדף הזה מפורטות כמה אפשרויות מתקדמות להגדרת תוספי אבטחה של DNS (DNSSEC) שאפשר להשתמש בהן אם מפעילים את DNSSEC באזורים המנוהלים. האפשרויות האלה נעות בין אלגוריתמים שונים לחתימה ודחיית קיום לבין היכולת להשתמש בסוגי רשומות שדורשים או ממליצים על שימוש ב-DNSSEC.
הענקת גישה לשכבות משנה עם חתימת DNSSEC
אפשר להפעיל את DNSSEC לדומיינים משניים שהוקצו אחרי שמפעילים את DNSSEC לדומיין הראשי. כדי להפעיל את DNSSEC עבור תת-דומיינים שהוקצו, צריך קודם ליצור רשומת DS בתחום Cloud DNS. צריך גם ליצור רשומת NS אחת או יותר.
כדי ליצור רשומות DS לתת-דומיינים שהוקצו, צריך לקבל את רשומת ה-DS של האזור. אם גם הדומיין שהוקצה מתארח ב-Cloud DNS, תוכלו לקבל את רשומת ה-DS מהמסוף Trusted Cloud או מ-Google Cloud CLI.
המסוף
נכנסים לדף Cloud DNS במסוף Trusted Cloud .
עוברים לאזור המנוהל שרוצים לראות בו את רשומת ה-DS.
כדי לראות את רשומת ה-DS של הדומיין, לוחצים על Registrar Setup (הגדרת הרשם) בפינה השמאלית העליונה של הדף Zone details (פרטי הדומיין).
רשומת ה-DS זמינה בדף Registrar Setup.
כדי ליצור רשומות NS, פועלים לפי ההוראות במאמר הוספת רשומה.
gcloud
כדי לקבל את פרטי רשומות ה-DS של תת-דומיינים שהוקצו, מריצים את הפקודה הבאה:
gcloud dns dns-keys list --zone EXAMPLE_ZONE
מחליפים את
EXAMPLE_ZONEבשם של תחום ה-DNS של תת-הדומיין שהוקצה בפרויקט.הפלט אמור להיראות כך:
ID KEY_TAG TYPE IS_ACTIVE DESCRIPTION 0 1234 KEY_SIGNING True 1 12345 ZONE_SIGNING True
כדי לקבל רשומת DS מלאה ואת כל פרטי המפתח, צריך את המזהה של מפתח ה-KEY_SIGNING (KSK), שבדרך כלל הוא אפס (0). מריצים את הפקודה הבאה:
gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \ --format "value(ds_record())"
מחליפים את מה שכתוב בשדות הבאים:
EXAMPLE_ZONE: השם של תחום ה-DNS של תת-הדומיין שהוקצה בפרויקטKSK_ID: מספר המזהה של KSK, בדרך כלל 0
הפלט אמור להיראות כך:
44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
מעתיקים את הפלט מהפקודה הקודמת כדי להשתמש בו בשלב הבא.
כדי ליצור את רשומות ה-DS להענקת גישה משנית מאובטחת, מריצים את הפקודה הבאה כדי להתחיל את העסקה:
gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
מחליפים את
EXAMPLE_ZONEבשם של תחום ה-DNS ההורה בפרויקט שבו יוצרים את הרשומות של תת-הדומיין שהוקצה.הפלט אמור להיראות כך:
Transaction started [transaction.yaml].
לאחר מכן, מריצים את הפקודה הבאה כדי להוסיף קבוצת רשומות:
gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \ --ttl TIME_TO_LIVE \ --type DS \ --name subdomain.example.com \ "DS_RECORD_AND_KEY"
מחליפים את מה שכתוב בשדות הבאים:
EXAMPLE_ZONE: שם תחום ה-DNS ההורה בפרויקטTIME_TO_LIVE: משך החיים של האזור בשניות, למשל 3600subdomain.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 EXAMPLE_ZONE \ --ttl TIME_TO_LIVE \ --type NS \ --name subdomain.example.com \
מחליפים את מה שכתוב בשדות הבאים:
EXAMPLE_ZONE: שם תחום ה-DNS ההורה בפרויקטTIME_TO_LIVE: משך החיים של האזור בשניות, למשל 3600subdomain.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 ו-NSEC של 256 ביט, כדי לקבל את חבילות התשובה הקטנות ביותר החתומה על ידי 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 הם מינימליים, וגודל התשובות החתולות זהה. אורך המפתחות חשוב: מפתחות ארוכים יותר איטיים יותר והתשובות שלהם גדולות יותר (ראו ניתוחים של גודל התשובות לתחום הבסיס ולדומיינים ברמה העליונה, וניתוח של הביצועים בצד השרת ב-Windows).
התמיכה ב-Resolver עבור ECDSA מוגבלת למערכות חדשות יחסית. מקודדי DNS ישנים שלא יכולים לאמת תחומים עם חתימת ECDSA מתייחסים אליהם כאל תחומים ללא חתימת, ויכול להיות שהם לא מאובטחים אם משתמשים בסוגים חדשים של רשומות שמסתמכות על DNSSEC. התמיכה של הרשם והמרשם ב-ECDSA של 256 ביט נפוצה, אבל לא אוניברסלית. רק כמה מרשםים ועוד פחות רשמים תומכים ב-ECDSA של 384 ביט. השימוש ב-ECDSA יכול להיות יעיל אם אין צורך לתמוך בלקוחות ישנים יותר, כי החתימות קטנות בהרבה ופעולת החישוב שלהן מהירה יותר.
מומלץ להימנע משימוש באלגוריתמים שונים ל-KSK ול-ZSK באזורים המנוהלים. השימוש באלגוריתמים שונים פוגע בתאימות ועלול לפגוע באבטחה. יכול להיות שמקודדי DNS מסוימים לא יאמתו תחומים עם אלגוריתמים של DNSKEY שלא משמשים לחתימה על כל הרשומות בתחום. זה נכון למרות שב-RFC 6840 כתוב "אסור להתעקש שכל האלגוריתמים ... ב-RRset של DNSKEY יפעלו". אם זה לא מטריד אתכם (רוב המפצים המאמתים פועלים בהתאם ל-RFC 6840), תוכלו להשתמש ב-RSASHA256 עבור KSK וב-ECDSA עבור ZSK אם רשם הדומיינים או רשם ה-TLD לא תומכים ב-ECDSA ואתם צריכים להקטין את גודל התשובות.
NSEC3 הוא סוג ברירת המחדל של דחייה של קיומו של פריט. הוא מספק הגנה מוגבלת מפני 'מטיילים באזורים' שמנסים לגלות את כל הרשומות באזור.
ההגדרות של NSEC3PARAM קבועות: NSEC3 opt-out מושבת מטעמי אבטחה, ויש עוד חזרה אחת של גיבוב (סה"כ שתי חזרות) עם מלח של 64 ביט.
התשובות של NSEC קצת קטנות יותר, אבל אין בהן הגנה מפני סריקה של תחומים. שימוש ב-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 של השרת עבור אותו שרת. רק מפתחות של שרתי SSH ללא רשומת 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 באמצעות אישורים שנוצרו בתשתית של רשות אישורים משלכם, על סמך OpenSSL או CFSSL של Cloudflare.
מאמת DANE לשרתים של HTTPS של 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)
גם XMPP (ושירותים אחרים שמשתמשים ברשומות SRV) יכולים להפיק תועלת מ-DANE. דוגמה ל-XMPP שמשתמשת בהגדרת DANE-SRV כפי שמפורט ב-RFC 7673.
שיוך של מפתח ציבורי TXT (OpenPGP / GnuPG)
אפשר להשתמש ברשומות TXT בלי DNSSEC, אבל רשומות TXT חתומות על ידי DNSSEC מספקות רמה גבוהה יותר של אמינות. הדבר חשוב לפרסום של מפתחות ציבוריים של OpenPGP (GnuPG) שמבוסס על DNS, שלא חתומים על ידי גורמים ידועים כמו רשויות אישור X.509.
לדוגמה, אם Alice מפרסמת רשומת TXT כמו זו הבאה באזור an.example החתום על ידי DNSSEC, ומארחת עותק של המפתח הציבורי המאובטח ב-ASCII בכתובת ה-URI הנתונה, Bob יכול לחפש מפתח 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 מסביר איך ליצור רשומות OpenPGP CERT (אבל 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 או אישורים אחרים לדומיין שלכם. אמצעי הבקרה הזה שימושי (ויעיל) במיוחד אם רוצים לוודא שלא מתבצעת הנפקה של אישורים לדומיין על ידי רשות אישורים ציבורית (כמו LetsEncrypt.org) שמנפיקה אישורי DV (אישורים מאומתים לדומיין).
לרשומת CAA רגילה יש פורמט פשוט כמו 0 issue "best-ca.example", שמאפשר לרשות האישורים best-ca.example (ולא לרשות אישורים אחרת) להנפיק אישורים לשמות בדומיין שבו נמצאת קבוצת רשומות ה-CAA.
אם רוצים לאפשר ליותר מרשות אישורים אחת להנפיק אישורים, צריך ליצור כמה רשומות CAA.
RFC 6844 מספק פרטים נוספים על השימוש בסוג קבוצת רשומות CAA, וממליץ מאוד להשתמש ב-DNSSEC.
IPSECKEY
אפשר גם להפעיל הצפנה אופורטוניסטית דרך מנהרות IPsec על ידי פרסום של רשומות IPSECKEY. להטמעת ה-VPN של IPsec ב-strongSwan יש פלאגין שמשתמש ברשומות IPSECKEY.
בנוסף למיקום של רשומות IPSECKEY בתחומים הרגילים של ניתוב קדימה, כמו service.example.com, סעיף 1.2 ב-RFC 4025 מחייב שערי אבטחה לחפש רשומות IPSECKEY בתחומים ההפוכים ip6.arpa ו-in-addr.arpa.
תמיכה ב-DNSSEC עבור תחומים הפוכים פחות נפוצה מאשר תמיכה בתחומים ישירים, והיא דורשת ספק שירותי אינטרנט (ISP) שמטמיע את DNSSEC. עם זאת, יש ספקי אינטרנט מסוימים שיכולים לתמוך ב-DNSSEC להענקת גישה לתחומים הפוכים.
עדיין אין תמיכה בהענקת גישה (delegation) לתחומים הפוכים של כתובות IP חיצוניות של מכונות וירטואליות ב-Compute Engine.
המאמרים הבאים
- במאמר ניהול תחומים מוסבר איך יוצרים, מעדכנים, מציגים ברשימה ומוחקים תחומים מנוהלים.
- במאמר פתרון בעיות מפורטות פתרונות לבעיות נפוצות שעשויות להתרחש במהלך השימוש ב-Cloud DNS.
- בסקירה הכללית על Cloud DNS תוכלו לקרוא מידע נוסף על Cloud DNS.