מבוא
בסוף מאמר זה, עליך להבין טוב יותר את:
- מה זה DNS ומה הוא עושה
- מה שרתי DNS עושים
- כיצד פועלות כתובות פרוטוקול אינטרנט (IP) בהקשר של DNS
מושגים חשובים
ישנם כמה מודלים נפשיים חיוניים שכדאי להכיר כאשר לומדים על DNS, שרתי DNS וכתובות IP. עובר על מושגים אלה כעת, לפני שתתחיל ללמוד על DNS, יעשה זאת
- לעזור להבין את כל המונחים השונים המשמשים לתיאור התנהגות המשתלבת במודלים אלה, וכן
- סיוע בשמירת זיכרון.
מודלים נפשיים נותנים לך מסגרת התייחסות כאשר הדברים נעשים קצת מוזרים ולא מוכרים.
אז בואו נניח את היסודות.
- שאילתות ותגובות. זה כאשר דבר 1 מבקש מעניין 2 משהו, ועניין 2 נענה לבקשה זו. ככה:
- יחסי צומת הורים וילדים וגרפים שנראים כך (רק מסובך יותר).
- הודעות. זה לא שאילתה ותגובה מכיוון שאין תגובה. בעולם ה- DNS, העיצוב והתוכן של ההודעות משתנים בהתאם לשימוש.
- יחסי לקוח-שרת. במילים הפשוטות ביותר, שרת הוא תוכנה או התקן חומרה המספק פונקציונליות עבור תוכנות או התקני חומרה אחרים, הנקראים "לקוחות".
היכונו להרבה דיבורים על שרתים. כפי שמתברר, יש הרבה מאוד שרתים שנכנסים לדבר הזה שאנחנו מכנים DNS, ואיך אנחנו, כבני אדם, משתמשים בו כשאנחנו מתחברים לאינטרנט.
מה זה DNS?
מערכת שמות הדומיינים (DNS) ממפה שמות דומיינים הניתנים לקריאה אנושית (בכתובות אתרים או בכתובות דוא"ל) לכתובות IP. לדוגמה, DNS מתרגם וממפה את הדומיין freecodecamp.org לכתובת ה- IP 104.26.2.33.
כדי לעזור לך להבין היטב את התיאור הזה, חלק זה מפרט:
- הקשר היסטורי לפיתוח DNS - אילו בעיות פתרו כתובות ה- IP?
- שמות דומיינים
- כתובות IP
הקשר היסטורי
בשנת 1966, הסוכנות למחקר מתקדם למחקר (ARPA), סוכנות ממשלתית אמריקאית, הקימה רשת מחשבים בשם ARPAnet. במילים פשוטות, חשוב על ARPAnet כאיטרציה הראשונה של מה שאנו מכירים כיום כאינטרנט.
המטרות העיקריות של ARPAnet כללו
"(1) מתן תקשורת אמינה גם במקרה של ציוד חלקי או כשל ברשת, (2) יכולת להתחבר לסוגים שונים של מחשבים ומערכות הפעלה (3) להיות מאמץ שיתופי ולא למונופול הנשלט על ידי יחיד תַאֲגִיד. על מנת לספק תקשורת אמינה לנוכח כשל בציוד, ARPANET תוכנן כך שאף נקודה או קישור לא היו קריטיים יותר מכל האחרים. זה לווה בבניית מסלולים מיותרים ושימוש בניתוב מחדש של נתונים אם חלק כלשהו ברשת נכשל. "הבעיות
DNS ו- TCP / IP היו קריטיים לפתרון שתי בעיות עם ARPAnet:
עבור ARPAnet, היה מיקום יחיד (קובץ בשם HOSTS.TXT) שהכיל את כל מיפוי השם לכתובת עבור כל מארח ברשת.
"HOSTS.TXT הוחזק על ידי מרכז המידע ברשת של SRI (המכונה" ה- NIC ") והופץ ממארח יחיד, SRI-NIC. [*] מנהלי ARPAnet שלחו בדרך כלל בדוא"ל את השינויים שלהם ב- NIC, ומדי פעם FTP הועברו ל- SRI- NIC ותפס את הקובץ הנוכחי HOSTS.TXT. השינויים שלהם נערכו לקובץ HOSTS.TXT חדש פעם או פעמיים בשבוע. "במערך זה היו שלושה אתגרים:
- תנועה ועומס - הפצת הקובץ נהיה יותר מדי לטפל במארח האחראי.
- התנגשויות שם - לכל מארח היה צריך להיות שם ייחודי, ולא הייתה שום סמכות ריכוזית שמנעה ממשתמשי הרשת להוסיף מארח עם שם סותר (לא ייחודי) ובכך "לשבור את כל התוכנית."
- עקביות - פעולת עדכון הקובץ והבטחת כל המארחים בגירסה המעודכנת ביותר הפכה לבלתי אפשרית או לפחות קשה מאוד.
בעיקרו של דבר, HOSTS.TX היווה נקודת כישלון אחת, ולכן התהליך כולו כאן לא התרחש מעבר למספר מסוים של מארחים. ARPAnet נזקקה לפיתרון מבוזר וניתן להרחבה. DNS היה זה. מָקוֹר
תקשורת מארח למארח באותה רשת לא הייתה אמינה מספיק. TCP / IP עזר לפתור בעיה זו.
- פרוטוקול בקרת השידור (TCP) מספק אמצעי אבטחת איכות לתהליך הפיכת מסרים (בין מארחים) לחבילות. פרוטוקול TCP מכוון לחיבור, כלומר יש ליצור קשר בין מארח המקור למארח היעד.
- פרוטוקול האינטרנט (IP) מגדיר כיצד הודעות (מנות) מועברות בין מארח המקור למארח היעד. כתובת IP היא מזהה ייחודי לנתיב ספציפי שמוביל למארח ברשת.
- TCP ו- IP עובדים יחד הדוקים, ולכן בדרך כלל מכנים אותם כמו "TCP / IP".
- אמנם לא אצלול אליו במאמר זה, הן TCP והן פרוטוקול Datagram User (UDP) משמשים בשכבת הובלת הנתונים של DNS. UDP מהיר יותר, הרבה פחות אמין ואינו דורש חיבורים; TCP איטי יותר, הרבה יותר אמין, אך זקוק לחיבורים. הם משמשים לפי הצורך והמתאים ב- DNS; למותר לציין שהכללת TCP ב- APRAnet הייתה תוספת חשובה לשכבת הובלת הנתונים.
בתחילת שנות השמונים, DNS ו- TCP / IP (ולכן, כתובות IP) היו נהלי הפעלה סטנדרטיים עבור ה- ARPAnet.
ההיסטוריה הזו מקוצרת מאוד . אם ברצונך ללמוד עוד על נושאים אלה, עיין בסעיף משאבים בסוף מאמר זה.
כעת, כשיש לנו הקשר היסטורי כלשהו, נעבור ללמוד עוד על שמות דומיינים וכתובות IP.
שמות דומיינים
בהקשר של DNS, שם דומיין מספק דרך ידידותית למשתמש להצביע על משאבים שאינם מקומיים. זה יכול להיות אתר אינטרנט, מערכת דואר, שרת הדפסה או כל שרת אחר הזמין באינטרנט. שם דומיין יכול להיות יותר מסתם אתר!
"המטרה של שמות דומיינים היא לספק מנגנון למתן שמות למשאבים באופן שהשמות ישמשו במארחים שונים, רשתות, משפחות פרוטוקולים, רשתות אינטרנט וארגונים מנהליים."הרבה יותר קל לזכור שם דומיין ולהיכנס למסוף או לדפדפן אינטרנט מאשר לכתובת IP.
שם תחום הוא חלק מאיתור משאבים אחיד (URL), אך המונחים אינם שם נרדף . כתובת אתר היא כתובת האינטרנט המלאה של משאב, ואילו שם הדומיין הוא שם אתר והוא רכיב משנה של כל כתובת אתר.
אמנם יש הבחנות טכניות בין כתובות אתרים ושמות דומיינים, אך דפדפני האינטרנט בדרך כלל מתייחסים אליהם באותה צורה, כך שתגיע לאתר אם תקליד את כתובת האינטרנט המלאה, או רק את שם הדומיין.
תחומים ברמה העליונה ותחומים בדרגה שנייה
ישנם שני חלקים לכל תחום נתון: תחום ברמה העליונה (TLD) ודומיין ברמה שנייה (SLD). החלקים של שם דומיין הופכים ספציפיים יותר כאשר עוברים מימין (סוף) לשמאל (התחלה).
זה יכול להיות מבלבל בהתחלה. לדוגמה, בואו נסתכל על "freecodecamp.org"
- כתובת אתר: //www.freecodecamp.org
- שם דומיין: freecodecamp.com
- TLD: org
- SLD: מחנה חופשי
בימים הראשונים של ARPAnet, היה מספר מוגבל של TLD זמין, כולל תחומי קוד מדינה, com, edu, gov, org, arpa, mil ו- 2 אותיות. בתחילה שמורות TLD אלה שמורות למוסדות המשתתפים ב- ARPAnet, אך חלקן מאוחר יותר זמינות בשווקים מסחריים.
כיום יש עושר השוואתי של TLDs זמינים, כולל רשת, aero, biz, לול, מידע, מוזיאון, שם ואחרים.
דומיינים בדרגה שנייה הם הדומיינים שזמינים לרכישה פרטנית דרך רשמי הדומיין (למשל Namecheap).
כתובות IP
בעוד שכתובות IP קשורות ל- DNS בתפקודן, פרוטוקול האינטרנט עצמו נפרד מבחינה טכנית מ- DNS. כבר סיפקתי הקשר היסטורי להבחנה זו, אז עכשיו אסביר כיצד כתובות IP מתפקדות.
כתובת IP, כאמור, היא מזהה ייחודי לנתיב ספציפי שמוביל למארח ברשת. ברצוני להתייחס לאנלוגיה של מספר טלפון וטלפון: מספר טלפון אינו מייצג את הטלפון עצמו, זו פשוט דרך להגיע לאדם עם הטלפון.
אנלוגיה זו מתאימה באופן סביר (לפחות, במשטח), עם כתובות IP. כתובת IP מייצגת נקודת קצה, אך היא אינה נקודת הקצה עצמה. מטלות IP יכולות להיות קבועות (קבועות) או דינמיות (גמישות וניתן להקצותן מחדש).
כמו שם דומיין, ארגון כתובות ה- IP עוקב אחר מבנה היררכי. בשונה משמות דומיינים, כתובות IP נהיות ספציפיות יותר משמאל לימין. זו דוגמה של IPv4 להלן:
- רשת: המספר הייחודי שהוקצה לרשת שלך
- מארח: מזהה את המארח (המכונה) ברשת
אם יש צורך בספציפיות רבה יותר, מנהלי רשת יכולים לרשת משנה את שטח הכתובת ולהאציל מספרים נוספים.
כמה כתובות IP יש?
IPv4 היה האיטרציה הראשונה של ה- IP ששימשה ARPAnet בייצור. התפרס בתחילת שנות ה -80, זו עדיין גרסת ה- IP הנפוצה ביותר. זוהי תוכנית של 32 סיביות, ולכן יכולה לתמוך במעט יותר מ -4 מיליארד כתובות.
אבל רגע, זה מספיק? לא.
ל- IPv6 יש תוכנית של 128 סיביות, המאפשרת לו לתמוך ב -340 כתובות לא-מיליונים. הוא מציע גם שיפורי ביצועים ב- IPv4.
כתובת IPv4 לדוגמא:
- 104.26.2.33 (freeCodeCamp)
כתובת IPv6 לדוגמא:
- 2001: db8: a0b: 12f0 :: 1 (הפורמט הדחוס ולא מצביע על freeCodeCamp)
כיצד פועלת מערכת שמות הדומיינים?
אז למדנו על שמות דומיינים! למדנו על כתובות IP! עכשיו איך הם קשורים למערכת שמות הדומיינים?
קודם כל, הם משתלבים במרחב השמות.
מרחב שמות הדומיין
כמשתמע משפת התחום ברמה העליונה ובדומיין ברמה השנייה, מרחב השמות מבוסס על היררכיה
"... כאשר ההיררכיה תואמת בערך למבנה הארגוני, ושמות באמצעות". " כדמות לסימון הגבול בין רמות היררכיה. " מָקוֹר.גרף עץ זה, עם השורש בחלקו העליון, ממחיש בצורה הטובה ביותר את המבנה:
בואו נפרק את זה, נתחיל מלמעלה.
החלק העליון של התרשים הזה מצוין בסימן "." נקרא "השורש".
"שרתי השמות הסמכותיים המשרתים את אזור הבסיס של ה- DNS, הידוע בכינויו" שרתי השורש ", הם רשת של מאות שרתים במדינות רבות ברחבי העולם. הם מוגדרים באזור שורש ה- DNS כ -13 רשויות בעלות שם. "לדומיין הבסיס יש תווית באורך אפס.
מכאן ואילך, לכל צומת (נקודה) בגרף יש תווית ייחודית באורך של עד 63 תווים.
הרמה הראשונה מהשורש היא ה- TLD: com, org, edu ו- gov. לידיעתך, גרף זה אינו מכיל רשימה מלאה של TLD.
מתחת ל- TLD נמצאים ה- SLD, התחומים בדרגה השנייה. הילדים של כל צומת נקראים "תת-דומיינים", שעדיין נחשבים כחלק מתחום האב. לדוגמה, ב- freecodecamp.org, freecodecamp (SLD) הוא תת-תחום של org (ה- TLD).
בהתאם להיררכיה של האתר, עשויים להיות תחומים שלישית, רביעית, חמישית. לדוגמה, ב- hypothetical-subdomain.freecodecamp.org, תת-תחום היפותטי הוא התחום ברמה השלישית, ותת-הדומיין של freecodecamp. הלאה וכן הלאה, לפחות עד 127 רמות, שזה המקסימום המותר על ידי DNS.
מי מנהל את מרחב השמות?
האם לא יהיה זה אגוז לנסות לגרום לאדם או ארגון אחד לנהל הכל? כן זה יהיה. במיוחד מכיוון שאחת ממטרות התכנון העיקריות של DNS הייתה קידום ניהול מבוזר ומבוזר של המערכת כולה.
הלוואי שיכולתי לומר לך שהאחראים נקראים "מלכי השמות", אבל אבוי.
כל דומיין (או תת-דומיין) במרחב שמות הדומיינים הוא או הוא חלק מאזור , "חלק המנוהל באופן אוטונומי ממרחב השמות." אז מרחב השמות מחולק לאזורים.
האחריות לאותם אזורים מנוהלת באמצעות האצלה ומינהל.
תהליך הקצאת האחריות של תת-דומיינים לגופים אחרים נקרא משלחת.
לדוגמה, רישום האינטרסים הציבוריים מנהל את שם הדומיין org, והוא קיים מאז 2003. רישום האינטרסים הציבוריים עשוי להאציל אחריות לגורמים אחרים לניהול תת-דומיינים של הארגון, אומרים freecodecamp. ואז מי שמנהל freecodecamp רשאי להקצות אחריות לתת-דומיינים של freecodecamp (למשל, hypothetical-subdomain.freecodecamp.com) לצד אחר.
אם מישהו (ארגון, צוות או יחיד) מנהל אזור, מה שהם עושים הוא לנהל את שרת השמות שאחראי על האזור.
זה מביא אותנו לאחד המושגים הבסיסיים ביותר במערכת שמות הדומיינים.
שרתי שמות מתחם
"התוכניות המאחסנות מידע על מרחב שמות הדומיין נקראות שרתי שמות."בשלב זה המקום לחשוב על יחסי לקוח-שרת, לפחות בהתחלה, מועיל. שרתי שמות דומיינים הם הצד ה"שרת "ביחסי לקוח-שרת. שרת שמות עשוי לטעון אזור, מאות או אפילו אלפי אזורים, אך הם לעולם לא טוענים את כל מרחב השמות. ברגע ששרת שמות נטען את מכלול האזור, נאמר שהוא סמכותי לאזור זה.
כדי להבין מדוע שרתי שמות מתפקדים כפי שהם פועלים, כדאי להבין את החלק ה"לקוח "במערכת היחסים.
מחליטים
ב- DNS, הלקוח (מבקש המידע) נקרא "פותר", שנראה אולי אחורי בהתחלה. האם השרת הפותר את הבקשה לא ייקרא "הפותר?" גם אני חשבתי, אבל זה לא. הכי טוב פשוט לשנן את זה ולעבור הלאה.
בדרך כלל נכללים ברזולוציות, למעשה, ברוב מערכות ההפעלה, כך שהיישומים המותקנים במערכת ההפעלה אינם צריכים להבין כיצד לבצע שאילתות DNS ברמה נמוכה.
שאילתות DNS ותגובותיהן הן סוגים של הודעות DNS, ויש להן פרוטוקול העברת נתונים משלהן (בדרך כלל UDP). המתמודדים אחראים לסייע ליישומים המותקנים במערכת ההפעלה לתרגם בקשות לנתונים הקשורים ל- DNS לשאילתות DNS.
לסיכום, הרזולוציות אחראיות על האריזה ושליחת בקשות הנתונים. ברגע שהפתרון מקבל את התגובה (אם בכלל), הוא מעביר את זה ליישום המבקש המקורי בפורמט מתכלה ליישום המבקש.
חזרה לשרת שמות
כעת, כאשר אנו מכירים מעט יותר את צד הלקוח של הקשר, עלינו להבין כיצד מגיבים שמות דומיינים לשאילתות רזולוציות.
שרת שמות מגיב לשאילתות DNS באמצעות רזולוציה . רזולוציה היא התהליך שבו שרתי שמות מוצאים קבצי נתונים במרחב השמות. תלוי בסוג השאילתה, שרת שמות מגיב באופן שונה לשאילתות שונות, אך המטרה הסופית היא רזולוציה.
סוגי שאילתות
סוג השאילתה? כן, ישנם מספר סוגים של שאילתות DNS. אבל ראשית, מה בדרך כלל בשאילתת DNS? זו בקשה למידע, במיוחד עבור כתובת ה- IP המשויכת לשם דומיין.
- רקורסיבי : שאילתות רקורסיביות מאפשרות להפנות את השאילתה למספר שמות שמות. אם לשרת השמות השאילתי הראשון אין את הנתונים הרצויים, שרת השמות הזה שולח את השאילתה לשרת השמות הבא המתאים ביותר, עד שיימצא שרת השמות עם קובצי הנתונים הרצויים ושולח תגובה לפותר.
- איטרטיבי : שאילתות איטרטיביות מחייבות את שרת השמות שאילתה להגיב עם הנתונים הרצויים או עם שגיאה. התגובה עשויה להכיל את כתובת ה- IP של שרת השמות המתאים ביותר לשלוח את הבקשה להבא; לאחר מכן רשאי הפותר לשלוח בקשה נוספת לשרת השמות המתאים יותר.
במקרה שאתה זקוק לו, תוכל גם לשאול על שם התחום, אם כל מה שיש לך הוא כתובת ה- IP. זה נקרא בדיקת DNS הפוכה.
לאחר שהשאילתה מגיעה לשרת שמות המכיל את קובצי הנתונים הרצויים, ניתן לפתור את השאילתה. לשרתים של שמות יש מספר קבצי נתונים המשויכים אליהם, אשר כולם או חלקם עשויים לשמש לפתרון השאילתה.
רשומות משאבים (RRs)
אלה קבצי הנתונים במרחב שמות הדומיינים. לקבצי נתונים אלה יש פורמטים ותכנים ספציפיים.
שיעורי ה- RR הנפוצים ביותר:
- שיא: אם לא שמעתם על אף RR אחר למעט זה, זה יהיה הגיוני. זה ככל הנראה ה- RR הידוע ביותר ומכיל את כתובת ה- IP של התחום הנתון.
- שיא CNAME: אם לא שמעתם על עוד RRs פרט לזה ולתקליט ה- A, זה גם הגיוני. ה- "C" מייצג "קנוני", ומשמש במקום רשומת A, להקצאת כינוי לדומיין.
- רשומת SOA: רשומה זו מכילה מידע מנהלי אודות זה, כולל כתובת הדוא"ל של המנהל. רמז: אם אתה מנהל אזור, ודא שיש כאן כתובת דוא"ל תקפה, כך שאנשים יוכלו ליצור איתך קשר במידת הצורך.
- סוגים חשובים נוספים של שיא משאבים (RR) הם PR, NS, SRV ו- MX. קרא עליהם כאן.
אחסון במטמון וזמן חי (TTL)
כאשר שרת השמות המקומי מקבל תשובה משאילתה, הוא שומר במטמון את הנתונים האלה (שומר אותם בזיכרון), כך שבפעם הבאה שהוא יקבל את אותה השאילתה, הוא יכול פשוט לענות על השאילתה ישירות במקום לעבור על תהליך הרזולוציה המקורי והארוך יותר.
אך ברגע שמידע זה נשמר במטמון, הוא סטטי ומבודד כאחד, ולכן הוא נמצא בסיכון להתאושש. לכן, לרשומות המשאבים יש את מה שמכונה זמן לחיות (TTL), שמכתיב כמה זמן ניתן לשמור את הנתונים האלה. כאשר הזמן הזה נגמר (מגיע לאפס), שרת השמות מוחק את הרשומה.
הערה חשובה: TTL אינו חל על שרתי השמות המוסמכים לאזור המכיל את רשומת המשאבים. זה חל רק על שרת השמות ששמר במטמון את רשומת המשאבים הזו.
יום בחיי שאילתה
במאמר זה כיסינו הרבה אדמות וזה היה כבד על המושגים. כדי לקשור את כל זה ולהפוך אותו לממשי, הנה יום (יום פיגורטיבי) בחיי השאילתה.
אז למה אני צריך לדעת את כל זה?
יש כל כך הרבה סיבות להכיר מושגים הקשורים ל- DNS וכתובת IP.
- ראשית, זהו עמוד השדרה של האינטרנט, הדבר שרבים מאיתנו משתמשים בו, מפתחים רגשות כלפיו (אוהבים / שונאים / אתה שם את זה), ומקבלים כמובן מאליו כל יום. חשוב להכיר את המבנים המאפשרים לנו להשיג דברים גדולים היום עם הטכנולוגיה והאינטרנט כיום.
- אנשים חכמים להפליא בילו עשרות שנים מחייהם בבניית הדברים האלה! בואו נודה ונעריך את תרומתם.
- כעת, לאחר שהדבר הוצאתי מהכלים החשוב, חשוב להכיר מושגי DNS למקרה שאתה אחראי לכל מה שקשור לתשתיות בחברה שלך או בצוות שלך או בעסק שלך. מסגרת התייחסות כשנושאים משמעותיים צצים מאפשרת לך לפעול הרבה יותר מהר ולמצוא פתרונות הרבה יותר מוקדם.
סיכום
בשלב זה עליכם להבין מהו DNS ומהו שרת שמות, וכן להכיר מושגים טכניים הנוגעים לכתובות IP.
ספרים רבים נכתבו וצללו עמוק יותר בעולם המרתק של ה- DNS, ויש עוד כל כך הרבה מה ללמוד. הנושאים שלא נכללו במאמר זה, אך הם חלק מ- DNS או קשורים מאוד כוללים:
- יישומי שרת שמות
- העברה
- (עוד אודות) תוויות צומת
- יחסי שרת שמות ראשוניים ומשניים
- אלגוריתמי שידור חוזר
- איזון עומסים
- בנוסף, נושאים כלליים נוספים על אופן פעולת האינטרנט, כמו:
- אינטרנט
- HTTP
- FTP
- שכבות פרוטוקול תקשורת: שכבת קישור, שכבת IP, שכבת תחבורה, שכבת אינטרנט וכו '.
לאלו מכם שעדיין קוראים ורוצה ללמוד עוד על DNS, אני קודם כל ממליץ על "DNS ו- BIND, 5th Ed.", שנכתב על ידי קריקט ליו ופורסם על ידי O'Reilly Media. זה לא יסולא בפז.
אני גם ממליץ לכולם להתעסק בבקשה המקורית להערות (RFC) המקושרות למטה. לא רק שיש נקודות לקריאת מקורות ראשוניים, אלא שהם גם מסמכים מאורגנים ומובנים במיוחד, ולכן ציטטתי אותם במאמר זה.
אֶמְצָעִי
- RFC 1034: שמות דומיינים - מושגים ומתקנים
- RFC 1035: שמות דומיינים - יישום ומפרט
- RFC 1122: דרישות עבור מארחי אינטרנט - שכבות תקשורת
- עוד על מטרות עיצוב DNS, מתוך Connected: אנציקלופדיה אינטרנטית
- איך נולד האינטרנט מה- ARPAnet לפרשנות, מתוך השיחה
- לימוד קורס וידיאו DNS, מאת קריקט ליו, מאת אוריילי מדיה
קצת עלי
אני קלואי טאקר, אמנית ומפתחת בפורטלנד, אורגון. כמחנך לשעבר, אני מחפש ללא הרף את צומת הלמידה וההוראה, או טכנולוגיה ואמנות. פנה אלי בטוויטר @_chloetucker ובדוק באתר שלי בכתובת chloe.dev.