ماذا يحدث عند تحديث DNS الخاص بك

Fenix ​​by Takeda11 يشعر



الكثير من الناس بالارتباك بشأن تحديث سجلات DNS عندما يغيرون عنوان IP الخاص بموقعهم . لماذا يتم تحديث هذه السجلات ببطء؟ هل تحتاج حقًا إلى الانتظار يومين حتى يتم تحديث كل شيء؟ لماذا يرى بعض الزائرين عنوان IP الجديد بينما يرى الآخرون العنوان القديم؟



قام فريق Mail.ru Cloud Solutions بترجمة مقال كتبه المطور ومؤلف المقالات Julia Evans ، حيث أجابت على هذه الأسئلة وأخبرت بشكل عام ما يحدث أثناء تحديث DNS من منظور الواجهة الأمامية.



إليك استكشاف سريع لما يحدث خلف الكواليس عند تحديث سجل DNS.

كيف يعمل DNS: خوادم DNS التكرارية والمعتمدة

أولاً ، نحتاج إلى توضيح القليل عن نظام DNS. هناك نوعان من خوادم DNS: موثوقة و متكررة .



حجية خوادم DNS (المعروف أيضا باسم خوادم الأسماء ) الحفاظ على قاعدة بيانات لعناوين IP لكل مجال أنها هي المسؤولة عن. على سبيل المثال ، الآن خادم DNS الموثوق لـ github.com هو ns-421.awsdns-52.com. يمكنك أن تطلب منه عنوان IP الخاص بـ github.com مع هذا الطلب:

dig @ns-421.awsdns-52.com github.com

لا تعرف خوادم DNS التكرارية في حد ذاتها أي شيء عن من يمتلك أي عنوان IP. يقومون بحساب عنوان IP لمجال من خلال الاستعلام عنه من خوادم DNS الرسمية المناسبة ثم تخزين عنوان IP هذا في حالة مطالبتهم به مرة أخرى. لذا فإن 8.8.8.8 هو خادم DNS تكراري.



عندما يزور الأشخاص موقع الويب الخاص بك ، فمن المحتمل أنهم يجرون عمليات بحث عن DNS لخادم DNS تكراري. إذن كيف تعمل خوادم DNS التكرارية؟ دعنا نلقي نظرة!

كيف يستعلم خادم DNS التكراري عن عنوان IP الخاص بـ github.com

دعونا نرى مثالاً لما يفعله خادم DNS التكراري (على سبيل المثال 8.8.8.8) عندما تطلب منه عنوان IP (سجل A) لـ github.com. أولاً ، إذا كانت تحتوي بالفعل على نتيجة مخزنة مؤقتًا ، فستصدرها. ولكن ماذا لو انتهت صلاحية جميع ذاكرات التخزين المؤقت؟ إليك ما يحدث.



الخطوة 1 : عناوين IP لخوادم DNS الجذر مشفرة بشكل ثابت في كود المصدر الخاص بها. يمكنك أن ترى هذا في شفرة المصدر غير منضم . لنفترض أنه اختار 198.41.0.4 للبدء بها. هذا هو المصدر الرسمي لعناوين IP المشفرة ، والمعروفة أيضًا باسم "ملف تلميحات الجذر".



الخطوة 2 : اسأل خوادم أسماء الجذر عن github.com.



يمكننا إعادة إنتاج ما يحدث للأمر تقريبًاdig... يعطينا خادم أسماء .comموثوقًا جديدًا للاستعلام: خادم أسماء بعنوان IP هو 192.5.6.30.

$ dig @198.41.0.4 github.com
...
com.			172800	IN	NS	a.gtld-servers.net.
...
a.gtld-servers.net.	172800	IN	A	192.5.6.30
...

تفاصيل استجابة DNS أكثر تعقيدًا بعض الشيء - في هذه الحالة يوجد قسم استناد به بعض سجلات NS وقسم إضافي به سجلات A ، لذلك لا يتعين عليك إجراء بحث إضافي للحصول على عناوين IP لخوادم الأسماء هذه.



من الناحية العملية ، سيكون هناك بالفعل عنوان خادم أسماء مؤقتًا في 99.99٪ من الوقت .com، لكننا نتظاهر بأننا نبدأ بالفعل من نقطة الصفر.



الخطوة 3 : اسأل خوادم الأسماء .comعن github.com.

$ dig @192.5.6.30 github.com
...
github.com.		172800	IN	NS	ns-421.awsdns-52.com.
ns-421.awsdns-52.com.	172800	IN	A	205.251.193.165
...

لدينا عنوان IP جديد لإرسال الطلب! هذا أحد خوادم أسماء github.com.



الخطوة 4 : اسأل خوادم أسماء github.com عن عنوان github.com.



نحن على وشك الانتهاء!

$ dig @205.251.193.165 github.com

github.com.		60	IN	A	140.82.112.4

لذلك لدينا سجل A لـ github.com. يحتوي الخادم التكراري الآن على عنوان IP الخاص بـ github.com ويمكنه إعادته إليك. وقد تمكن من متابعة العملية بأكملها ، بدءًا من عدد قليل من عناوين IP المشفرة: عناوين خوادم اسم الجذر.

كيف ترى كل خطوات خادم DNS التكراري: dig + trace

لمعرفة ما سيفعله خادم DNS التكراري لحل المجال ، يمكنك تشغيل:

$ dig @8.8.8.8 +trace github.com

يعرض هذا الأمر جميع سجلات DNS التي يطلبها الخادم التكراري ، بدءًا من خوادم DNS الجذرية ، وهي جميع الخطوات الأربع التي مررنا بها للتو.

تحديث سجلات DNS

الآن بعد أن عرفنا أساسيات كيفية عمل DNS ، دعنا نحدث بعض سجلات DNS ونرى ما سيحدث.



عند تحديث سجلات DNS ، هناك خياران رئيسيان:

1. الاحتفاظ بخوادم الأسماء نفسها ؛
2. تغيير خوادم الأسماء.

لنتحدث عن TTL

لكننا نسينا شيئًا مهمًا. هذا هو TTL. كما قلنا سابقًا ، سيقوم خادم DNS التكراري بتخزين السجلات مؤقتًا حتى تنتهي صلاحيتها. وهي تقرر انتهاء صلاحية سجل بناءً على مدة البقاء (TTL) الخاصة به.



في هذا المثال ، يعرض خادم أسماء GitHub مدة بقاء قدرها 60 لسجل DNS الخاص به ، مما يعني 60 ثانية:

$ dig @205.251.193.165 github.com

github.com.		60	IN	A	140.82.112.4

هذا TTL قصير إلى حد ما. من الناحية النظرية ، إذا اتبعت جميع تطبيقات DNS معيار DNS ، فإن هذا يعني أنه إذا قررت GitHub تغيير عنوان IP لموقع github.com ، فسيحصل الجميع على عنوان IP جديد في غضون 60 ثانية. دعونا نرى كيف يحدث هذا في الممارسة.

الخيار 1: تحديث سجل DNS على نفس خوادم الأسماء

أولاً ، قمت بتحديث خوادم الأسماء الخاصة بي (Cloudflare) للحصول على سجل DNS جديد ، سجل A ، والذي يعيّن test.jvns.ca1.2.3.4:

$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca.		299	IN	A	1.2.3.4

عملت على الفور! لم تكن هناك حاجة للانتظار على الإطلاق ، لأنه قبل ذلك لم يكن هناك سجل DNS test.jvns.caيمكن تخزينه مؤقتًا. ممتاز. ولكن يبدو أنه تم تخزين الرقم القياسي الجديد مؤقتًا لمدة خمس دقائق (299 ثانية).



إذن ماذا لو حاولنا تغيير عنوان IP هذا؟ لقد غيرته إلى 5.6.7.8 ثم قمت بتشغيل نفس استعلام DNS:

$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca.		144	IN	A	1.2.3.4

يبدو أنه على خادم DNS هذا لا يزال السجل 1.2.3.4 مخبأًا لمدة 144 ثانية. ومن المثير للاهتمام ، إذا استفسرت عن 8.8.8.8 عدة مرات ، فستحصل على نتائج متضاربة - في بعض الأحيان يمنحك IP جديدًا وأحيانًا عنوان IP قديم. من المحتمل أن 8.8.8.8 يوزع الحمل عبر مجموعة من الخلفيات المختلفة ، لكل منها ذاكرة التخزين المؤقت الخاصة به.



بعد خمس دقائق من الانتظار ، تم تحديث جميع ذاكرات التخزين المؤقت 8.8.8.8 وعادت دائمًا إدخال 5.6.7.8 جديد. رائعة حقا. إنه سريع جدًا!

لا يمكنك دائمًا الاعتماد على TTL

كما هو الحال مع معظم بروتوكولات الإنترنت ، لا يتبع كل شيء مواصفات DNS. ستقوم بعض خوادم DNS الخاصة بـ ISP بتخزين السجلات مؤقتًا لفترة أطول من TTL المحدد. على سبيل المثال ، في غضون يومين بدلاً من خمس دقائق. ويمكن للأشخاص دائمًا ترميز عنوان IP القديم في ملفاتهم /etc/hosts.



من الناحية العملية ، عند تحديث سجل DNS لمدة خمس دقائق TTL ، يمكنك أن تتوقع أن تنتقل نسبة كبيرة من العملاء بسرعة إلى عناوين IP الجديدة (على سبيل المثال ، في غضون 15 دقيقة) ، وبعد ذلك ستكون هناك مجموعة من المتخلفين الذين سيتم تحديثهم ببطء خلال الأيام القليلة المقبلة.

الخيار 2: تحديث خوادم الأسماء الخاصة بك

لذلك ، رأينا أنه عند تجديد عنوان IP دون تغيير خوادم الأسماء الخاصة بك ، تحصل العديد من خوادم DNS على عنوان IP جديد بسرعة كبيرة. ممتاز. ولكن ماذا يحدث إذا قمت بتغيير خوادم الأسماء الخاصة بك؟ لنجرب!



لم أرغب في تحديث خوادم الأسماء لمدونتي ، لذا بدلاً من ذلك أخذت نطاقًا مختلفًا خاصتي واستخدمته في أمثلة سجل HTTP ، examplecat.com.



في السابق ، تم تعيين خوادمي على dns1.p01.nsone.net. قررت تغييرها إلى خوادم Google بالعناوين ns-cloud-b1.googledomains.comوما إلى ذلك.



عندما قمت بإجراء التغيير ، تومض مسجل النطاق الخاص بي الرسالة بشكل ينذر بالسوء إلى حد ما: "تم حفظ التغييرات على examplecat.com. وستدخلان حيز التنفيذ خلال الـ 48 ساعة القادمة ". ثم قمت بإعداد سجل A جديد للنطاق للإشارة إلى 1.2.3.4.



حسنًا ، دعنا نرى ما إذا كان أي شيء قد تغير:

$ dig @8.8.8.8 examplecat.com
examplecat.com.		17	IN	A	104.248.50.87

لا تغييرات. إذا سألت خادم DNS آخر ، فإنه يعرف عنوان IP الجديد:

$ dig @1.1.1.1 examplecat.com
examplecat.com.		299	IN	A	1.2.3.4

لكن 8.8.8.8 لا يزال لا يعرف أي شيء. السبب في أن 1.1.1.1 يرى عنوان IP جديدًا ، على الرغم من أنني قمت بتغييره منذ خمس دقائق ، ربما يرجع السبب في ذلك إلى أنه لم يسأل أحد على الإطلاق 1.1.1.1 عن هذا Examplecat.com من قبل - مما يعني أنه ليس لديه أي شيء في ذاكرة التخزين المؤقت الخاصة به كانت.

تحتوي خوادم الأسماء على مدة TTL أكثر بكثير

سبب قول أمين السجل الخاص بي ، "سيستغرق ذلك 48 ساعة" ، هو أن مدة البقاء في سجلات NS أكبر بكثير.



يعرض خادم الأسماء الجديد بالتأكيد عنوان IP جديدًا لـ examplecat.com:

$ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com.		300	IN	A	1.2.3.4

لكن تذكر ما حدث عندما استفسرنا عن خوادم أسماء github.com مسبقًا:

$ dig @192.5.6.30 github.com
...
github.com.		172800	IN	NS	ns-421.awsdns-52.com.
ns-421.awsdns-52.com.	172800	IN	A	205.251.193.165
...

172،800 ثانية هي 48 ساعة! وبالتالي ، عادةً ما يستغرق تحديث خادم الأسماء وقتًا أطول. يستغرق انتهاء صلاحية ذاكرات التخزين المؤقت ونشر العنوان الجديد وقتًا. يستغرق الأمر وقتًا أطول بكثير من مجرد تحديث عنوان IP الخاص بك دون تغيير خادم الأسماء.

كيف يتم تحديث خوادم الأسماء الخاصة بك

عندما أقوم بتحديث خوادم الأسماء لـ examplecat.com، .comيحصل خادم الأسماء على سجل NS جديد بنطاق جديد. مثله:

dig ns @j.gtld-servers.net examplecat.com

examplecat.com.		172800	IN	NS	ns-cloud-b1.googledomains.com

ولكن كيف يصل سجل NS الجديد إلى هناك؟ في الواقع ، أخبر مسجل النطاق الخاص بي كيف أريد أن تبدو خوادم الأسماء الجديدة من خلال تحديثها على موقع الويب ، ثم يخبر مسجل النطاق خوادم الأسماء .comبالقيام بالتحديث.



بالنسبة .comلهذه التحديثات ، تكون سريعة إلى حد ما (في غضون بضع دقائق) ، لكنني أعتقد أنه بالنسبة لبعض مناطق TLD الأخرى ، قد لا تطبق خوادم الأسماء التحديثات بالسرعة نفسها.

يمكن أيضًا لمكتبة محلل DNS في البرنامج تخزين سجلات DNS مؤقتًا

سبب آخر لعدم ملاحظة TTL عمليًا هو أن العديد من البرامج يجب أن تحل أسماء DNS ، كما أن بعض البرامج ستخزن سجلات DNS مؤقتًا في الذاكرة إلى أجل غير مسمى (حتى يتم إعادة تشغيل البرنامج).



على سبيل المثال ، هناك مقال حول إعداد JVM TTL لبحث DNS . لم أكتب الكثير من كود JVM لبحث DNS بنفسي ، لكن القليل من البحث على الإنترنت حول JVM و DNS يعطي انطباعًا بأنه يمكنك تكوين JVM لتخزين كل بحث DNS مؤقتًا لفترة غير محدودة من الوقت (انظر بطاقة ElasticSearch على سبيل المثال ) ...

هذا كل شئ!

آمل أن يساعدك هذا في فهم ما يحدث عند تحديث DNS الخاص بك.



سأحفظ أن السجل الكامل لتوزيع DNS لا يتم تحديده فقط بواسطة TTL. ربما لا تحترم بعض خوادم DNS التكرارية TTL ، حتى الخوادم الرئيسية مثل 8.8.8.8. لذا ، حتى إذا قمت للتو بتحديث السجل A باستخدام TTL صغير ، فمن الممكن أن تستمر عمليًا في تلقي طلبات IP القديم في غضون يوم أو يومين.



بعد نشر هذه المقالة ، قمت بتغيير خوادم الأسماء الخاصة بـ examplecat.com إلى قيمها القديمة.



ماذا تقرأ:

1. اذهب ومخابئ وحدة المعالجة المركزية .
2. قاعدة البيانات التي تختارها للمشروع حتى لا تضطر إلى الاختيار مرة أخرى .
3. تدور قناة Telegram الخاصة بنا حول التحول الرقمي .