تفويض مجال DNS إلى خوادم Yandex والاتصال بخدمة Yandex المجانية "Mail for a Domain". أفضل خوادم DNS ما هي أسماء DNS المستخدمة؟

• ترجمة

سيجد القارئ اليقظ IPv6 في هذه الصورة

غالبًا ما يتم الخلط بين الناس بشأن المجالات. لماذا لا يعمل موقعي؟ لماذا تم كسر هذا الهراء، لا شيء يساعد، أريد فقط أن يعمل!عادةً ما يكون السائل إما لا يعرف شيئًا عن DNS، أو لا يفهم الأفكار الأساسية. بالنسبة للكثيرين، DNS هو شيء مخيف وغير مفهوم. هذه المقالة هي محاولة لتبديد هذا الخوف. DNS هو فقط، إذا كنت تفهم بعض المفاهيم الأساسية.

ما هو DNS

DNSتمثل نظام اسم المجال. إنه متجر ذو قيمة رئيسية موزعة عالميًا. يمكن للخوادم في جميع أنحاء العالم أن تمنحك القيمة حسب المفتاح، وإذا كانوا لا يعرفون المفتاح، فسوف يطلبون المساعدة من خادم آخر.

هذا كل شئ. هل هذا صحيح؟ تطلب أنت أو متصفحك قيمة للمفتاح www.example.com ويتلقى 1.2.3.4 ردًا على ذلك.

اشياء اساسيه

الميزة الكبرى لـ DNS هي أنها خدمة عامة، ويمكنك الدخول إلى الخوادم إذا كنت تريد معرفة ذلك. دعونا نحاول. لدي نطاق petekeen.net، وهو مستضاف على الجهاز web01.bugsplat.info. يمكن تشغيل الأوامر المستخدمة أدناه من سطر أوامر OS X ( أوه، هذا هو، macOS، - تقريبًا. خط).

دعونا نلقي نظرة على التعيين بين الاسم والعنوان:

$حفر web01.bugsplat.info

أمر الحفر هو سكين الجيش السويسري لاستعلامات DNS. أداة رائعة ومتعددة الوظائف. وهنا الجزء الأول من الجواب:

; <<>> ديج 9.7.6-P1<<>> web01.bugsplat.info ;; الخيارات العامة: +cmd ;; حصلت على الجواب: ;; - >>الرأس<<- opcode: QUERY, status: NOERROR, id: 51539 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

لا يوجد سوى تفاصيل واحدة مثيرة للاهتمام هنا: معلومات حول الطلب نفسه. تقول أننا طلبنا سجلاً وتلقينا ردًا واحدًا بالضبط. هنا:

؛؛ قسم الأسئلة: ;web01.bugsplat.info. في

طلبات الحفر والسجلات بشكل افتراضي. ا هذا عنوان(العنوان)، وهذا أحد الأنواع الأساسية للسجلات في DNS. يحتوي على عنوان IPv4 واحد. يوجد ما يعادل عناوين IPv6 - AAAA. دعونا نلقي نظرة على الجواب:

؛؛ قسم الإجابة: web01.bugsplat.info. 300 في 192.241.250.244

تصف بقية الإجابة الإجابة نفسها:

؛؛ وقت الاستعلام: 20 مللي ثانية؛؛ الخادم: 192.168.1.1#53(192.168.1.1) ؛؛ متى: الجمعة 19 يوليو 20:01:16 2013؛؛ مقاس MSG RCVD: 56

على وجه الخصوص، توضح المدة التي استغرقها الخادم للاستجابة، وعنوان IP الخاص بالخادم (192.168.1.1)، وما هو المنفذ الذي تم حفره (53، منفذ DNS الافتراضي)، ومتى اكتمل الطلب، وعدد البايتات كانوا في الرد.

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

لكن في هذا المثال، ليس من الواضح أن خادم DNS 192.168.1.1 اتصل بمجموعة من الخوادم الأخرى للإجابة على سؤال بسيط: "إلى أين يشير العنوان web01.bugsplat.info؟" دعونا نجري عملية تتبع للتعرف على السلسلة المحتملة بأكملها التي يجب أن تمر بها عملية الحفر "y" إذا لم يتم تخزين المعلومات مؤقتًا:

$ dig +trace web01.bugsplat.info ;<<>> ديج 9.7.6-P1<<>> +تتبع web01.bugsplat.info ;; الخيارات العالمية: +cmd . 137375 في NS l.root-servers.net. . 137375 في NS m.root-servers.net. . 137375 في NS a.root-servers.net. . 137375 في NS b.root-servers.net. . 137375 في NS c.root-servers.net. . 137375 في NS d.root-servers.net. . 137375 في NS e.root-servers.net. . 137375 في NS f.root-servers.net. . 137375 في NS g.root-servers.net. . 137375 في NS h.root-servers.net. . 137375 في NS i.root-servers.net. . 137375 في NS j.root-servers.net. . 137375 في NS k.root-servers.net. ؛؛ تم استلام 512 بايت من 192.168.1.1#53(192.168.1.1) في 189 مللي ثانية من المعلومات. 172800 في NS c0.info.afilias-nst.info. معلومات. 172800 في NS a2.info.afilias-nst.info. معلومات. 172800 في NS d0.info.afilias-nst.org. معلومات. 172800 في NS b2.info.afilias-nst.org. معلومات. 172800 في NS b0.info.afilias-nst.org. معلومات. 172800 في NS a0.info.afilias-nst.info. ؛؛ تم استلام 443 بايت من 192.5.5.241#53(192.5.5.241) في 1224 مللي ثانية bugsplat.info. 86400 في NS ns-1356.awsdns-41.org. bugsplat.info. 86400 في NS ns-212.awsdns-26.com. bugsplat.info. 86400 في NS ns-1580.awsdns-05.co.uk. bugsplat.info. 86400 في NS ns-911.awsdns-49.net. ؛؛ تم استلام 180 بايت من 199.254.48.1#53(199.254.48.1) في 239 مللي ثانية web01.bugsplat.info. 300 في 192.241.250.244 bugsplat.info. 172800 في NS ns-1356.awsdns-41.org. bugsplat.info. 172800 في NS ns-1580.awsdns-05.co.uk. bugsplat.info. 172800 في NS ns-212.awsdns-26.com. bugsplat.info. 172800 في NS ns-911.awsdns-49.net. ؛؛ تم استلام 196 بايت من 205.251.195.143#53(205.251.195.143) في 15 مللي ثانية

يتم عرض المعلومات في تسلسل هرمي. تذكر كيف حفر إدراج فترة. بعد المضيف، web01.bugsplat.info ؟ لذا، الفترة. وهذا تفصيل مهم ويدل على أصل التسلسل الهرمي.

تتم صيانة خوادم DNS الجذرية من قبل العديد من الشركات والبلدان حول العالم. في البداية كان هناك عدد قليل منهم، ولكن شبكة الإنترنت نمت، والآن هناك 13 منهم. لكن كل خادم لديه عشرات أو مئات من الأجهزة المادية المخفية خلف عنوان IP واحد.

لذلك، في الجزء العلوي من التتبع توجد خوادم الجذر، ويتم تحديد كل منها بواسطة سجل NS. يربط سجل NS اسم المجال (في هذه الحالة، المجال الجذر) بخادم DNS. عندما تقوم بتسجيل اسم نطاق لدى جهة تسجيل مثل Namecheap أو Godaddy، فإنها تقوم بإنشاء سجلات NS لك.

في الكتلة التالية، يمكنك أن ترى كيف اختار Dig خادم جذر عشوائي وطلب منه سجل A لـ web01.bugsplat.info. يظهر فقط عنوان IP الخاص بخادم الجذر (192.5.5.241). إذن ما هو خادم الجذر بالضبط؟ هيا نكتشف!

$ حفر -x 192.5.5.241 ;<<>> ديج 9.8.3-P1<<>> -x 192.5.5.241؛؛ الخيارات العامة: +cmd ;; حصلت على الجواب: ;; - >>الرأس<<- opcode: QUERY, status: NOERROR, id: 2862 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;241.5.5.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 241.5.5.192.in-addr.arpa. 3261 IN PTR f.root-servers.net.

تؤدي العلامة -x إلى قيام dig بإجراء بحث عكسي على عنوان IP. يستجيب DNS بسجل PTR الذي يربط IP والمضيف، في هذه الحالة f.root-servers.net.

وبالعودة إلى طلبنا الأولي، أعاد خادم الجذر F مجموعة مختلفة من خوادم NS. وهو مسؤول عن مجال المعلومات ذي المستوى الأعلى. يطلب dig من أحد هذه الخوادم سجل A لـ web01.bugsplat.info ، ويتلقى مجموعة أخرى من خوادم NS ردًا على ذلك، ثم يقوم بالاستعلام واحدة من هذهتسجل الخوادم A لـ web01.bugsplat.info. . وأخيرا يحصل على إجابة!

قرف! سيتم إنشاء الكثير من حركة المرور، ولكن تم تخزين جميع هذه السجلات تقريبًا مؤقتًا لفترة طويلة بواسطة كل خادم في السلسلة. يقوم جهاز الكمبيوتر الخاص بك أيضًا بتخزين هذه البيانات مؤقتًا، تمامًا مثل متصفحك. في أغلب الأحيان، لا تصل استعلامات DNS أبدًا إلى خوادم الجذر نظرًا لأن عناوين IP الخاصة بها لا تتغير أبدًا ( "ربما نتحدث عن TTL كبير للسجلات الموجودة في قاعدة بياناتهم. إذا لم يتغير عنوان IP الخاص بخادم DNS على الإطلاق، فهذا لا يعني أن قاعدة البيانات الخاصة به مخزنة مؤقتًا إلى الأبد.- تقريبا. من رراف). نطاقات المستوى الأعلى com وnet وorg وما إلى ذلك. عادةً ما يتم تخزينها مؤقتًا بشكل كبير.

أنواع أخرى

هناك بضعة أنواع أخرى تستحق المعرفة عنها. الأول هو MX. فهو يربط اسم المجال بخادم بريد واحد أو أكثر. البريد الإلكتروني مهم جدًا لدرجة أنه يحتوي على نوع خاص به من سجل DNS. فيما يلي قيم MX لموقع petekeen.net:

$ حفر petekeen.net مكس ;<<>> ديج 9.7.6-P1<<>> petekeen.net mx ;; الخيارات العامة: +cmd ;; حصلت على الجواب: ;; - >>الرأس<<- opcode: QUERY, status: NOERROR, id: 18765 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;petekeen.net. IN MX ;; ANSWER SECTION: petekeen.net. 86400 IN MX 60 web01.bugsplat.info. ;; Query time: 272 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:33:43 2013 ;; MSG SIZE rcvd: 93

لاحظ أن سجل MX يشير إلى اسم، وليس إلى عنوان IP.

هناك نوع آخر ربما تكون على دراية به وهو CNAME. فك كما الاسم المقبول(الاسم المقبول). فهو يربط اسمًا بآخر. دعونا ننظر إلى الجواب:

$ حفر www.petekeen.net ;<<>> ديج 9.7.6-P1<<>> www.petekeen.net ;; الخيارات العامة: +cmd ;; حصلت على الجواب: ;; - >>الرأس<<- opcode: QUERY, status: NOERROR, id: 16785 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.petekeen.net. IN A ;; ANSWER SECTION: www.petekeen.net. 86400 IN CNAME web01.bugsplat.info. web01.bugsplat.info. 300 IN A 192.241.250.244 ;; Query time: 63 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:36:58 2013 ;; MSG SIZE rcvd: 86

من الواضح على الفور أننا تلقينا إجابتين. الأول يقول أن www.petekeen.net يشير إلى web01.bugsplat.info. يقوم الثاني بإرجاع السجل A لهذا الخادم. يمكنك اعتبار CNAME كاسم مستعار (أو اسم مستعار) لخادم آخر.

ما هو الخطأ في CNAME

تعد سجلات CNAME مفيدة جدًا، ولكن هناك نقطة مهمة: إذا كان هناك CNAME باسم معين، فلن تتمكن من إنشاء سجل آخر بنفس الاسم. لا يوجد MX، ولا A، ولا NS، ولا شيء.

والسبب هو أن DNS يقوم بالاستبدال بطريقة تجعل جميع سجلات الموقع الذي يشير إليه CNAME صالحة أيضًا لـ CNAME. في مثالنا، سوف تتطابق إدخالات www.petekeen.net وweb01.bugsplat.info.

ولذلك، لا يمكنك إنشاء CNAME على نطاق جذر مثل petekeen.net، لأنه يحتاج عادةً إلى سجلات أخرى، مثل MX.

طلبات إلى خوادم أخرى

لنتخيل أن تكوين DNS تالف. تعتقد أنك قد أصلحت المشكلة، ولكنك لا تريد الانتظار حتى يتم تحديث ذاكرة التخزين المؤقت للتأكد. باستخدام dig، يمكنك تقديم طلب إلى خادم DNS عام بدلاً من خادمك الافتراضي، مثل هذا:

$ حفر www.petekeen.net @8.8.8.8

يتسبب الرمز @ بعنوان IP أو المضيف في قيام dig بتقديم طلب إلى الخادم المحدد على المنفذ الافتراضي. يمكنك استخدام خادم DNS العام من Google أو خادم المستوى 3 شبه العام على 4.2.2.2.

حالات نموذجية

دعونا نلقي نظرة على المواقف النموذجية المألوفة لدى العديد من مطوري الويب.

إعادة توجيه المجال إلى www

غالبًا ما تحتاج إلى إعادة توجيه النطاق iskettlemanstillopen.com إلى www.iskettlemanstillopen.com. المسجلون مثل Namecheap أو DNSimple يسمون هذا إعادة توجيه عنوان URL. فيما يلي مثال من لوحة إدارة Namecheap:

يشير الرمز @ إلى المجال الجذر وهو iskettlemanstillopen.com. دعونا نلقي نظرة على السجل A لهذا المجال:

$ dig iskettlemanstillopen.com ;; قسم الأسئلة: ;iskettlemanstillopen.com. في ؛؛ قسم الإجابة: iskettlemanstillopen.com. 500 في 192.64.119.118

ينتمي عنوان IP هذا إلى Namecheap، ويوجد خادم ويب صغير يعمل هناك ويقوم ببساطة بإعادة التوجيه على مستوى HTTP إلى العنوان http://www.iskettlemanstillopen.com:

$ cur -I iskettlemanstillopen.com cur -I iskettlemanstillopen.com HTTP/1.1 302 تم نقله مؤقتًا الخادم: nginx التاريخ: الجمعة، 19 يوليو 2013 الساعة 23:53:21 بتوقيت جرينتش نوع المحتوى: نص/html الاتصال: طول المحتوى المستمر : 154 الموقع: http://www.iskettlemanstillopen.com/

CNAME لـ Heroku أو Github

ألق نظرة على لقطة الشاشة أعلاه. على السطر الثاني يوجد CNAME. في هذه الحالة، يشير موقع www.iskettlemanstillopen.com إلى التطبيق الذي يعمل على Heroku.

نطاقات Heroku $ === Warm-journey-3906 أسماء النطاقات Warm-journey-3906.herokuapp.com www.iskettlemanstillopen.com

القصة مشابهة لـ Github، ولكن هناك تحتاج إلى إنشاء ملف خاص في جذر المستودع وتسميته CNAME. راجع الوثائق .dns أضف العلامات

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

ما هو DNS؟

الإنترنت عبارة عن شبكة تربط ملايين أجهزة الكمبيوتر. تحتوي الشبكة على أجهزة كمبيوتر تعمل على مدار الساعة وبدون توقف. عادةً ما تكون هذه الخوادم تُستخدم لتخزين مواقع الويب والبريد الإلكتروني. يتلقى كل كمبيوتر، عند اتصاله بالإنترنت، معرفًا خاصًا في شكل رقمي. وبعبارة أخرى، عنوان IP. بالطبع، يمكنك الوصول إلى الخادم باستخدام معرف رقمي، لكن الممارسة تظهر أنه لن يكون من المناسب للأشخاص تذكر العناوين في شكل أرقام. لذلك، قدم المطورون نظام نطاقات الحروف.

نظام اسم المجال، أو DNS، هو نظام خاص يطابق النطاقات مع عناوينها الرقمية. هناك فئة خاصة من الخوادم على الإنترنت - خوادم ns المسؤولة عن تخزين DNS. هناك يمكنك التحقق من سجلات DNS الخاصة بالمجال الخاص بك. وهي مدعومة على كلا الجانبين - من قبل موفري خدمة الإنترنت والمضيفين، وكذلك من قبل مسؤولي منطقة المجال. بيانات الخادم لها تسلسل هرمي خاص بها.

توقيت تحديث سجلات DNS

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

ابدأ بشكل أسرع

إذا كنت قد أكملت العملية للتو أو قمت بتغيير سجلات DNS الخاصة بك وتحتاج إلى البدء بسرعة في موقع الويب الخاص بك، فهناك خدعة رائعة يمكنك استخدامها لتسريع الوقت الذي تستغرقه للبدء. أضف سطرًا واحدًا إلى ملف المضيفين، والذي يقع افتراضيًا في C:\WINDOWS\system32\drivers\etc (قد يكون المجلد مخفيًا):

Xxxx.xxx.xxx.xxx site.ru

يتم استخدام عنوان IP الخاص بالخادم الذي يوجد به موقع الويب كـ xxx.xxx.xxx.xxx، وsite.ru هو مجال موقع الويب الخاص بك.

أنواع سجلات DNS

قد تحتاج إلى تعيين إدخالات متعددة لتكون ناجحًا.

• دخول ن.سيحدد خادم DNS الذي يخدم المجال. يتم تقديم هذه الخدمات من قبل مزود الاستضافة أو مسجل النطاق.
• سجل أمطلوب للإشارة إلى عنوان IP الخاص بك. يمكن تحديد هذا العنوان بواسطة موفر الاستضافة.
• سجل AAAAيجب استخدامه لتحديد عنوان IP للإصدار 6. الدعم واسع النطاق لم ينتشر بعد.
• سجل إم إكسيجب إضافتها للإشارة إلى خادم البريد الخاص بك. ستكون هناك حاجة للبريد للوصول إلى صناديق بريد المجال.
• سجل CNAMEهناك حاجة لاستخدام مجال واحد كعنوان لمجال مختلف تمامًا، أي أنه ينشئ نطاقًا فرعيًا.
• سجل PTRستكون هناك حاجة إليها في الحالات التي تحتاج فيها إلى الحصول على اسم مجال مؤهل بالكامل. يتم تعيين هذا الإدخال افتراضيًا بواسطة موفري الاستضافة، لكنك لا تزال بحاجة إلى التحقق من صحة الإدخال باستخدام خدمة خاصة.

إنشاء سجل Wildcard DNS

Wildcard هو سجل DNS خاص مسؤول عن النطاقات الفرعية *.site.ru. تحتاج إلى تحديد مثل هذا الإدخال لنظام إدارة المحتوى (CMS) المستخدم لإدارة النطاقات الفرعية الموجودة. لإنشاء مثل هذا السجل، تحتاج إلى إضافة سجل من النوع A، وتعيين * كمجال فرعي. لتكوين Apache، تحتاج إلى إجراء التغييرات التالية على ملف تكوين خاص:

DocumentRoot "/home/site.ru" اسم الخادم "site.ru" ServerAlias ​​​​"www.site.ru" سجلات ErrorLog/site.ru-error.log سجلات CustomLog/site.ru-access.log المشتركة

هنا تحتاج فقط إلى إضافة الاسم المستعار *.site.ru.

تعمل شبكة الإنترنت على أساس نظام DNS الذي يحتوي على أسماء النطاقات وعناوين IP. يوجد 13 خادم DNS جذريًا يحتوي على معلومات حول نطاقات المستوى الأعلى مثل .com، و.ru، و.uk، وما إلى ذلك. يقع معظمها في الولايات المتحدة الأمريكية، وعدد قليل منها في أوروبا واليابان، وهناك أيضًا "مرايا" في بلدان مختلفة تكرر المعلومات. تتم إدارة خوادم DNS من قبل منظمة ICANN الدولية غير الربحية، ومقرها في الولايات المتحدة.

2019

ICANN تشعر بالقلق إزاء التهديد الذي يتعرض له أمن عناصر الإنترنت الرئيسية

تتعرض العناصر الرئيسية للبنية التحتية العالمية للإنترنت للتهديد من الهجمات السيبرانية واسعة النطاق. وقد أبلغ ممثلو مؤسسة ICANN وكالة الأنباء الفرنسية (AFP) بذلك في 22 فبراير.

وكما أفادت وكالة فرانس برس، عقدت ICANN اجتماعًا طارئًا بسبب "المخاطر العالية المستمرة" التي تواجه العناصر الرئيسية للبنية التحتية للإنترنت. ووفقا لما ذكره ديفيد كونراد، كبير مديري التكنولوجيا في الشركة، فإن المهاجمين مهتمون بالبنية التحتية نفسها التي تقوم عليها الشبكة العالمية. وقال كونراد: "كانت هناك هجمات في الماضي، ولكن لا شيء يمكن مقارنتها بهذه الهجمات".

بدأت الهجمات في عام 2017، لكنها بدأت الآن فقط في إثارة القلق بين الباحثين الأمنيين، ولهذا السبب تم عقد اجتماع طارئ. يستهدف المهاجمون نظام DNS، والذي يقول خبراء ICANN إنه قد يسمح لهم باعتراض حركة المرور وإعادة توجيهها سرًا إلى مكان آخر وانتحال المواقع المهمة.

بدأت الهجمات، التي تسمى DNSpionage، في عام 2017، وفقًا لمحلل التجسس السيبراني الكبير في FireEye Ben Read. يعترض المهاجمون في المقام الأول بيانات اعتماد مسجلي أسماء النطاقات ومقدمي خدمات الإنترنت في الشرق الأوسط. ويعتقد أن قراصنة إيرانيين يعملون نيابة عن الحكومة الإيرانية هم الذين يقفون وراء الهجمات.

وقال كونراد: "لا توجد أداة واحدة لحل هذه المشكلة". وفي هذا الصدد، تدعو ICANN الخبراء إلى تعزيز أمن البنية التحتية للإنترنت ككل.

اعتبارًا من 1 فبراير 2019، لن يكون من الممكن الوصول إلى العديد من مواقع الإنترنت

أعلن عدد من شركات خدمات DNS وشركات تصنيع خوادم DNS في يناير 2019 عن عقد يوم للمعالجة الصحيحة لاستعلامات DNS، أو ما يسمى بـ "يوم العلم". في هذا اليوم، المقرر في 1 فبراير 2019، لن تقوم المبادرة بعد الآن بتنفيذ الحلول البديلة لخوادم DNS الموثوقة التي لا تدعم بروتوكول EDNS. بحلول التاريخ المحدد، يقوم كل مشارك في المبادرة بتنفيذ التغييرات المقابلة في إصدار معين من برنامجه.

بالنسبة لـ BIND 9، سيتم إغلاق الحلول البديلة في BIND 9.14.0، المقرر إصداره في الأول من فبراير. الابتكار متاح بالفعل للفرع 9.13، ولكن لن يتم نقله إلى 9.11 أو فروع BIND الأقدم، لأنه وفقًا لسياسة الشركة، لا يتم إجراء تغييرات على الإصدارات الثابتة ذات الدعم الموسع. يدعم خادم DNS الرسمي (الأساسي) BIND بروتوكول EDNS بالفعل.

بدءًا من 1 فبراير، قد تصبح النطاقات التي تخدمها خوادم DNS غير المتوافقة مع EDNS غير متاحة. يجب على الشركات التي يتم خدمة مناطق DNS الخاصة بها بواسطة خوادم غير متوافقة أن تدرك أن تواجدها على الإنترنت سيبدأ في الانخفاض بشكل ملحوظ وقد يختفي عندما يقوم مزودو خدمات الإنترنت والمؤسسات الأخرى بتحديث محللات DNS الخاصة بهم. بعد تحديث أدوات الحل إلى إصدارات لا تحتوي على حلول بديلة، قد تصبح بعض المواقع وخوادم البريد غير متوفرة.

يُنصح مشغلو خوادم DNS الموثوقة بالتحقق من توافق أنظمتهم مع EDNS على https://dnsflagday.net/. لا داعي للقلق لمستخدمي BIND 9 لأنه، كما ذكرنا أعلاه، فإن خادم DNS متوافق بالفعل مع EDNS.

2018: لأول مرة في تاريخ الإنترنت، تم تحديث مفاتيح التشفير لحماية DNS

في 11 أكتوبر 2018، حدث الاستبدال الأول الذي طال انتظاره لمفاتيح التشفير التي تحمي نظام اسم المجال (DNS) في تاريخ الإنترنت. هذه العملية، كما ورد في []، مرت دون مشاكل.

ظهرت مفاتيح التشفير في عام 2010 بمبادرة من ICANN. وقد تم استخدامها في ملحق أمان DNS (DNSSEC). في البداية، لم توفر خوادم نظام أسماء النطاقات (DNS) التحقق من صحة الاستجابات، وهو ما استغله المهاجمون: حيث كان بإمكانهم اعتراض طلب من كمبيوتر المستخدم الذي كان يحاول تعيين عنوان IP الخاص بـ "وجهته" واستبداله بعنوان غير صحيح. وبالتالي، يمكن للمستخدم، دون أن يلاحظ ذلك، الاتصال بخادم المحتالين. ولتجنب ذلك، تم إصدار امتداد DNSSEC في عام 2010، والذي وافق العديد من كبار مزودي خدمات الإنترنت على تثبيته.

خططت ICANN لتغيير المفاتيح كل خمس سنوات. وكان من المفترض أن يتم التغيير الأول للمفاتيح في عام 2015، ولكن تم تأجيله بسبب انخفاض مستوى جاهزية مزودي خدمة الإنترنت.

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

إن نائب رئيس ICANN للأبحاث، مات لارسون، واثق من أن تحديثات مفاتيح التشفير هذه ستصبح شائعة بالنسبة للمشغلين.

2017: تم توجيه وزارة الاتصالات والإعلام لإنشاء "إنترنت مستقل" لدول البريكس.

في نوفمبر 2017، أصدر مجلس الأمن الروسي تعليماته إلى وزارة الاتصالات والإعلام، بالتعاون مع وزارة الخارجية الروسية، للعمل على مسألة إنشاء نظام خاص بهم لخوادم أسماء النطاقات الجذرية، أو DNS، في دول البريكس (البرازيل، روسيا والهند والصين وجنوب أفريقيا) بحلول 1 أغسطس 2018. وبعبارة أخرى، كتب RBC أن مجلس الأمن قد أصدر تعليماته بجعل الإنترنت في هذه البلدان مستقلة عن المنظمات الدولية وعن التأثير الخارجي.

"ضمن شبكة الإنترنت الحالية، لا يمكن تحقيق الاستقلال؛ على أي حال، سوف تتباعد المعلومات الموجودة على خوادم الجذر من نقطة واحدة - IANA. وبالتالي، فإن إنشاء نظام لخوادم اسم النطاق الجذر، بشكل مستقل عن المسؤولين الدوليين، يعادل إنشاء إنترنت بديل، مستقل عن الموجود،" نقلاً عن منشور صادر عن ممثل المركز الفني للإنترنت (TCI)، الذي يحافظ على بنية DNS للجزء الروسي من الشبكة.

ويشير المراقبون إلى أن إنشاء خوادم DNS بديلة سيؤدي إلى تجزئة الإنترنت وإنشاء شبكة منفصلة.

2014: نقل وظائف التحكم في إدارة منطقة جذر DNS من حكومة الولايات المتحدة

في ديسمبر 2014، أعدت مجموعة العمل متعددة الصناعات التابعة لـ ICANN مقترحات لنقل التحكم في إدارة منطقة جذر DNS من الحكومة إلى مجتمع الإنترنت. تم اتخاذ مبادرة نقل هذه الوظائف هذا الربيع من قبل الإدارة الوطنية للاتصالات والمعلومات (NTIA)، وهي جزء من وزارة التجارة الأمريكية. وقدمت مجموعة العمل المشتركة بين القطاعات المكونة من 119 عضوًا خيارين لنقل الوظائف.

وقد تم ذكر إحداها بعبارات عامة جدًا، حيث إنها تنص على نقل وظائف التحكم مباشرةً إلى ICANN. ومع ذلك، سيتم مراقبة أداء الوظائف من خلال آليات المساءلة الحالية في ICANN .

وهناك خيار آخر يتمثل في إنشاء هيكل جديد للإشراف على أنشطة إدارة نظام نطاق ICANN، والتي يحكمها أعضاء مجتمع الإنترنت. يؤكد مؤلفو المقترحات أننا نتحدث عن هيكل غير ربحي مع الحد الأدنى لعدد الموظفين. وبالتالي، فمن الواضح أن مجموعة العمل المشتركة بين الصناعات تسعى إلى تجنب ما يخشاه العديد من المراقبين - إنشاء "مؤسسة ICANN أخرى للإشراف على ICANN".

سوف يتولى الهيكل، الذي تم تحديده تقليديًا في الوثيقة باسم Contract Co، وظائف NTIA لمراقبة إدارة منطقة جذر DNS. سيتم تكليف تطوير شروط العقد مع Contract Co والإشراف على الامتثال لتنفيذه إلى فريق مراجعة أصحاب المصلحة المتعددين، والذي تم تشكيله من بين مندوبين من جميع المجتمعات التي تمثل ICANN مصالحها. ولم يتم تحديد آليات تشكيل هذه اللجنة بعد، ومن المرجح أن تصبح موضوع نقاش ساخن، حيث أن مجموعة متنوعة من المجموعات ذات المصالح المتعارضة في كثير من الأحيان ستسعى جاهدة لتحقيق أقصى قدر من التمثيل فيها.

سيتم أيضًا تشكيل لجنة دائمة جديدة للعملاء، والتي ستضم ممثلين عن سجلات النطاقات ذات المستوى الأعلى العامة ورمز الدولة - باعتبارهم "مستهلكي الخدمة" الرئيسيين لمنطقة جذر DNS. وسوف ينقل رغبات السجلات إلى فريق مراجعة أصحاب المصلحة المتعددين، وبالتالي ضمان أن ICANN مسؤولة أمامهم. أخيرًا، من المخطط أيضًا إنشاء لجنة استئناف مستقلة، حيث يمكن تقديم الشكاوى ضد أي قرارات تتعلق بإدارة منطقة جذر DNS، بما في ذلك، بوضوح، القرارات المتعلقة بتفويض أو إلغاء تفويض النطاقات.

يتم نشر المقترحات على موقع ICANN الإلكتروني، ويتم قبول التعليقات حتى 22 ديسمبر 2014. يجب صياغة الاقتراح النهائي المقدم إلى حكومة الولايات المتحدة لنقل السيطرة على إدارة منطقة جذر DNS في صيف عام 2015.

ميزات DNS الرئيسية

يتميز DNS بالخصائص التالية:

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

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

تم تطوير DNS بواسطة Paul Mockapetris في عام 1983؛ تم وصف الوصف الأصلي لآليات التشغيل في RFC 882 وRFC 883. في عام 1987، أدى نشر RFC 1034 وRFC 1035 إلى تغيير مواصفات DNS وإهمال RFC 882 وRFC 883. قامت بعض طلبات RFC الجديدة بإضافة وتوسيع قدرات البروتوكولات الأساسية.

ميزات إضافية

• دعم التحديثات الديناميكية
• اتصالات آمنة (DNSsec)
• دعم أنواع مختلفة من المعلومات (سجلات SRV)

المصطلحات ومبادئ التشغيل

المفاهيم الأساسية لـ DNS هي:

• المنطقة هي عقدة منطقية في شجرة الأسماء. يمكن نقل الحق في إدارة المنطقة إلى أطراف ثالثة، وبالتالي ضمان توزيع قاعدة البيانات. في هذه الحالة، يقوم الشخص الذي نقل حق الإدارة في قاعدة بياناته بتخزين معلومات فقط حول وجود المنطقة (ولكن ليس المناطق الفرعية!)، ومعلومات حول الشخص (المؤسسة) التي تدير المنطقة، وعناوين الخوادم التي هم المسؤولون عن المنطقة. يتم تخزين جميع المعلومات الإضافية على الخوادم المسؤولة عن المنطقة.
• النطاق هو اسم منطقة في نظام أسماء النطاقات على الإنترنت (DNS)، مخصصة لدولة أو منظمة أو لأغراض أخرى. تعكس بنية اسم النطاق ترتيب المناطق في شكل هرمي؛ تتم قراءة اسم المجال من اليسار إلى اليمين من النطاقات المبتدئة إلى نطاقات المستوى الأعلى (حسب الأهمية المتزايدة)، والمجال الجذر للنظام بأكمله عبارة عن نقطة (".")، تليها نطاقات المستوى الأول (جغرافية أو موضوعي)، ثم المستوى الثاني والثالث وما إلى ذلك (على سبيل المثال، بالنسبة للعنوان ru.wikipedia.org، نطاق المستوى الأول هو org، والثاني هو wikipedia، والثالث هو ru). من الناحية العملية، غالبًا ما يتم حذف النقطة الموجودة في نهاية الاسم، ولكنها قد تكون مهمة في حالات الفصل بين المجالات النسبية وFQDN (اسم المجال المؤهل بالكامل باللغة الإنجليزية، اسم المجال المؤهل بالكامل).
• المجال الفرعي (المجال الفرعي الإنجليزي) - اسم المنطقة التابعة. (على سبيل المثال، wikipedia.org هو نطاق فرعي لمجال org، وru.wikipedia.org هو نطاق فرعي لمجال wikipedia.org). من الناحية النظرية، يمكن أن يصل هذا التقسيم إلى عمق 127 مستوى، ويمكن أن تحتوي كل تسمية على ما يصل إلى 63 حرفًا، حتى يصل الطول الإجمالي، بما في ذلك الفترات، إلى 254 حرفًا. ولكن من الناحية العملية، يستخدم مسجلو أسماء النطاقات قيودًا أكثر صرامة.
• خادم DNS هو برنامج متخصص لصيانة DNS. قد يكون خادم DNS مسؤولاً عن بعض المناطق و/أو قد يعيد توجيه الاستعلامات إلى الخوادم الرئيسية.
• عميل DNS هو مكتبة (أو برنامج) متخصص للعمل مع DNS. في بعض الحالات، يعمل خادم DNS كعميل DNS.
• المسؤولية (بالإنجليزية: Authoritative) هي علامة على وضع منطقة على خادم DNS. يمكن أن تكون استجابات خادم DNS من نوعين: موثوقة (عندما يعلن الخادم أنه مسؤول عن المنطقة) وغير موثوقة (بالإنجليزية: Non-authoritative)، عندما يقوم الخادم بمعالجة الطلب وإرجاع استجابة من خوادم أخرى. في بعض الحالات، بدلاً من تمرير الطلب، قد يقوم خادم DNS بإرجاع قيمة معروفة له بالفعل (من الطلبات السابقة) (وضع التخزين المؤقت).
• استعلام DNS - طلب من العميل (أو الخادم) إلى الخادم. يمكن أن يكون الاستعلام عوديًا أو غير عوديًا. يقوم الاستعلام غير المتكرر إما بإرجاع معلومات حول المنطقة الموجودة في منطقة مسؤولية خادم DNS (الذي تلقى الطلب) أو إرجاع عناوين خوادم الجذر (بشكل أكثر دقة، عنوان أي خادم لديه المزيد معلومات حول المنطقة المطلوبة من الخادم المستجيب). في حالة الاستعلام المتكرر، يقوم الخادم باستقصاء الخوادم (بترتيب تنازلي لمستوى المنطقة في الاسم) حتى يجد إجابة أو يكتشف أن المجال غير موجود. من الناحية العملية، يبدأ البحث بخوادم DNS الأقرب إلى الخوادم التي تم البحث عنها؛ إذا كانت المعلومات المتعلقة بها موجودة في ذاكرة التخزين المؤقت وليست قديمة، فلا يجوز للخادم الاستعلام عن خوادم DNS). تتطلب الطلبات المتكررة المزيد من الموارد من الخادم (وتخلق المزيد من حركة المرور)، لذلك يتم قبولها عادة من العقد "المعروفة" لمالك الخادم (على سبيل المثال، يوفر المزود القدرة على تقديم طلبات متكررة لعملائه فقط؛ في شركة الشبكة، يتم قبول الطلبات العودية فقط من القطاع المحلي). عادةً ما يتم قبول الاستعلامات غير العودية من جميع العقد الموجودة على الشبكة (ويتم تقديم استجابة ذات معنى فقط للاستعلامات حول المنطقة المستضافة على العقدة؛ وعادةً ما تُرجع استعلامات DNS حول المناطق الأخرى عناوين خوادم الجذر).
• النطاق الفرعي هو اسم نطاق إضافي من المستوى الثالث في النطاق الرئيسي. يمكن الإشارة إلى المستندات الموجودة في الدليل الجذر أو إلى أي دليل فرعي للخادم الرئيسي. على سبيل المثال، إذا كان لديك نطاق مثل mydomain.ru، فيمكنك إنشاء نطاقات فرعية مختلفة له مثل mysite1.mydomain.ru، وmysite2.mydomain.ru، وما إلى ذلك.

يحتوي نظام DNS على تسلسل هرمي لخوادم DNS. يتم دعم كل مجال أو مجال فرعي بواسطة خادم DNS موثوق واحد على الأقل (من اللغة الإنجليزية الموثوقة - الموثوقة، الجديرة بالثقة؛ في RuNet، فيما يتعلق بـ DNS وخوادم الأسماء، غالبًا ما يتم استخدام خيارات الترجمة الأخرى: معتمدة، موثوقة)، والتي معلومات عنها يقع المجال. يتزامن التسلسل الهرمي لخوادم DNS مع التسلسل الهرمي للمجالات.

الاسم وعنوان IP ليسا متطابقين - يمكن أن يحتوي عنوان IP واحد على العديد من الأسماء، مما يسمح لك بدعم العديد من مواقع الويب على جهاز كمبيوتر واحد (وهذا ما يسمى بالاستضافة الافتراضية). والعكس صحيح أيضًا - حيث يمكن ربط العديد من عناوين IP باسم واحد: وهذا يسمح لك بإنشاء موازنة التحميل.

لزيادة استقرار النظام، يتم استخدام العديد من الخوادم التي تحتوي على معلومات متطابقة، ويحتوي البروتوكول على أدوات للحفاظ على تزامن المعلومات الموجودة على خوادم مختلفة. هناك 13 خادمًا جذرًا، ولا تتغير عناوينهم عمليًا.

يستخدم بروتوكول DNS منفذ TCP أو UDP رقم 53 للرد على الاستعلامات. تقليديًا، يتم إرسال الطلبات والاستجابات كمخطط بيانات UDP واحد. يتم استخدام TCP لطلبات AXFR.

العودية

دعونا نلقي نظرة على مثال لكيفية عمل النظام بأكمله.

لنفترض أننا كتبنا العنوان ru.wikipedia.org في المتصفح. يسأل المتصفح خادم DNS: "ما هو عنوان IP الخاص بـ ru.wikipedia.org"؟ ومع ذلك، قد لا يعرف خادم DNS شيئًا عن الاسم المطلوب فحسب، بل قد يعرف أيضًا عن نطاق wikipedia.org بأكمله. في هذه الحالة، يحدث التكرار: يصل الخادم إلى خادم الجذر - على سبيل المثال، 198.41.0.4. يُبلغ هذا الخادم - "ليس لدي أي معلومات حول هذا العنوان، لكنني أعلم أن 204.74.112.1 هو عنوان موثوق لمنطقة المؤسسة." يرسل خادم DNS بعد ذلك طلبه إلى 204.74.112.1، لكنه يستجيب بـ "ليس لدي معلومات حول هذا الخادم، لكنني أعلم أن 207.142.131.234 هو المعتمد لمنطقة wikipedia.org." وأخيرا، يتم إرسال نفس الطلب إلى خادم DNS الثالث ويتلقى استجابة - عنوان IP، الذي يتم تمريره إلى العميل - المتصفح.

في هذه الحالة، عند حل الاسم، أي في عملية البحث عن IP بالاسم:

• يرسل المتصفح ما يسمى بخادم DNS المعروف له. طلب متكرر - استجابة لهذا النوع من الطلب، يلتزم الخادم بإرجاع "النتيجة النهائية"، أي عنوان IP، أو الإبلاغ عن خطأ؛
• بعد أن تلقى خادم DNS طلبًا من العميل، أرسل استعلامات متكررة بالتتابع، حيث تلقى ردودًا من خوادم DNS الأخرى، حتى تلقى استجابة موثوقة من الخادم المسؤول عن المنطقة المطلوبة.

من حيث المبدأ، يمكن للخادم الذي تم الاستعلام عنه تمرير استعلام متكرر إلى خادم DNS "الأصلي" وانتظار استجابة جاهزة.

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

عكس بحث DNS

يتم استخدام DNS في المقام الأول لتحليل الأسماء الرمزية لعناوين IP، ولكن يمكنه أيضًا إجراء العملية العكسية. ولهذا الغرض، يتم استخدام أدوات DNS الموجودة. الحقيقة هي أنه يمكن ربط بيانات مختلفة بسجل DNS، بما في ذلك الاسم الرمزي. يوجد مجال خاص في addr.arpa، حيث تُستخدم الإدخالات لتحويل عناوين IP إلى أسماء رمزية. على سبيل المثال، للحصول على اسم DNS للعنوان 11.22.33.44، يمكنك الاستعلام عن خادم DNS للسجل 44.33.22.11.in-addr.arpa، وسيقوم بإرجاع الاسم الرمزي المقابل. يتم تفسير الترتيب العكسي لكتابة أجزاء من عنوان IP من خلال حقيقة أنه في عناوين IP توجد البتات الأكثر أهمية في البداية، وفي أسماء DNS الرمزية، توجد الأجزاء الأكثر أهمية (الأقرب إلى الجذر) في النهاية.

سجلات DNS

أهم أنواع سجلات DNS هي:

• يقوم سجل (سجل العنوان) بربط اسم المضيف بعنوان IP. على سبيل المثال، سيؤدي طلب A-record إلى Referrals.icann.org إلى إرجاع عنوان IP الخاص به - 192.0.34.164
• يقوم AAAA (سجل عنوان IPv6) بربط اسم المضيف بعنوان بروتوكول IPv6. على سبيل المثال، سيؤدي طلب سجل AAAA بالاسم K.ROOT-SERVERS.NET إلى إرجاع عنوان IPv6 الخاص به - 2001:7fd::1
• يتم استخدام CNAME (سجل الاسم المتعارف عليه) أو سجل الاسم المتعارف عليه (الاسم المستعار) لإعادة التوجيه إلى اسم آخر
• يحدد سجل MX (تبادل البريد) أو مبادل البريد خادم (خوادم) تبادل البريد لمجال معين.
• يشير سجل NS (خادم الاسم) إلى خادم DNS لمجال معين.
• يقوم سجل PTR (المؤشر) أو سجل المؤشر بربط عنوان IP الخاص بالمضيف باسمه المتعارف عليه. سيؤدي الطلب في المجال in-addr.arpa لعنوان IP المضيف في شكل عكسي إلى إرجاع الاسم (FQDN) لهذا المضيف (راجع طلب DNS العكسي). على سبيل المثال، (في وقت كتابة هذا التقرير)، بالنسبة لعنوان IP 192.0.34.164: سيؤدي طلب سجل PTR 164.34.0.192.in-addr.arpa إلى إرجاع اسمه المتعارف عليه Referrals.icann.org. لتقليل حجم المراسلات غير المرغوب فيها (البريد العشوائي)، يمكن للعديد من خوادم البريد الإلكتروني المتلقية التحقق من سجل PTR الخاص بالمضيف الذي يتم إرسال البريد الإلكتروني منه. في هذه الحالة، يجب أن يتطابق سجل PTR لعنوان IP مع اسم خادم البريد المرسل الذي يتم تقديمه إليه أثناء جلسة SMTP.
• يشير سجل SOA (بدء السلطة) أو سجل المنطقة الأولي إلى المعلومات المرجعية للخادم حول مجال معين، ويحتوي على معلومات الاتصال الخاصة بالشخص المسؤول عن هذه المنطقة، وتوقيتات تخزين معلومات المنطقة مؤقتًا والتفاعل بين خوادم DNS.
• يشير سجل SRV (اختيار الخادم) إلى خوادم الخدمات المستخدمة، على وجه الخصوص، لـ Jabber.

أسماء النطاقات المحجوزة

يحدد RFC 2606 (أسماء DNS ذات المستوى الأعلى المحفوظة) أسماء النطاقات التي يجب استخدامها كأمثلة (على سبيل المثال، في الوثائق) وأيضًا للاختبار. بالإضافة إلى example.com وexample.org وexample.net، تتضمن هذه المجموعة أيضًا اختبارًا وغير صالح وما إلى ذلك.

الهجمات على خوادم DNS

تتطلب جميع حلول برامج DNS الأمان. بعد كل شيء، إذا هاجم أحد المتسللين خادم DNS، فسيقع المستخدمون في الفخ دون أن يعرفوا ذلك.

أولا، نتيجة لهجمات DNS، يخاطر المستخدم بعدم الوصول إلى الصفحة المطلوبة. عند إدخال عنوان موقع ويب، سيقوم DNS المهاجم بإعادة توجيه الطلب إلى صفحات مزيفة.

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

معلومات المجال

تدعم العديد من نطاقات المستوى الأعلى خدمة whois، والتي تتيح لك معرفة من تم تفويض النطاق والمعلومات التقنية الأخرى.

تسجيل النطاقات

تسجيل النطاق هو إجراء الحصول على اسم النطاق. وهو يتألف من إنشاء سجلات تشير إلى مسؤول المجال في قاعدة بيانات DNS. تعتمد إجراءات التسجيل ومتطلباته على منطقة النطاق المحددة. يمكن إجراء تسجيل النطاق إما عن طريق مؤسسة مسجلة أو عن طريق فرد، إذا كانت قواعد منطقة النطاق المحددة تسمح بذلك.

يمكن إنشاء المراسلات بين أسماء النطاقات وعناوين IP إما عن طريق أدوات المضيف المحلية أو عن طريق خدمة مركزية. في الأيام الأولى للإنترنت، تم إنشاء ملف نصي بأسماء المضيفين المعروفة يدويًا على كل مضيف. يتكون هذا الملف من عدد من الأسطر، يحتوي كل منها على زوج واحد من "عنوان IP - اسم المجال"، على سبيل المثال 102.54.94.97 - rhino.acme.com.

مع نمو الإنترنت، نمت ملفات المضيفين أيضًا، وأصبح إنشاء حل قابل للتطوير لتحليل الأسماء أمرًا ضروريًا.

وكان هذا الحل خدمة خاصة - نظام اسم النطاق (DNS). DNS عبارة عن خدمة مركزية تعتمد على قاعدة بيانات تعيين عنوان IP لاسم المجال الموزع. تستخدم خدمة DNS بروتوكول خادم العميل في عملها. وهو يحدد خوادم DNS وعملاء DNS. تحتفظ خوادم DNS بقاعدة بيانات تعيين موزعة، ويقوم عملاء DNS بالاتصال بالخوادم لطلب تحويل اسم المجال إلى عنوان IP.

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

كل مجال اسم له خادم DNS الخاص به. يمكن لهذا الخادم تخزين تعيينات عنوان IP لاسم المجال للمجال بأكمله، بما في ذلك جميع نطاقاته الفرعية. ومع ذلك، فإن هذا الحل ضعيف التوسع، لأنه عند إضافة نطاقات فرعية جديدة، قد يتجاوز الحمل على هذا الخادم قدراته. في أغلب الأحيان، يقوم خادم المجال فقط بتخزين الأسماء التي تنتهي عند المستوى الأدنى التالي في التسلسل الهرمي من اسم المجال. (على غرار دليل نظام الملفات، الذي يحتوي على سجلات حول الملفات والأدلة الفرعية "المضمنة" فيه مباشرةً.) مع هذا التنظيم لخدمة DNS، يتم توزيع تحميل تحليل الاسم بالتساوي بين جميع خوادم DNS الموجودة الشبكة. على سبيل المثال، في الحالة الأولى، سيقوم خادم DNS الخاص بمجال mmtru بتخزين التعيينات لجميع الأسماء التي تنتهي بـ mmt.ru: wwwl.zil.mmt.ru، ftp.zil.mmt.ru، mail.mmt.ru، إلخ في الحالة الثانية، يقوم هذا الخادم بتخزين التعيينات فقط لأسماء مثل mail.mmt.ru وwww.mmt.ru، ويجب تخزين كافة التعيينات الأخرى على خادم DNS الخاص بالمجال الفرعي zil.

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

يشبه إجراء حل اسم DNS من نواحٍ عديدة الإجراء الخاص بنظام الملفات الذي يبحث عن عنوان ملف باسمه الرمزي. في الواقع، في كلتا الحالتين، يعكس الاسم المركب الهيكل الهرمي لتنظيم الدلائل المقابلة - أدلة الملفات أو جداول DNS. هنا يشبه خادم DNS والمجال دليل نظام الملفات. تتميز أسماء النطاقات، مثل أسماء الملفات الرمزية، باستقلال التسمية عن الموقع الفعلي.

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

هناك نظامان رئيسيان لتحليل اسم DNS. في الخيار الأول، يتم تنسيق عمل العثور على عنوان IP بواسطة عميل DNS:

يتصل عميل DNS بخادم DNS الجذري باستخدام اسم المجال المؤهل بالكامل؛

يستجيب خادم DNS بعنوان خادم DNS التالي الذي يخدم نطاق المستوى الأعلى المحدد في الجزء العلوي من الاسم المطلوب؛

يقدم عميل DNS طلبًا إلى خادم DNS التالي، والذي يرسله إلى خادم DNS للمجال الفرعي المطلوب، وهكذا حتى يتم العثور على خادم DNS الذي يخزن تعيين الاسم المطلوب إلى عنوان IP. يعطي هذا الخادم الرد النهائي للعميل.

يسمى نمط التفاعل هذا غير متكرر أو غير متكرر، عندما يقوم العميل نفسه بشكل متكرر بتنفيذ سلسلة من الطلبات إلى خوادم أسماء مختلفة. نظرا لأن هذا المخطط يقوم بتحميل العميل بعمل معقد للغاية، فنادرا ما يتم استخدامه.

ينفذ الخيار الثاني إجراءً عوديًا:

يستعلم عميل DNS عن خادم DNS المحلي، أي الخادم الذي يخدم المجال الفرعي الذي ينتمي إليه اسم العميل؛

إذا كان خادم DNS المحلي يعرف الإجابة، فإنه يعيدها على الفور إلى العميل؛ قد يتوافق هذا مع الحالة التي يكون فيها الاسم المطلوب موجودًا في نفس المجال الفرعي مثل اسم العميل، وقد يتوافق أيضًا مع الحالة التي يكون فيها الخادم قد تعلم بالفعل هذه المطابقة لعميل آخر وقام بتخزينها في ذاكرة التخزين المؤقت الخاصة به؛

إذا كان الخادم المحلي لا يعرف الإجابة، فإنه ينفذ طلبات متكررة إلى الخادم الجذر، وما إلى ذلك، بنفس الطريقة التي فعلها العميل في الخيار الأول؛ بعد تلقي الإجابة، فإنه ينقلها إلى العميل، الذي كان ينتظره طوال هذا الوقت من خادم DNS المحلي الخاص به.

في هذا المخطط، يقوم العميل بتفويض العمل إلى الخادم الخاص به، وبالتالي يسمى المخطط غير مباشر أو عودي. يستخدم جميع عملاء DNS تقريبًا إجراءً متكررًا.

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

يستخدم مكدس TCP/IP ثلاثة أنواع من العناوين: المحلية (وتسمى أيضًا الأجهزة)، وعناوين IP، وأسماء المجال الرمزية. يتم تعيين كل هذه الأنواع من العناوين لعقد الشبكة المركبة بشكل مستقل عن بعضها البعض.

يبلغ طول عنوان IP 4 بايت ويتكون من رقم الشبكة ورقم المضيف. لتحديد الحد الفاصل بين رقم الشبكة ورقم العقدة، يتم تنفيذ طريقتين. الأول يعتمد على مفهوم فئة العنوان، والثاني يعتمد على استخدام الأقنعة.

يتم تحديد فئة العنوان من خلال قيم البتات القليلة الأولى من العنوان. تخصص عناوين الفئة (أ) بايتًا واحدًا لرقم الشبكة، والبايتات الثلاث المتبقية لرقم العقدة، بحيث يتم استخدامها في أكبر الشبكات. تعد عناوين الفئات أكثر ملاءمة للشبكات الصغيرة مع، حيث يأخذ رقم الشبكة ثلاث بايت، ويمكن استخدام بايت واحد فقط لترقيم العقد. تحتل عناوين الفئة B موقعًا متوسطًا.

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

يتم تعيين أرقام الشبكة إما مركزيًا، إذا كانت الشبكة جزءًا من الإنترنت، أو عشوائيًا، إذا كانت الشبكة تعمل بشكل مستقل.

يمكن أتمتة عملية توزيع عناوين IP بين عقد الشبكة باستخدام بروتوكول DHCP.

يتم إنشاء مراسلات بين عنوان IP وعنوان الجهاز (في أغلب الأحيان عنوان MAC) بواسطة بروتوكول تحليل عنوان ARP، الذي يبحث في جداول ARP لهذا الغرض. إذا لم يكن العنوان المطلوب متاحًا، فسيتم تنفيذ طلب بث ARP.

يستخدم مكدس TCP/IP نظام تسمية رمزي للمجال، والذي يحتوي على بنية شجرة هرمية تسمح باستخدام عدد عشوائي من المكونات في الاسم. مجموعة من الأسماء التي تتطابق فيها العديد من المكونات العليا لتشكل مجال اسم. يتم تعيين أسماء النطاقات مركزيًا إذا كانت الشبكة جزءًا من الإنترنت، وإلا - محليًا.

يمكن إنشاء المراسلات بين أسماء النطاقات وعناوين IP إما عن طريق المضيف المحلي باستخدام ملف المضيفين، أو باستخدام خدمة DNS مركزية تعتمد على قاعدة بيانات موزعة لتعيينات "اسم المجال - عنوان IP".

يحل بروتوكول IP مشكلة تسليم الرسائل بين عقد الشبكة المركبة. بروتوكول IP هو بروتوكول بدون اتصال، لذا فهو لا يوفر أي ضمان لتسليم الرسائل بشكل موثوق. يتم حل جميع المشكلات المتعلقة بضمان موثوقية تسليم البيانات في شبكة مركبة في مكدس TCP/IP بواسطة بروتوكول TCP، استنادًا إلى إنشاء اتصالات منطقية بين العمليات المتفاعلة.

تتكون حزمة IP من رأس وحقل بيانات. يبلغ الحد الأقصى لطول الحزمة 65.535 بايت، ويبلغ طول الرأس عادةً 20 بايت ويحتوي على معلومات حول عناوين الشبكة الخاصة بالمرسل والمستلم ومعلمات التجزئة وعمر الحزمة والمجموع الاختباري وبعض المعلومات الأخرى. يحتوي حقل البيانات لحزمة IP على رسائل ذات طبقة أعلى، مثل TCP أو UDP.

يعتمد نوع جدول توجيه IP على التنفيذ المحدد لجهاز التوجيه، ولكن على الرغم من الاختلافات الخارجية القوية جدًا، فإن جداول جميع أنواع أجهزة التوجيه تحتوي على جميع الحقول الأساسية اللازمة لتنفيذ التوجيه.

هناك العديد من المصادر التي توفر إدخالات جدول التوجيه. أولاً، عند التهيئة، يكتب برنامج مكدس TCP/IP في جدول إدخالات للشبكات المتصلة مباشرة وأجهزة التوجيه الافتراضية، بالإضافة إلى إدخالات للعناوين الخاصة مثل 127.0.0.0. ثانيًا، يقوم المسؤول يدويًا بإدخال إدخالات ثابتة حول مسارات محددة أو جهاز التوجيه الافتراضي. ثالثًا، تقوم بروتوكولات التوجيه تلقائيًا بإدخال السجلات الديناميكية للمسارات المتاحة في الجدول.

تعتبر الأقنعة وسيلة فعالة لتنظيم شبكات IP. تسمح لك الأقنعة بتقسيم شبكة واحدة إلى عدة شبكات فرعية. تُستخدم الأقنعة ذات الطول المتساوي لتقسيم الشبكة إلى شبكات فرعية ذات حجم متساوٍ، وتُستخدم الأقنعة ذات الطول المتغير لتقسيم الشبكة إلى شبكات فرعية ذات أحجام مختلفة. يؤدي استخدام الأقنعة إلى تعديل خوارزمية التوجيه؛ لذلك، في هذه الحالة، يتم فرض متطلبات خاصة على بروتوكولات التوجيه في الشبكة، وعلى الخصائص التقنية لأجهزة التوجيه وإجراءات تكوينها.

ستلعب تقنية التوجيه غير الطبقي بين المجالات (CIDR) دورًا مهمًا في مستقبل شبكات IP، والتي تحل مشكلتين رئيسيتين. الأول هو استخدام أكثر اقتصادا لمساحة العنوان - بفضل CIDR، يستطيع مقدمو الخدمة "قص" كتل بأحجام مختلفة من مساحة العنوان المخصصة لهم بما يتفق بدقة مع متطلبات كل عميل. الهدف الثاني هو تقليل عدد إدخالات جدول التوجيه عن طريق تجميع المسارات - يمكن أن يمثل إدخال واحد في جدول التوجيه عددًا كبيرًا من الشبكات ذات بادئة مشتركة.

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

ما هو خادم DNS، وكيف يعمل خادم DNS؟

ما هو خادم DNS

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

المجال هو منطقة محددة في مساحة اسم المجال، والتي يجب أن يتم تعيين عنوان IP واحد لها على الأقل.

كيف يعمل نظام أسماء النطاقات (DNS).

يتم استخدام خدمة DNS لتعيين اسم المجال إلى عنوان IP. يتكون نظام DNS من العديد من الخوادم بمستويات مختلفة، ويجب أن يكون لكل شبكة خادم DNS خاص بها، والذي يحتوي على قاعدة بيانات محلية لسجلات DNS.

كيف تعمل:

• يقدم العميل طلبًا إلى خادم DNS المحلي، على سبيل المثال، قمت بكتابة عنوان موقع الويب في شريط العناوين بالمتصفح الخاص بك؛
• إذا كان DNS المحلي يحتوي على هذا الإدخال، فإنه يعطي الإجابة. في مثالنا، سيتلقى المتصفح عنوان IP الخاص بالموقع ويتصل به.
• إذا لم يكن لدى DNS المحلي الإدخال المطلوب، فإنه يتصل بخادم DNS التالي، وهكذا حتى يتم العثور على الإدخال.

يمكن ربط عنوان IP واحد بالعديد من أسماء النطاقات - وهذا ما يسمى بالاستضافة الافتراضية. ولكن يمكن تعيين عناوين IP متعددة لاسم مجال واحد، عادةً لتوزيع الحمل.

سجلات خادم DNS

يحتوي خادم DNS على عدة أنواع من السجلات، دعونا نلقي نظرة عليها:

سجل الخدميةينشئ منطقة للمجال، على سبيل المثال، نحتاج إلى إضافة المجال exempl.com، ثم نحتاج أولاً إلى إنشاء سجل SOA، والذي سيشير إلى الخادم الذي يتم تخزين المعلومات حول هذا المجال عليه. يحتوي سجل SOA على عدة معلمات:

1. المسلسل - الرقم التسلسلي للمنطقة. ويزداد في كل مرة يتم فيها إجراء تغييرات في مجال معين؛ وهذا ضروري لاكتشاف التغييرات من خادم DNS الثانوي وتحديد الحاجة إلى تحديث ذاكرة التخزين المؤقت الخاصة به.
2. تحديث - فترة التحديث. الفترة بالثواني التي يجب بعدها على خادم DNS الثانوي التحقق من الرقم التسلسلي للخادم الأساسي لمعرفة التغييرات، وتحديث البيانات إذا لزم الأمر.
3. إعادة المحاولة - كرر التحديث. يضبط تكرار محاولات تحديث DNS الثانوي عند فشل الاتصال بالنظام الأساسي. تعيين في ثوان.
4. انتهاء الصلاحية - فترة تخزين بيانات DNS الأساسية على البيانات الثانوية، في حالة المحاولات غير الناجحة للاتصال وتحديث البيانات.
5. TTL هو عمر السجلات لهذه المنطقة في ذاكرة التخزين المؤقت لخوادم DNS الثانوية. على سبيل المثال، العمر A لسجل منطقة معين على الخوادم الثانوية. إذا كانت البيانات تتغير بشكل متكرر، فمن المستحسن تعيين القيمة إلى قيمة صغيرة.

دخول ن.س(خادم الاسم) - يشير إلى خادم DNS لهذا المجال، أي إلى الخادم حيث يتم تخزين سجلات A.

example.com في NS ns1.ukraine.com.ua

سجل أ(سجل العنوان) - يشير هذا السجل إلى عنوان IP الخاص بالمجال.

example.com في 91.206.200.221

سجل CNAME(سجل الاسم المتعارف عليه) يشير إلى مرادف لهذا المجال، أي أنه سيتم تعيين عنوان IP لهذا المجال للمجال الذي يشير إليه هذا السجل.

example.com في CNAME xdroid.org.ua

سجل إم إكس(تبادل البريد) يشير إلى خادم البريد لهذا المجال.

example.com في MX 10 mail.example.com

يشير الرقم الإضافي الموجود أمام mail.example.com إلى قيمة الأولوية - الرقم الأصغر يعني أولوية أعلى.

سجل PTR(المؤشر) - هو عكس السجل A. يتم البحث عن عنوان IP حسب المجال باستخدام السجل A، ويتم البحث عن المجال حسب عنوان IP باستخدام سجلات PTR. من المنطقي تعيين سجلات PTR فقط على الاستضافة الفعلية، حيث أن جميع الأسماء في الاستضافة الافتراضية لها نفس عنوان IP.

هذه ليست قائمة كاملة بسجلات خادم DNS، لكننا نظرنا إلى السجلات الرئيسية.

القائمة الكاملة لسجلات DNS:

1. SOA (بداية سجل الاستناد)
2. NS (خادم الأسماء)
3. MX (تبادل البريد)
4. أ (سجل العنوان)
5. CNAME (سجل الاسم المتعارف عليه)
6. TXT (نص)
7. PTR (المؤشر)
8. SRV (اختيار الخادم)
9. AAAA (سجل عنوان IPv6)
10. AFSDB (موقع قاعدة بيانات AFS)
11. ATMA (عنوان الصراف الآلي)
12. DNAME (إعادة توجيه الاسم)
13. HINFO (معلومات المضيف)
14. ISDN (عنوان ISDN)
15. LOC (معلومات الموقع)
16. ميغابايت (صندوق البريد)
17. MG (عضو مجموعة البريد)
18. MINFO (معلومات صندوق البريد أو قائمة البريد)
19. MR (إعادة تسمية البريد)
20. NAPTR (مؤشر سلطة التسمية)
21. NSAP (عنوان NSAP)
22. RP (الشخص المسؤول)
23. RT (الطريق عبر)
24. SPF (إطار سياسة المرسل)
25. SRV (اختيار الخادم)
26. X25 (عنوان X.25 PSDN)

لا تنسى أن تغادر