• בלוג
  • DNSSEC – מה זה ולמה הוא חשוב?

DNSSEC – מה זה ולמה הוא חשוב?

    DNSSEC – מה זה ולמה הוא חשוב?

    פורסם ב 28-04-2025

    information-security

    לא נחזיק אתכם במתח. DNSSEC – ר”ת של Domain Name System Security Extension – הוא תוסף אבטחה לפרוטוקול DNS. הוא נועד לאמת את התשובות המתקבלות בעת חיפוש שמות דומיין. האימות נחוץ על מנת למנוע זיוף של התשובות לשאילתות DNS, כאשר באמצעות זיוף זה ניתן להפנות גולשים ברשת האינטרנט לאתרים עוינים עם מטרות לא טהורות כלל.
    איך כל זה עובד?

    נתחיל מההתחלה.

    כפי שבוודאי הבנתם ממאמרים קודמים, אנחנו אוהבים שהכל ברור ומובן – חשוב לנו שתדעו מה אתם עושים, ולמה. כדי להבין איך DNSSEC עובד, קודם עלינו להבין מהו פרוטוקול DNS.

    פרוטוקול DNS

    השרת

    כדי שאתרי אינטרנט ויישומי רשת (ולמעשה כל פיסת מידע המורכבת מנתונים) יהיו נגישים ברשת – בין אם מדובר ברשת האינטרנט ובין אם מדובר ברשת פנימית כלשהי, כמו הרשת בבית שלכם או הרשת הארגונית במשרד- הם צריכים להתארח על שרת.
    שרת הנו מחשב לכל דבר. יש לו מעבד, זיכרון פנימי (RAM), כונן אחסון וכדומה. מה שמקנה למחשב את התואר “שרת” הוא תפקידו – לאחסן שירות שנועד להיות נגיש דרך הרשת ולנהל את התקשורת בין אותו שירות ללקוחות ברשת – הגולשים, העובדים וכדומה. כלומר, לשרת את אותם לקוחות. באמצעות מערכת הפעלה המתאימה לתפקוד הספציפי הזה, פאנל ניהול והגדרות שונות, ניתן להפוך מחשב לשרת.

    IP – פרוטוקול אינטרנט

    כדי שמכשירים יזהו שרתים (ואחד את השני) ברשת, ויוכלו לפנות לשירותים שכל שרת מספק, יש צורך באמצעי זיהוי. אמצעי הזיהוי הזה הנו מושג שאנחנו שומעים הרבה בהקשרים שונים – כתובת IP (פרוטוקול אינטרנט – Internet Protocol). כתובת ה-IP היא מזהה מספרי לכל מכשיר בכל רשת – למעשה, היא מעין נקודות ציון של המכשיר במפת הרשת.

    אם, לדוגמה, אנחנו רוצים להיכנס לממשק של הנתב (ראוטר) שלנו, עלינו להתחבר אליו (כלומר, לרשת הביתית) ולהקליד את כתובת ה-IP שלו (לרוב, תהיה זו כתובת בסגנון 192.168.1.1). הנתב “מקצה” לכל מכשיר כתובת IP כאמצעי זיהוי ברשת. זאת, בהנחה שהמכשיר מוגדר לקבל כתובת IP באופן דינמי; מרבית המכשירים כיום מאפשרים הגדרת כתובת IP סטטית.

    כאשר מדובר ברשת ענקית וכמעט אינסופית, כמו רשת האינטרנט, דברים קצת מסתבכים. רשת האינטרנט מלאה באתרים ובשירותים אליהם אנו רוצים/צריכים לגשת, ולכולם יש כתובות IP שונות.
    המוח האנושי אינו מסוגל לזכור כמות גבוהה של מספרים. נסו, למשל, לגלות מהו מספר ה-IP של השרתים המארחים שלושה או ארבעה מהאתרים האהובים עליכם, ולזכור את המספרים האלה במקום להקליד את כתובות האינטרנט שלהם. מסורבל, נכון? שלא לדבר על הקושי הכרוך בלזכור את המספרים עצמם, או בהשלכות האבטחה שיכולות לנבוע מחשיפת כתובת ה-IP האמיתית של השרת בידי גורמים זדוניים.

    לשם כך פותח פרוטוקול DNS, או מערכת שם מתחם (Domain Name System).

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

    איך פרוטוקול DNS עובד?

    1. הלקוח – הגולש, או מי שמשתמש בשירות הרשת, מקליד את כתובת הדומיין בשורת החיפוש של הדפדפן.
    2. הדפדפן שולח שאילתה לשרת ה-DNS הקרוב אליו: “מה כתובת ה-IP של השרת שרשום על הדומיין הזה?”. שרת ה-DNS יכול להיות מטעם ספק האינטרנט של הגולש, או אחד אחר לבחירתו (לדוגמה, שרת ה-DNS של גוגל). שרת ה-DNS ידוע גם כ”פותר שמות שרת”, או כ-Resolving Nameserver.
    3. בפני שרת ה-DNS ניצבות שתי אפשרויות. הראשונה היא לבדוק אם התשובה לשאילתה שנשלחה מהדפדפן קיימת במטמון השרת. אם המידע קיים במטמון של שרת ה-DNS, מה טוב – נחסך הזמן הנוסף שמצריכה האפשרות השנייה, והשרת מעביר את המידע ישר לדפדפן.
      האפשרות השנייה, בהיעדר המידע במטמון של שרת ה-DNS, היא לפנות לשרתים אחרים בהיררכיה (כן, יש היררכיה של שרתי DNS). כלומר, שרת ה-DNS פונה בשאילתה לשרתי DNS “מעליו”, על הדומיין ולאיזו כתובת IP של איזה שרת הוא משויך. לבסוף, שרת ה-DNS מקבל את התשובה, ומספק את התשובה לדפדפן.
    1. הדפדפן, שקיבל את נקודות הציון של השרת (כתובת ה-IP שלו) ברשת האינטרנט, מאפשר למשתמש לנהל אינטראקציה עם השירות שהשרת מארח.
    תרשים המתאר את הפעולה של פרוטוקול DNS, שלשם אבטחתו פותח DNSSEC.
    פרוטוקול DNS בשלבים

    אז מה הבעיה?

    כמו כל דבר בעולם הדיגיטלי, ועל אחת כמה וכמה כאשר מדובר בתקשורת, גם את פרוטוקול DNS ניתן לנצל בדרכים שונות. זאת מאחר ו-פרוטוקול DNS לכשעצמו אינו מאובטח כלל.
    לא ניכנס לכל הדרכים בהן ניתן לתקוף את הפרוטקול – אמרנו שלא נחזיק אתכם במתח.
    כן נתמקד בסוג התקפה רלוונטי לענייננו:

    הרעלת/זיוף DNS

    או DNS Cache Poisoning (לפעמים נקראת רק DNS Poisoning). נקראת גם DNS Spoofing. למעשה, השם די מסגיר מה היא עושה, במיוחד אם קראתם איך DNS עובד.
    זיוף או הרעלת DNS מתבצע כאשר תוקף מעביר מידע שגוי על דומיין מסויים לשרת ה-DNS, או שמתבצעת פריצה ו”השתלה” של מידע שגוי למטמון של שרת ה-DNS. השרת מספק את המידע הכוזב לגולש מתוך המטמון שלו, כאשר הוא מקבל שאילתה מהדפדפן.

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

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

    DNSSEC פותח כדי להתמודד עם הבעיה הזו.

    איך? על ידי שימוש בחתימות דיגיטליות, כדי לאמת שהמידע שמגיע לשרת ה-DNS מהשרתים שמעליו בהיררכיה הוא אכן שלהם. כלומר, המידע המתקבל על ידי שרת ה-DNS “נושא” חתימה דיגיטלית של שרת השורש, שאומתה על ידי כל אחד מהשרתים האחרים בהיררכיה. אותנטיות החתימה מאומתת באמצעות מפתחות הצפנה, כאשר בפיענוח מפתחות אלה, יודע שרת ה-DNS שהחתימה היא אכן של שרת השורש, ושהמידע שהתקבל משרת השמות הסמכותני הוא למעשה כתובת ה-IP האמיתית של השרת שהדפדפן מחפש.

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

    רשומות

    פרוטוקול DNS משתמש ברשומות (Resource Records, או RR בקיצור) – קבצים המכילים מידע על הדומיינים ועל השרתים הקשורים אליהם. אם לדייק, הם מכילים מידע לאן להפנות את הגולש בשאילתת DNS כאשר היא מתקבלת – כתובות IP, שרתי אימייל, דומיין אחר וכדומה.

    השימוש ב-DNSSEC מוסיף רשומות נוספות. רשומות אלה נחוצות לתהליך האימות ולפעולת שרשרת האמון:

    RRSIG (ר”ת Resource Record Signature) – מכילה את החתימה המוצפנת (קריפטוגרפית) של ערכת רשומות נתונה. ערכת רשומות היא למעשה רשומות DNS מאותו סוג ובאותו השם, כלומר, משויכות לאותו דומיין.

    DNSKEY – מחזיקה במפתח ההצפנה הציבורי אשר מפענח את החתימה הקריפטוגרפית של רשומת RRSIG.

    DS (ר”ת Delegation Signer) – האצלת DNS, או DNS Delegation, היא מונח שמתרחש כאשר שרת אחד בהיררכיה מעביר את ה”אחריות” על אספקת המידע לקבוצת שרתים אחרת. לדוגמה, השרת האחראי על example.co.il יעביר את האחריות, בעת הצורך, לשרתים האחראיים על תת-דומיינים, בחיפוש האתר sales.example.co.il.
    רשומת DS מכילה הפניה לרשומת DNSKEY של השרת המאציל (“שרת הורה”). כלומר, השרת המאציל מחזיק במפתח ההצפנה הציבורי של השרת שהואצלה אליו האחריות (“שרת ילד”).

    אם אתם רוצים דימוי להמחשה, דמיינו הורה אשר מחזיק באישור כניסה למקום כלשהו, כאשר האישור תקף להורה ולילדיו. אם אחד הילדים רוצה להיכנס למקום המצריך את אישור הכניסה, הוא יפנה את האחראים להורה.
    לכן, שרתים מסוימים נקראים “שרתי הורה” (Parent DNS Server) ו-“שרתי ילד” (Child DNS Server). מונחים אלה לרוב מתייחסים לדומיינים ולתת-דומיינים המקושרים אליהם.

    NSEC3 / NSEC (ר”ת Next Secure) – כאשר שרת DNS מקבל בקשה להפניה באמצעות שם דומיין שאיננו קיים או אינו משויך לאף שרת, הוא מחזיר תשובה שלילית באמצעות רשומת NSEC או NSEC3.
    רשומות אלה נועדו לוודא באופן מאובטח שהדומיין אכן איננו קיים, ושלא “עובדים” על שרת ה-DNS (וכך גם על הגולש).

    CDS ו-CDNSKY – רשומות אלה נועדו להצביע על שינויים במצב המאובטח של שרת שורש איזורי. שינויים אלה כוללים בעיקר הפעלה/כיבוי של אבטחת פרוטוקול DNS, או תחלופה של המפתח הציבורי של השרת.

    מפתחות הצפנה

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

    ZSK – מפתחות הצפנה של שרת השורש האיזורי (Zone Signing Keys).

    לכל שרת שורש איזורי יש זוג מפתחות הצפנה – מפתח ציבורי ומפתח פרטי.
    המפתח הפרטי מצפין ערכת רשומות ספציפית המתאחסנת עליו. שרת השורש האיזורי מאחסן את רשומות המידע שהוא אמור לשלוח בתוך רשומות RRSIG, אשר מועברות לשרת ה-DNS. כך, למעשה, שרת השורש מראה לשרת ה-DNS כיצד נראה המידע שבידיו.
    המפתח הציבורי נועד לפענח את החתימה של שרת השורש. בבוא הזמן, יידע שרת ה-DNS כי המידע שבידיו אמיתי. המפתח הציבורי מופיע ברשומות ה-DNSKEY של שרת השורש.

    KSK – מפתח לחתימת מפתח (Key-Signing Key).

    שרת השורש האיזורי מחזיק ב-KSK ברשומת DNSKEY נוספת, ומאחסן את הנתון הזה כ RRSIG נוסף על שרת ה-DNS.
    ה-KSK הציבורי וה-ZSK הציבורי נחתמים באמצעות מפתח KSK פרטי, ולאחר מכן, שרת ה-DNS יכול לאמת את ה-ZSK הציבורי באמצעות ה-KSK הציבורי.

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

    איך DNSSEC עובד?

    1. הגולש מקליד את כתובת האתר (הדומיין) בשורת החיפוש בדפדפן. כלומר, הדפדפן שולח שאילתת DNS לשרת ה-DNS הקרוב.
    2. שרת ה-DNS, בהנחה שהוא אכן תומך בהרחבת SEC ושהמידע אינו מצוי במטמון שלו, שולח את השאילתה הלאה. הוא מציין בשאילתה שהתשובה צריכה להגיע כתשובה מאומתת ומאובטחת, ולא כתשובה רגילה.
    1. בהנחה שכל הגורמים בתהליך אכן תומכים ב-DNSSEC, תהליך האימות מתחיל. שרת השורש האיזורי מפנה את שרת ה-DNS לשרת ה-TLD הרלוונטי, ומספק לו את רשומת ה-DS של שרת ה-TLD. באמצעות רשומת ה-DS, שרת ה-DNS יודע ששרת ה-TLD מאובטח, כלומר, התשובה ממנו מאובטחת באמצעות הרחבת SEC.
    2. שרת ה-TLD מפנה את שרת ה-DNS לשרת השמות הסמכותני, יחד עם רשומת ה-DS של שרת השמות הסמכותני. שוב, בקבלת רשומת ה-DS של שרת השמות הסמכותני, יודע שרת ה-DNS כי התשובה ממנו אכן מאובטחת וניתנת לאימות.
    3. שרת ה-DNS מוודא כי מפתח ה-KSK של שרת ה-TLD תואם לזה שצוין ברשומת ה-DS שהתקבלה משרת השורש האיזורי. אם הם תואמים, סימן שהמידע משרת ה-TLD אמין.
    4. שרת ה-DNS שולח שאילתה לשרת השמות הסמכותני, אליו הופנה משרת ה-TLD. הוא מקבל ממנו את הרשומות הנחוצות להפניית הגולש, ואת רשומת ה- DNSKEY.
    5. התהליך חוזר על עצמו שוב: שרת ה-DNS משווה את ה-KSK שקיבל משרת השמות הסמכותני ל-DS שהתקבל משרת ה-TLD. אם השניים תואמים, ניתן לסמוך על המידע שהתקבל משרת השמות הסמכותני.
    6. שרת ה-DNS מחזיר את המידע המאומת לדפדפן, כלומר, לגולש.
    תרשים מתוך האתר של איגוד האינטרנט הישראלי, המתאר את אופן פעולתו של פרוטוקול DNSSEC.
    תיאור גרפי של תהליך האימות. מתוך האתר של איגוד האינטרנט הישראלי.

    קצת על חסרונות

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

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

    צריכת משאבים מוגברת:

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

    מורכבות:

    כפי שניתן להבין, מעצם ומאופן פעולתה, הרחבת האבטחה לפרוטוקול DNS מוסיפה המון מורכבות לתהליך. מפתחות הצפנה, רשומות, תחלופה, “התמסרות” בין השרתים, אימות – כל אלה מוסיפים מורכבות שבסופו של דבר משפיעה על זמן התקשורת, וגורעת מהפשטות היחסית של פרוטוקול DNS. כמו כל מערכת אבטחה, גם DNSSEC מוסיף “דלתות” שיש לפתוח כדי להגיע ליעד הנכסף – במקרה זה, כתובת ה-IP של השרת שהגולש מחפש.

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

    יותר עבודה:

    הגדרות, תחזוקה, חידוש מפתחות, פתרון תקלות – כל סוג של אבטחה מצריך תשומת לב נוספת מצד בעלי הדומיין/החברה המתחזקת אותו, ומצד בעלי שרתי הדומיין.

    לסיכום

    DNSSEC הוא מרכיב חשוב באבטחת סייבר. התפקיד שלו, בשורה התחתונה, הוא להגן על הגולשים ועל הלקוחות המשתמשים באתר או בשירות רשת כלשהו. הגנה זו מתבצעת באמצעות ווידוא כי המידע המתקבל בעת תשובה על שאילתת DNS, כלומר, בקשת הפניה לכתובת IP של שרת על פי הדומיין שלו, מאומת ואותנטי. אמנם תוספת האבטחה קצת מסבכת עניינים וקצת מעמיסה על כל מערכת DNS בה היא מתקיימת באופן מלא. אך בסופו של דבר, אנו מאמינים שכאשר מדובר באבטחת הגולשים ברשת האינטרנט, החסרונות שמגיעים עם האבטחה הם זניחים. אם אתם בעלי דומיין, ובמיוחד אם הדומיין מפנה לשירות אשר עוסק בפרטים אישיים או חשובים, אנו ממליצים לכם להפעיל את אופציית DNSSEC. מומלץ גם לוודא שספק ה-DNS שלכם אכן תומך באופציה זו.

    לבסוף, זכרו כי DNSSEC מגן נגד סוג מסוים וספציפי של התקפות, אך הוא לא מספיק על מנת לספק אבטחה שלמה ומקפת על הדומיין שלכם. פרוטוקול DNS, באופן כללי, הוא פרוטוקול פגיע ונטול הגנה, ומומלץ לבעלי דומיינים להתוודע לכל הסכנות הקיימות ולדרכים להתגונן בפניהן. רק כך, נוכל להגן הן על הגולשים והלקוחות שלנו והן על הנכסים שלנו, וכמובן – על עצמנו.

    אם רשמתם את הדומיין שלכם איתנו, אין לכם מה לדאוג – אנו מספקים אבטחת דומיינים, כולל תמיכה ב-DNSSEC. למעשה, איגוד האינטרנט הישראלי הקים מערך אבטחה תומך עוד בשנת 2016, כך שגם בעלי דומיינים ישראלים (co.il, org.il, gov.il וכו’) והגולשים אליהם יכולים להנות מאבטחה קצת יותר מוגברת.

    השותפים שלנו

    • js-partners-02
    • js-partners-03
    • nginx-js-partners-04
    • js-partners-06
    • mariadb-icon
    • docker-icon
    • nodejs
    Skip to content