רשומות DNSSEC

התוספות לפרוטוקול DNS ע"י DNSSEC הן:

• רשומות DNS חדשות
• הצהרות ב- DNS header ("דגלים" – flags, שלחלקם נתייחס בהמשך)

בעת ביצוע חתימת DNSSEC של דומיין, יתווספו אליו רשומות חדשות מסוג "מפתח", "חתימה" ועוד.. בפרק זה נפרט אודות רשומות אלה, ועל שאר הרשומות המתקבלות במימוש DNSSEC.
רשומות אלה הן כאמור חלק מפרוטוקול DNS התקני, והן מוכרות ע"י כל שרתי ה- DNS הידועים.
ולכן, בנוסף לרשומות הקלאסיות מסוג A, MX, NS, SOA, TXT וכו'.. דומיין חתום יכיל גם רשומות  DNSSEC כדלקמן:

רשומה מסוג DNSKEY (מפתח ציבורי)

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

• השדה הימני מכיל את המפתח הציבורי.
• שדה Algo מציין את מספר האלגוריתם הקריפטוגרפי. האלגוריתמים המקובלים הם RSA או Elliptic Curve שסימנם 8 ו- 13 בהתאמה
• שדה Flags הוא מספר שמייצג את סוג המפתח: ZSK = 256, KSK = 257

דומיין חתום יכיל שתי רשומות מסוג DNSKEY: אחת ZSK ואחת KSK

בדוגמא הנ"ל מוצג מפתח Elliptic curve מסוג ZSK של הדומיין co.il

רשומה מסוג RRSIG (חתימה)

רשומה זו מכילה את התוצר שהתקבל אחרי הפעלת מפתח, כלומר זוהי החתימה בפועל.
כפי שהוסבר קודם לכן חתימה ב- DNSSEC היא על רשומות, ולכן זוהי חתימה של רשומה כלשהי בדומיין (יוסבר איזו):

• השדה הימני מכיל את החתימה עצמה.
• שדה signer name הוא שם הדומיין שבו נמצא המפתח שיצר את החתימה
• שדה Key ID מציין את המזהה של המפתח שחתם (לכל מפתח יש מספר סידורי שמנוהל ע"י תוכנת החתימה)
• שדות sig create , sig exp מציגים את התוקף של החתימה. לפני ואחרי תאריכים אלה החתימה אינה תקפה (תוקף חתימה מוסבר בפרק המדיניות בעמ' 35)
• שדה orig TTL מציין את ה- TTL של הרשומה המקורית לפני שנחתמה
• שדה labels מציין את מספר הלייבלים המרכיבים את שם הדומיין (ב- il זה שניים)
• שדה Type signed מציין את סוג הרשומה המקורית שזאת החתימה שלה

בדוגמא הנ"ל מוצגת חתימה של רשומה מסוג NS אשר נחתמה ע"י מפתח מס' 47665
מסוג Elliptic curve, בדומיין co.il

הערה:

כאשר חותמים ב- DNSSEC על דומיין, החתימות הן כאמור של רשומות בדומיין. לכל רשומה בדומיין תהיה חתימה מתאימה.

נקודה זו יש לדייק:

למעשה, החתימה לא נעשית ממש על כל רשומה בנפרד, אלא על קבוצות של רשומות הקרויה: Resource record set = RRSET.

נסביר בעמוד הבא.

Resource Record Set – RRSET

קבוצת רשומות שהן מאותו סוג (אותו שדה TYPE), ויש להן אותו שם (אותו דומיין), ייחשבו RRSET אחד. לדוגמא, אם בדומיין example.com יש 3 רשומות MX אזי שלושתן יקובצו לאותו RRSET. כנ"ל רשומות מסוג NS של הדומיין, יקובצו ל- RRSET משלהן, וכו'

לעומת זאת אם בדומיין שלנו יש משהו כזה:

אזי שתי הרשומות האלה לא ישתייכו לאותו RRSET. אמנם שתיהן מסוג "A" אבל לכל אחת יש שם אחר (סאב דומיין אחר).

ולסיכום: פעולת חתימה של DNSSEC נעשית על RRSET ולא על כל רשומה בנפרד.
ייתכן ש- RRSET מכיל כמה רשומות וייתכן שרק רשומה אחת (למשל בדוגמא הנ"ל, כל A record יימצא ב- RRSET משלו).
בציור להלן מוצג בצד שמאל  zone "רגיל", לא חתום, שבו רשומת SOA, שתי רשומות מסוג A, שתי רשומות CNAME, שני MX ו-4 רשומות NS. כל ריבוע הוא RRSET.

לאחר הפעלת DNSSEC תתווסף רשומה מסוג RRSIG (חתימה), לכל RRSET (כל ריבוע), בנוסף ניתן לראות RRSET חדש שהוא שני המפתחות (שתי רשומות מסוג DNSKEY).
ל- zone שלנו התווספו אם כן 9 רשומות חדשות:

• 2 רשומות מסוג מפתח – DNSKEY (אחד ZSK ואחד KSK)
  
• 7 רשומות מסוג חתימה – RRSIG

רשומה מסוג DS

במבנה ההיררכי של DNS, הצבעה מרמה אחת בעץ לרמה שמתחתיה נקראת "דלגציה", והיא
נעשית באמצעות רשומות מסוג "NS".

רשומות NS תפקידן לפרסם מי הם שרתי ה-DNS של דומיין מוכל (זה ששמו מופיע בשדה השמאלי). לדוגמא, ב- org.il, הדלגציה ל- isoc.org.il תכיל למשל את הרשומה:

isoc.org.il.     86400    IN      NS      ns1.isoc.org.il.

כאן מוגדר ששרת DNS של דומיין isoc.org.il הוא ns1.isoc.org.il והמשמעות היא שיש לפנות אליו בשאילתות לגבי הדומיין הזה (זוהי דלגציה).

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

בדוגמא שלנו : באחריות הגורם המתפעל את הדומיין isoc.org.il להעביר DS למי שמתפעל את org.il.

כפי שהוסבר בעמודים 12 – 14, רשומת DS מכילה HASH (טביעת אצבע) של מפתח (KSK) שנמצא ברמה שמתחתיה, ויש משמעות גדולה לתקינותה, לקיומה או אי קיומה של הרשומה.

רשומת DS ללא KSK מתאים תכשיל את הדומיין החתום עד כדי עצירת השירות.

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

דוגמא לרשומת DS של דומיין isoc.org.il, כפי שהיא מופיעה ב- org.il

• השדה הימני מכיל את טביעת האצבע (HASH) של ה- KSK שאליו ה-DS מתייחס
• שדה Digest type מציין את סוג ה- HASH. התקן היום הוא SHA2
• שדה Algo מציין את האלגוריתם הקריפטוגרפי של ה-KSK שאליו מתייחסים
• שדה Child key tag מציין את המספר הסידורי של ה- KSK שאליו ה- DS מתייחס

רשומת ה- DS הנ"ל מתייחסת ל-KSK מספר 48693 מסוג elliptic curve של דומיין isoc.org.il.  הרשומה עצמה נמצאת ברמה שמעל – org.il

ייצור רשומת DS

רשומות DNSSEC נוצרות באופן אוטומטי ע"י תוכנת החתימה ומתווספות ל- zone file בעת ביצוע חתימה על דומיין. העיקרון הזה חל על כולן, פרט לרשומת DS.

רשומת DS יש לייצר עצמאית:  פעם אחת כאשר מפעילים DNSSEC לראשונה, ולאחר מכן בכל פעם שה- KSK מתחלף (דוגמאות יש בהמשך, ובעמ' 48, סעיף 6).

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

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

תהליך החלפת KSK מתבצע בשלבים:

• בשלב הראשון, לאחר הגלגול, שני ה-KSK, החדש והישן יתפרסמו זה לצד זה.
• עד שלא מתווספת לרמה שמעל, רשומת DS שמתאימה ל- KSK החדש, יש להמשיך לחתום עם ה- KSK הישן (כיוון שרק אותו ניתן לאמת!).
• לאחר שיצרנו רשומת DS שמתאימה ל- KSK החדש (בהמשך נראה כיצד), עלינו להעביר אותה לגורם המתפעל את רמת ה-DNS שמעל. את ה- DS של דומיין co.il יש להעביר לגורם המתפעל את co.il ובאופן דומה, את ה- DS של y.org.il ל- org.il.
• הגורם המתפעל את מרחבי השמות תחת IL (פרט ל- il ו- idf.il) הוא איגוד האינטרנט הישראלי . רשומות DS יש להעביר באמצעות הרשם המתפעל.
• יש לשים לב, כי בשלב ראשון פרסום ה- DS החדש הוא בנוסף ל- DS הישן, ולא במקומו!
• רק אחרי שעבר מספיק זמן (לא פחות מה- TTL של ה-DS, שהוא בד"כ יום) אפשר להורות לתוכנת החתימה להפסיק לחתום עם המפתח הישן, ולחתום רק עם החדש.
• אחרי פרק זמן נוסף (שוב, לפחות יום או TTL) שבמהלכו נבדק כי החתימה של ה- KSK החדש תקינה וניתנת לאימות, אפשר להורות לתוכנת החתימה למחוק את המפתח הישן.
  בסוף המסמך, בפרק "בדיקות" מוצגות אפשרויות של בדיקת DNSSEC
• רק אחרי שהמפתח הישן נמחק, יש להסיר את ה- DS הישן (שוב, ע"י פניה באמצעות הרשם המתפעל את הדומיין)

כיצד לייצר רשומת DS

1. דומיינים רבים מנוהלים אצל ספק DNS המאפשר ניהול עצמי באמצעות פורטל (למשל Wix, Cloudflare, Akamai, CloudDNS או ספקי ענן AWS, GCP וכו').
   במקרים אלה סט הפעולות הדרוש להפעלת DNSSEC הוא מצומצם וברוב המקרים כל שנדרש הוא לסמן למערכת לחתום DNSSEC, והשאר מתבצע באופן אוטומטי. יחד עם זאת, כפי שהוזכר קודם לכן, ייצור רשומת DS והעברה לרמה מעל היא באחריות לקוח הקצה או בא כוחו. לכן, בממשק הניהול, יש לבקש לייצר רשומת DS, ואת התוצר המתקבל (שורת טקסט) יש להעביר לרשם שדרכו נרשם הדומיין.
2. ניתן לייצר רשומת DS באמצעות פקודה: dnssec-dsfromkey שהיא חלק מסט הפקודות בחבילת "bind9-utils" של ISC (ניתנת להתקנה חינמית).
   את הפקודה אפשר להריץ במספר אופנים (יש לעיין בתיעוד). ניתן לייצר DS עפ"י המפתח שנשמר מקומית בשרת או לחילופין לפי המפתח הציבורי המתפרסם בעולם, כלומר ממש מתוך שאילתת DNS. לדוגמא:

שאילתת DNS באמצעות פקודת dig – המראה מהם המפתחות של דומיין isoc.org.il

dig dnskey isoc.org.il

257          3              13            0uIaVQeiX5wtvq9yEAiJjBI58qATI56NfG2+2 … yM/M32ve2H2RAP9w==

256          3              13            mW6EF30JCft2c1HXiyOOFzZ/wXPszXnIcCexM … T8NV9rWom45Hw59Q==

את הפלט של השאילתה הנ"ל ניתן להעביר ל- dnssec-dsfromkey ולקבל את ה- DS:

dig dnskey isoc.org.il | dnssec-dsfromkey -f – isoc.org.il

isoc.org.il. IN DS 27123 13 2 3FB17345C8B2DF51289DF7CE … BAF14B7EF98E0CD72946

1. ניתן לייצר רשומת DS באמצעות תוכנת החתימה, דוגמת OpenDNSsec, כפי שמתואר בעמ' 48, סעיף 6
2. ניתן לייצר רשומות DS בסקריפט פייתון, ועוד ועוד..

דוגמא 1:

כך נראית דלגציה מאובטחת בין שתי הרמות: org.il  ו-  isoc.org.il

ניתן לראות את רשומות ה- NS של isoc.org.il כפי שהן מופיעות ב- org.il (דלגציה רגילה) ובנוסף את רשומת ה- DS המתייחסת למפתח KSK ברמה שמתחתיה (דלגציה מאובטחת)

דוגמא 2

תיאור מנגנון האמון: הקשר בין המפתחות וה- DS דלגציה מאובטחת בין שתי רמות חתומות

בצד שמאל:  ה- zone החתום של org.il

• מכיל מפתח מסוג KSK שמספרו 40504, ומפתח מסוג ZSK שמספרו 47665
• שני המפתחות חתומים ע"י ה- KSK, מספר 40504
• רשומת DS מצביעה על KSK מס' 14406 של org.il (דלגציה מאובטחת)
• ה- DS, כמו כל רשומה אחרת, חתום גם הוא ע"י ה- ZSK של il

בצד ימין: ה- zone החתום של isoc.org.il

• מפתח מסוג KSK שמספרו 14406, ומפתח מסוג ZSK שמספרו 35955
• שני המפתחות חתומים ע"י ה- KSK, מספר 14406
• כל שאר הרשומות (כל RRSET) ב- org.il חתומות ע"י ZSK מס' 35955

בין מפתח והרשומה שעליה הוא חותם יש חץ מקווקו ⇠

חץ ירוק מראה את התוצר = החתימה המתקבלת

רשומה מסוג NSEC או NSEC3 (הוכחת אי קיום- proof of non existence)

מנגנון DNSSEC מאפשר להחזיר תשובה חתומה לשאילתת DNS. אולם זוהי פעולה המתאפשרת כאשר יש תוכן שעליו ניתן לחתום, כלומר כאשר יש תשובה לשאילתה.  נשאלת השאלה מה קורה כאשר התשובה שלילית?
ובמילים אחרות, כיצד אפשר להוכיח שמשהו לא קיים?
במבט ראשון נראה שאין בעיה. עפ"י פרוטוקול DNS, התשובה המוחזרת במקרה של דומיין לא קיים היא "NXDOMAIN", ולכן ב- DNSSEC פשוט נצרף לתשובה את החתימה של המחרוזת הזאת. לדוגמא:
נניח שהחתימה של  NXDOMAIN עפ"י המפתח שלנו היא: "==ABCDefgh123"
כעת, בכל פעם שנצטרך להחזיר תשובה שלילית, נחזיר את התשובה NXDOMAIN בצירוף החתימה הנ"ל. ואולם, בחינה נוספת מראה שדווקא יש בעיה.
נחזור כדוגמא ל- zone שלנו, "example.com"
 ונניח שיש בו 3 תת- דומיינים:
www.example.com
ftp.example.com
sub.example.com

שאילתה לגבי דומיין לא קיים, למשל: en.example.com תחזיר NXDOMAIN בצירוף  "==ABCDefgh123". החתימה הזו לגיטימית, ניתן לאמת שהיא אכן של NXDOMAIN.
ואולם,  גם שאילתה על דומיין אחר שאינו קיים ב- zone, למשל he.example.com
תחזיר גם היא את אותה תשובה בדיוק. וכאן הבעיה:  אותה תשובה מוחזרת לכל דומיין לא קיים. גורם זדוני שיש ביכולתו ליירט או לצוטט לתקשורת הזו, יוכל להזריק את התשובה הנ"ל גם בעבור שאילתות תקינות.
 כיוון שתמיד ניתן לאמת את התשובה הזו , ניתן למעשה לייצר מתקפת מניעת שירות על דומיין קיים – "Authenticated reply attack denial of service"
הפתרון של מנגנון DNSSEC לבעיה נקרא NSEC, (קיצור של Next Secure)
או NSEC3 שהוא וריאנט של NSEC ועליהם יוסבר להלן.

1)      רשומות NSEC

רשומות מסוג NSEC מתעדות את כל הדומיינים הקיימים ב- zone החתום.
כל רשומה כזאת מחזיקה שלושה נתונים:

• שמו של דומיין שאליו היא מתייחסת
• סוגי הרשומות שיש לאותו דומיין ב- zone המדובר (למשל A, SOA, MX, וכו')
  
• שמו של הדומיין הבא ב- zone, בסדר אלפביתי.

לדוגמא, כך ייראו רשומות NSEC ב-zone של example.com שהוצג קודם לכן:

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

כיצד זה פותר את בעיית אי הקיום?

כמו שניתן לראות בדוגמא, רשומות NSEC הן למעשה שרשור של שמות הדומיינים ב- zone, בסדר אלפביתי (האחרון מצביע שוב על הראשון). כאשר יש שאילתה לגבי דומיין לא קיים, למשל,
 מהי כתובת ה- IP של he.example.com ? שרת ה- DNS יחזיר כתשובה את רשומת ה-NSEC הבאה:

משמעות התשובה הזו היא: ביקשת את he.exmple.com אבל אין כזה דומיין.
יש ftp.example.com ואחריו את  sub.example.com  ביניהם אין שום דבר אחר. במילים אחרות, הדומיין  he.example.com לא קיים.  כמו כל רשומה, גם התשובה הזאת חתומה וניתנת לאימות.
באופן דומה, אם הלקוח ישאל האם יש רשומת MX לדומיין sub.example.com
התשובה שתוחזר תהיה:

ומשמעותה: הדומיין sub.exmaple.com קיים אבל יש לו רק רשומות מסוג DS, RRSIG ו- NS. אין MX.

בעיות:

תופעת לוואי של  NSEC היא יכולת של צד הלקוח לנחש מה התכולה של ה- zone.
תהליך שנקרא "zone walking" הוא ביצוע הרבה שאילתות, ובהתאם לתשובות ה- NSEC המתקבלות,  לצבור מספיק מידע המאפשר להרכיב תמונה מלאה של ה- zone.
על פניו זאת לא אמורה להיות בעיה כיוון שנתוני DNS הם כידוע מידע פומבי. יחד עם זאת תכולה של zone בכללותו היא במקרים רבים רגישה, ובעל המידע אינו מעוניין להנגישה לכל העולם. בעיה נוספת, רלווטית יותר למרחבי שמות גדולים מאוד, דוגמת co.il היא העובדה שלכל סאב דומיין, גם אם הוא לא חתום יש להצמיד רשומת NSEC. זה מגדיל את ה- zone. לא ניתן לעשות "opt-out" לדלגציות שאינן חתומות.

2)      רשומות NSEC3

כמו NSEC רק שבמקום לשמור ולהחזיר שמות אמיתיים של דומיינים, שומרים ומחזירים את ערך ה- HASH שלהם.
כזכור, Hash function ( פונקצית גיבוב) היא פונקציה חד כיוונית. היא מפעילה אלגוריתם שהתוצר שלו הוא ערך ייחודי לכל קלט שניתן לה.

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

מקובל היום אלגוריתם SHA2  אם כי גם SHA1 נמצא בשימוש במקרים מסוימים.

ב- NSEC3 מופעל SHA1 על שמות הדומיינים. התוצר הוא ערך שלא ניתן להסיק ממנו דבר על השם המקורי. שמות הדומיינים ב- example.com אחרי הפעלת פונ' SHA1 יראו כך:

 

Domain name	Hash value
example.com	97612fdad3f6b17f61d6912994b66ea7b7bacc99
ftp.example.com	268cf36e335c84c5b08310ef65471e66feda7349
sub.example.com	1fc71ee46c1fbf928fc30b0f2ae52463ee0fe3cb
www.example.com	b2e6b3cf1af3417e10ea73ab781c1dc687ed0c4b

ולכן,  בהתאם לרשימה הנ"ל, שרשרת NSEC3 תראה כך:

הפעם אין שמות אלא ערכי HASH. כמו כן המיון הוא בהתאם ל- HASH ולא לערך המקורי.

• השדה השמאלי הוא ה- HASH של הדומיין שאליו מתייחסים
• השדה החמישי משמאל מחזיק את הספרה 1 שמציינת כי הפונ' היא SHA1
• השדה השישי משמאל מציין האם יש opt-out לדלגציות שאינן חתומות. כלומר שלא תהיה רשומת NSEC3 עבור סאב-דומיין שאינו חתום (כפי שהוזכר לעיל, זה מיועד למרחב שמות גדול מאוד). 1 מציין שיש opt-out. ו- 0 שלא.
• השדה השביעי משמאל מחזיק ספרה המציינת כמה פעמים פונקצית ה- HASH תרוץ על הערך המקורי. פעם היה נהוג להפעיל מספר איטרציות של הפונקציה. למשל 10, ע"מ להקשות עוד יותר על נסיונות Dictionary attack. אולם הניסיון מלמד שזה לא רלוונטי, ומקשה על נסיונות האימות.
• השדה השלישי מימין מחזיק ערך "SALT" אם הוחלט לקיימו. זוהי מחרוזת (string) שניתן להוסיף לחישוב שמבצעת פונקצית HASH. גם זה נועד להקשות על Dictionary attack. בדוגמא מצויין "-" כלומר שאין SALT. לאחרונה הוחלט שתוספת זו מיותרת ויש לבטלה.
• השדה השני מימין הוא ה- HASH של הדומיין הבא
• השדה הימני הוא סוג הרשומות שיש לדומיין (כמו ב- NSEC רגיל)

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

רשומה מסוג NSEC3PARAM

מגדירה את הפרמטרים של NSEC3

• השדה השמאלי – שם הדומיין
• שדה Algo מציין את סוג ה- Hash function של NSEC3 נכון להיום זה רק SHA1
• שדה Flags מציין אם לעשות opt-out לדלגציות לא חתומות
• שדה Iterations מציין כמה פעמים פונקצית ה-HASH תרוץ על הערך המקורי
• שדה SALT מציין מהי התוספת שיש להוסיף ל- HASH

בדוגמה הנ"ל רשומת NSEC3PARAM של דומיין isoc.org.il מגדירה כי במימוש רשומת NSEC3 יש להתעלם מדלגציות לא חתומות (opt-out), לבצע 15 איטרציות של HASH ולהוסיף לחישוב ה- HASH את הערך 7AE165659C6281B26.

כאמור, מקובל כיום כי עדיף להשתמש ב- NSEC ולא ב- NSEC3.
אם הנסיבות מחייבות בכל זאת להשתמש ב- NSEC3 (למשל כאשר רוצים למנוע zone walking) אזי הפרמטרים שיש לקבוע ב- NSEC3PARAM הם:

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

מידע על שיקולים ניתן למצוא כאן:

https://kb.isc.org/docs/dnssec-signed-zones-best-practice-guidance-for-nsec3-iterations

וכאן:

https://www.ietf.org/archive/id/draft-ietf-dnsop-nsec3-guidance-02.html#name-recommendations-for-deployi

לסיכום, לאחר הפעלת DNSSEC, תכולת ה- zone החתום תראה כך:

• לכל RRSET יש חתימה = RRSIG.
• רשומות NSEC או NSEC3 אינן RRSET אחד. כל אחת נחתמת בנפרד. כזכור, כל רשומה כזו שייכת ל- sub domain אחר (שיוך רשומות לאותו RRSET מתרחש כאשר כולן אותו TYPE ואותו שם דומיין).
• אם יש NSEC3 אז קיימת גם NSEC3PARAM + חתימה שלה.
• ולבסוף אם יש דלגציה (הפניה ל- NS) ל-zone מתחתינו, שגם הוא חתום, אז יש להציב רשומת DS שמצביעה על ה- KSK שלהם. גם כאן, לכל דלגציה רשומת DS ייחודית (רשומות DS אינן RRSET אחד) ולידה החתימה.