سؤال لماذا لا يمكن استخدام سجل CNAME في قمة (الملقب الجذر) من المجال؟


هذا ال السؤال الكنسي حول CNAMEs في apices (أو الجذور) للمناطق

انها معرفة مشتركة نسبيا ذلك CNAME السجلات في قمة المجال هي ممارسة محظورة.

مثال: example.com. IN CNAME ithurts.example.net.

في أفضل الحالات ، قد يرفض برنامج خادم الأسماء تحميل التهيئة ، وفي أسوأ الحالات ، قد يقبل هذا التهيئة ويفصل التكوين عن example.com.

لقد حصلت مؤخرًا على تعليمات بتمرير شركة Webhosting إلى وحدة أعمال كنا بحاجة إلى CNAME في قمة نطاقنا إلى سجل جديد. مع العلم أن هذا سيكون بمثابة إعداد انتحار عند إطعامه إلى BIND ، نصحتهم بأننا لن نكون قادرين على الامتثال ، وأن هذا كان نصيحة السرير العادي بشكل عام. اتخذت شركة استضافة المواقع موقفًا مفاده أنه غير محظور تمامًا من خلال تعريف RFCs القياسية هم البرنامج يدعم ذلك. إذا لم نتمكن من استخدام CNAME في القمة ، فكانت نصيحتهم عدم وجود سجل قمة على الإطلاق ، ولم يقدموا خادم ويب يعيد التوجيه. ...ماذا؟

معظمنا يعرف ذلك RFC1912 يصر على ذلك A CNAME record is not allowed to coexist with any other data.، ولكن دعونا نكون صادقين مع أنفسنا هنا ، أن RFC هو إعلامي فقط. وأقرب ما أعرفه عن الإسهاب الذي يحظر الممارسة هو من RFC1034:

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

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

هذا يقودنا إلى سؤال وجواب. لمرة واحدة أود أن نحصل عليها هل حقا تقنية حول الجنون من قمة CNAMEs ، وعدم التنورة حول هذه القضية كما نفعل عادة عندما ينشر شخص ما حول هذا الموضوع. RFC1912 خارج الحدود ، كما هو الحال مع أي RFC إعلامي آخر ينطبق هنا لم أفكر فيه. دعونا نغلق هذا الطفل.


108
2017-07-19 10:53


الأصل


RFC 1034 يسبق RFC 2119 بقليل من الوقت والخبرة. - Michael Hampton♦


الأجوبة:


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

لسوء الحظ ، تمت كتابة معيار DNS الأصلي قبل أن تتحقق هيئات إدارة المعايير من أنه كان من الضروري وجود تعبير صريح لتحديد السلوك المتسق (RFC 2119). كان من الضروري إنشاء RFC 2181 لتوضيح العديد من حالات الزوايا بسبب الصياغة الغامضة ، والتوضيح المحدث يجعل الأمر أكثر وضوحًا CNAME  لا تستطيع يمكن استخدامها لتحقيق قمة التعرج دون كسر المعيار.

6.1. سلطة المنطقة

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

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

RFC 1034 كان غامضا نوعا ما حول المشاكل التي يمكن أن تنشأ عند CNAME موجود جنبا إلى جنب مع أنواع السجلات الأخرى. RFC 2181 يزيل الغموض ويذكر صراحة أنواع السجلات المسموح لها بالتواجد بجانبها:

10.1. سجلات مورد CNAME

يوجد سجل DNS CNAME ("الاسم الأساسي") لتوفير      الاسم المتعارف عليه المرتبط باسم مستعار. قد يكون هناك واحد فقط      مثل هذا الاسم المتعارف عليه لأي اسم مستعار. يجب أن يكون هذا الاسم بشكل عام      اسم موجود في مكان آخر في DNS ، على الرغم من أن هناك بعض النادر      تطبيقات للأسماء المستعارة مع الاسم القانوني المرافقة      غير معروف في DNS. قد الاسم المستعار (تسمية سجل CNAME) ،      إذا كان DNSSEC قيد الاستخدام ، يكون SIG و NXT و RR KEY ، ولكن قد لا يكون      بيانات أخرى.  وهذا هو ، لأي تسمية في DNS (أي اسم المجال)      بالضبط واحد مما يلي صحيح:

 + one CNAME record exists, optionally accompanied by SIG, NXT, and
   KEY RRs,
 + one or more records exist, none being CNAME records,
 + the name exists, but has no associated RRs of any type,
 + the name does not exist at all.

"الاسم المستعار" في هذا السياق يشير إلى الجانب الأيسر من CNAME سجل. تجعل القائمة النقطية من الواضح بشكل واضح أن SOA، NSو A لا يمكن رؤية السجلات في العقدة حيث CNAME يبدو أيضا. عندما ندمج هذا مع القسم 6.1 ، فإنه من المستحيل ل CNAME إلى الوجود في القمة حيث سيكون عليه أن يعيش إلى جانب إلزامي SOA و NS السجلات.

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


تحديث:

يبدو أن الارتباك الأخير يأتي من قرار Cloudflare الأخير للسماح بتعريف سجل CNAME غير قانوني في قمة النطاقات ، حيث سيقوم بتجميع سجلات A. تشير عبارة "متوافقة مع RFC" كما هو موضح في المقالة المرتبطة إلى حقيقة أن السجلات التي تم توليفها بواسطة Cloudflare ستعمل بشكل جيد مع DNS. هذا لا يغير حقيقة أنه سلوك مخصص تمامًا.

في رأيي ، هذا يضر بمجتمع DNS الأكبر: ليس في الواقع سجل CNAME ، وهو يضلل الناس للاعتقاد بأن البرامج الأخرى غير كافية لعدم السماح بها. (كما يوضح سؤالي)


87
2017-07-19 10:53



أوافق على هذا الدليل ، ولا أعتقد أن مسار الإثبات هذا خطوة طويلة أو معقدة. (1) ضمان قمة المنطقة على الأقل SOA + NS سجلات ، 2. CNAME لا يسمح للسجلات بالتعايش مع البيانات الأخرى) - Håkan Lindqvist
عموما ، أعتقد أنه تفسير جيد للغاية. إذا أمكن إضافة أي شيء ، أعتقد أنه من الممكن أن يفسر ما هو أ CNAME سجل يعني في الواقع ، لأن هذا هو على الأرجح نوع السجل الذي يساء فهمه على نطاق واسع. على الرغم من أن هذا هو أبعد من النقطة ، وأعتقد أن هذا هو السؤال الشائع هو نتيجة مباشرة للكثير (معظم؟) عدم وجود فهم صحيح لل CNAME. - Håkan Lindqvist
Denis لا يمكن الإجابة عليها بشكل شامل في تعليق. أقصر إجابة هي أنك تحتاج إلى قراءة RFCs (1034 ، 1035) وأن يكون لديك فهم جيد لماهية الإحالات ، ما هي السلوكيات المطلوبة للإحالة (AUTHORITY ، SOA ، ووجود السجلات ، وما إلى ذلك) ، ولماذا هذا النوع من "الاسم المستعار أقل الإحالة" ينتهك العديد من التوقعات لخوادم DNS على المستوى الوظيفي. وهذا فقط لتبدأ. هذا السؤال ليس موضوعًا جيدًا هنا لأنه تأملي وليس متجذرًا في مشكلة قد تواجهها عند التعامل مع خادم DNS متوافق تمامًا مع المعايير. - Andrew B
DenisHowe باختصار: لا يوجد شيء اسمه "مجال" بدون سجلات NS و SOA. هذه هي السجلات غير الاختيارية. - hakamadare
Ekevoo يمكن للمرء أن يجادل تطبيقات HTTP يجب أن اعتمدت SRV بدلا من ذلك ، من شأنه أن يجعل هذا أيضا غير قضية. لا تقتصر المشكلة على ما يناقش هنا ؛ CNAME هو ، على عكس الاعتقاد الشائع ، لا تطابق كبير لما هو مطلوب. في النهاية ، مثل CNAME لا يعمل مثل الناس يتوقعون (!) ولا يمكن إعادة تصميمه بأثر رجعي وكما لا تستخدم تطبيقات HTTP SRV يبدو أكثر احتمالية أن تصبح وظيفة النمط "المستعار" أكثر شيوعًا لتلائم HTTP (نوع معين من الأسماء المستعارة تم تطبيقه خلف الكواليس وليس كنوع سجل مرئي) - Håkan Lindqvist


إذا كنت تعيد توجيه منطقة بأكملها ، فيجب عليك استخدام DNAME. بالنسبة الى RFC 6672،

تؤدي DNAME RR و CNAME RR [RFC1034] إلى البحث عن      (احتمال) إرجاع البيانات المقابلة لاسم نطاق مختلف      من اسم المجال المستعلم عنها. الفرق بين الاثنين      سجلات المورد هي أن CNAME RR يوجه عملية البحث عن البيانات في      صاحبه إلى اسم واحد آخر ، في حين يوجه مرجع الاسم المميز لـ DNAME عمليات البحث      للبيانات عند أحفاد اسم مالكها إلى الأسماء المقابلة      تحت عقدة (واحدة) مختلفة من الشجرة.

على سبيل المثال ، يمكنك الاطلاع على منطقة ما (انظر RFC 1034 [RFC1034] ،      القسم 4.3.2 ، الخطوة 3) لاسم النطاق "foo.example.com" ، و      تم العثور على سجل مورد DNAME في "example.com" مشيرًا إلى أن الكل      سيتم توجيه الاستعلامات الموجودة ضمن "example.com" إلى "example.net". البحث      ستعود العملية إلى الخطوة 1 مع اسم الاستعلام الجديد      "foo.example.net". هل كان اسم الاستعلام هو "www.foo.example.com" ،      سيكون اسم الاستعلام الجديد هو "www.foo.example.net".


0
2018-03-27 15:41



هذا هو تفسير غير صحيح. الرجوع إلى السطر الثاني من الجدول في RFC 6672 §2.2. لن يؤدي ذروة DNAME إلى مطابقة أنواع طلبات البحث بخلاف DNAME في القمة ، أي لا يؤدي إلى اسم مستعار فعلي لسجل ذروة A أو AAAA. - Andrew B
سيؤدي ذروة DNAME إلى لا إعادة توجيه للاستعلامات من اسم قمة. ليس صحيحًا تقنيًا أن تقول أنه سيؤدي إلى عدم مباراة. ستظل تحصل على تطابق إذا قمت بالبحث عن NS أو SOA أو أي أنواع RR أخرى موجودة بالفعل حاضر لاسم القمة. من عند RFC 6672: "إذا كان سجل DNAME موجودًا في قمة المنطقة ، فلا تزال هناك حاجة إلى وجود سجلات الموارد العادية SOA و NS أيضًا. لا يمكن استخدام DNAME هذا مرآة منطقة تماما ، لأنها لا تفعل ذلك مرآة قمة المنطقة ". - Quuxplusone