שאלה לגבי נפילת שרת DNS

[ChaoscripT]

יש לי ראוטר Unifi UCG Fiber שאליו מחובר מחשב מיני PC עם דוקר ועליו Technitium DNS הוא בעצם עושה לי resolve לכל ה- DNS,
בשבת האחרונה הילד הקטן כיבה לי את המחשב ולא שמתי לב ונוצר מצב שלא היה אינטרנט בגלל זה,
עכשיו נוציא רק את הבעיה של המיקום של השרת שהילד לא יוכל לגשת, זה יטופל.
הבעיה העיקרית שלי היא שלא ידעתי שהשרת היה ״למטה״ ולכן לא העלתי בדעתי שבגלל לא היה אינטרנט.

האייפי הסטטי של השרת מוגדר כ- primary DNS בראוטר,
האם יש דרך ל:
1. שבמקרה שה- DNS נופל הראוטר עושה resolve בדרך אחרת? סוג של failover?
2. לדעת שהשרת לא באוויר, לדוגמא דגימה כל כמה דקות/שעה לאייפי או למשהו אחר?

תודה רבה.

[הרקולס]

תגדיר ב DHCP שרת DNS משני שהוא לא המחשב שלך...

[ChaoscripT]

תגדיר ב DHCP שרת DNS משני שהוא לא המחשב שלך...

...

אני יודע שיש את השדה הזה, איך אני יכול לוודא שאין ״זליגה״ כלשהי, זאת אומרת שאם ה- primary dns פעיל שיעבוד רק דרכו?
יש אופציה כזו?
כי בברירת המחדל אני רוצה שיעבוד לפי ה- primary ואם חלילה יש בעיה שיעבור ל secondary

[OMRIJ]

לא, זה לא יעבוד כfail over
הוא יעבוד משניהם וישתמש במהיר
תקין עוד קונטיינר במחשב נוסף ותשתמש בו כsecondery

[ChaoscripT]

לא, זה לא יעבוד כfail over
הוא יעבוד משניהם וישתמש במהיר
תקין עוד קונטיינר במחשב נוסף ותשתמש בו כsecondery

...

הכוונה במחשב שרת להקים?

[DanielGR]

אני יודע שיש את השדה הזה, איך אני יכול לוודא שאין ״זליגה״ כלשהי, זאת אומרת שאם ה- primary dns פעיל שיעבוד רק דרכו?
יש אופציה כזו?
כי בברירת המחדל אני רוצה שיעבוד לפי ה- primary ואם חלילה יש בעיה שיעבור ל secondary

...

לגבי הזליגה - ראה דוגמא איך זה מבוצע ב- Router OS, זה העיקרון, תיישם משהו דומה ב- UCG fiber:



דוגמא:
* כתובת הרשת היא 192.168.0.0/24
* שרת PiHole על 192.168.0.2
המטרה: שום Client ברשת לא יעקוף את ה- DNS Filter.

יישום: על ידי NAT באופן הבא:

קוד: בחירת הכל

/ip firewall nat
# Force Main LAN clients to use Pi-hole DNS (except whitelisted hosts)
add action=dst-nat chain=dstnat src-address=192.168.0.0/24 src-address-list=!dns-whitelist protocol=udp dst-port=53 to-addresses=192.168.0.2 comment="Force Main LAN DNS to Pi-hole UDP"
# Redirect DNS over TCP as well (except whitelisted hosts)
add action=dst-nat chain=dstnat src-address=192.168.0.0/24 src-address-list=!dns-whitelist protocol=tcp dst-port=53 to-addresses=192.168.0.2 comment="Force Main LAN DNS to Pi-hole TCP"

הסבר:
מוגדר DNS Whitelist שאלו המחשבים שמותר להם לצאת החוצה לכל DNS שהוא. במקרה הזה ה- Pihole חייב להיות כלול כי הוא צריך לצאת ל- Upstream שלו

חוקי ה- NAT אומרים כך: כל מחשב מכתובת הרשת הפנימית, ואיננו מהמורשים, בפרוטוקול TCP או UDP, ופורט 53 - DNS יעבור Redirect לכתובת של ה- PiHole.

סייגים: זה לא יחסום DNS מעל HTTPS

עריכה: אפשר גם לחסום לחלוטין את כתובות השרתי DNS הידועים לכל מי שאיננו ברשימת המורשים. ״ידועים״ הכוונה ל- 8.8.8.8 וכו׳

[TheCoolest]

אני הגדרתי את שרת ה-DHCP (יש לי ER-X-SFP) כך:
DNS1: 192.168.0.5
DNS2: 192.168.0.1
הראשון זה pihole והשני זה הראוטר עצמו, שיפענח מול ה-DNS של הספק.
אם ה-pihole נופל או יורד ל"תחזוקה" או עדכון, האינטרנט בבית ממשיך לעבוד רגיל - רק בלי לחסום פרסומות.

[DanielGR]

ולגבי ניטור host מסוים ברשת ואם הוא למטה - לשנות את חוקי ה- Firewall.

זה ממחיש היטב את פילוסופיית התכנון של Unify OS: מה שזמין ונגיש דרך הממשק הגראפי הוא מאד קל לתפעול ומאד פשוט. ומה שחורג מזה נהיה הרבה יותר מסובך אם בכלל אפשרי.

ב- Router OS קיימת פונקציה מובנית לבדוק האם Host מסוים חי, ומגיב ל- Ping. במידה וכן ניתן להריץ סקריפט מסוים, ובמידה ולא - סקריפט אחר, ובמסגרת הסקריפטים - לשנות באופן דינמי את הגדרות ה- NAT. באופן הזה נפילה של Host תטופל באופן אוטומטי לחלוטין, וגם ההתאוששות.

ב- UCG fiber אין משהו דומה, אבל מכיוון שUnify OS מבוססת על לינוקס סטנדרטי אז תיאורטית אפשר דרך Command line לכתוב Shell script שעושה את זה. לא מומלץ כי שינוי הגדרות ה- NAT שלא דרך הממשק הגראפי לא נשמרות כחלק מהקונפיגורציה, ובכלל לא בטוח שהתוצאות יהיו צפויות לחלוטין. שורה תחתונה: אפשר לנסות, לא נראה שכדאי.

[DanielGR]

אני הגדרתי את שרת ה-DHCP (יש לי ER-X-SFP) כך:
DNS1: 192.168.0.5
DNS2: 192.168.0.1
הראשון זה pihole והשני זה הראוטר עצמו, שיפענח מול ה-DNS של הספק.

...

התוצאה של התצורה הזו היא שבחלק מהזמן פירסומות לא ייחסמו בגלל שה- Name resolution יתבצע על ידי הספקית.
עריכה: כפי שציין @OMRIJ - זה לא Failover

עריכה: הבדיקה של הטיעון הזה היא פשוטה: אני מריץ שני שרתי PiHole המפורסמים ב-DHCP כראשי ומשני. כאשר שניהם למעלה מסתבר שמספר השאילתות מהמשני יותר נמוך מהראשי, אבל מאד רחוק מלהיות 0. אם מדובר היה במנגנון קשיח של Failover אז היו 0 שאילתות מהמשני כאשר שניהם למעלה.

[TheCoolest]

התוצאה של התצורה הזו היא שבחלק מהזמן פירסומות לא ייחסמו בגלל שה- Name resolution יתבצע על ידי הספקית.
עריכה: כפי שציין @OMRIJ - זה לא Failover
עריכה: הבדיקה של הטיעון הזה היא פשוטה: אני מריץ שני שרתי PiHole המפורסמים ב-DHCP כראשי ומשני. כאשר שניהם למעלה מסתבר שמספר השאילתות מהמשני יותר נמוך מהראשי, אבל מאד רחוק מלהיות 0. אם מדובר היה במנגנון קשיח של Failover אז היו 0 שאילתות מהמשני כאשר שניהם למעלה.

...

אתה צודק, אבל לרוב זה עובד דיי טוב.
אם יש לך המלצה לתצורה טובה יותר, מבלי להקים pihole על עוד מכונה, אשמח להכוונה.

[DanielGR]

אתה צודק, אבל לרוב זה עובד דיי טוב.
אם יש לך המלצה לתצורה טובה יותר, מבלי להקים pihole על עוד מכונה, אשמח להכוונה.

...

על מה רץ ה-PiHole אצלך?

[TheCoolest]

כרגע על SBC נפרד כדוקר קונטיינר.

[DanielGR]

אוקי. להריץ עוד קונטיינר על אותו SBC לא יעזור אם ה-Host יורד. כמינימום שבמינימום - בזמנו הרצתי PiHole על Raspberry pi zero2W שעלותו נמוכה מאד, ועבד היטב.

עלות: 85 שקלים בארץ וקופסה תעלה עוד כמה גרושים, ואולי גם משלוח.

https://piitel.co.il/shop/raspberry-pi-zero-2-w/

[Jabberwock]

אצלי אני לא רק חוסם פרסומות אלא גם פורנוגרפיה. לכן אני הכנסתי חוקים בחומת אש שלא יוכלו לעקוף.
כל העניין הזה של failover לא יעבוד טוב כי אין מה שיגדיר לך אם X נופל תפנה ל-Y. ב-DHCP אם אתה מגדיר יותר מ-DNS אחד אז המכשירים פונים לשניהם באופן אקראי או אפילו אם אחד לא עונה (בכוונה אתר חסום) אז הוא ינסה בשני וכן יקבל את האתר שאתה רוצה לחסום אותו.
אני מריץ AdGuard Home על Raspberry Pi 4. אם יש הפסקת חשמל הוא נדלק אוטומטית בחזרה. אין מצב "כבוי" כל עוד אני לא מתעסק איתו.
מסקנה, פשוט תוודא בביוס שלא יוכלו לכבות לך את המחשב.

[ChaoscripT]

אני אענה,
לא מעניין אותי שלא יהיה חוסם פרסומות באותו זמן שהשרת נפל, כן מעניין אותי שיהיה אינטרנט, בזמן שהשרת היה למטה פשוט לא היה גישה לאינטרנט בכלל, לא קשור לפרסומות או לא.
אז אני מבין בגדול שאין את האופציה ל failover טוב מבלי להריץ עוד איזה RPi או מחשב נוסף עם שרת DNS אחר,
אני יודע של Technitium יש אפשרות של HA (High availability) לא ניסיתי וגם לא יודע איך זה עובד כרגע.

[oferlaor]

אני מבין שאתה מריץ חוסם פרסומות בסגנון Pi-hole כ Primary DNS

שים ב-secondary בנתב OpenDNS שיש להם גם חסימת פרסומות. אני אישית לא השתמשתי בהם אז לא יודע להעיד אם הם טובים:

• AdGuard DNS: 94.140.14.14
• Control D (Ads & Trackers Filter): 76.76.2.1
• Mullvad DNS (Ad-blocking): 194.242.2.3

[ChaoscripT]

אני מבין שאתה מריץ חוסם פרסומות בסגנון Pi-hole כ Primary DNS
שים ב-secondary בנתב OpenDNS שיש להם גם חסימת פרסומות. אני אישית לא השתמשתי בהם אז לא יודע להעיד אם הם טובים:

• AdGuard DNS: 94.140.14.14
• Control D (Ads & Trackers Filter): 76.76.2.1
• Mullvad DNS (Ad-blocking): 194.242.2.3

...

אני מכיר את זה,
אבל כמו שאמרו ה- secondary dns הוא לא באמת failover אלא הראוטר ישתמש בשניהם מה שאני לא באמת רוצה ביום יום (כאשר הDNS שלי דלוק ולמעלה).

[TheCoolest]

אוקי. להריץ עוד קונטיינר על אותו SBC לא יעזור אם ה-Host יורד. כמינימום שבמינימום - בזמנו הרצתי PiHole על Raspberry pi zero2W שעלותו נמוכה מאד, ועבד היטב.
עלות: 85 שקלים בארץ וקופסה תעלה עוד כמה גרושים, ואולי גם משלוח.
https://piitel.co.il/shop/raspberry-pi-zero-2-w/

...

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

[ChaoscripT]

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

...

לפי מה שהבנתי ש ה- Technitium עם אפשרות Cluster עושה את זה כבר, את כל ה- sync לשרת אחר,
אבל מעניין לבדוק את זה.

[oferlaor]

עשיתי מחקרון כי זה נשמע לי מוזר ואכן יש התנהגות שונה בין מכשירים שונים ביחס ל-Secondary DNS

נראה שב-Windows זה משמש כ-fallback רק כשהראשי לא זמין
ב-Mac זה משמש כ-load balancer
בלינוקס זה בכלל sticky fallback כלומר, הוא לא יעבור חזרה ל-DNS הראשון כל עוד שהשני זמין עדיין...

הזיה.