প্রশ্ন কোনও ডোমেনের শীর্ষস্থানীয় (ঊর্ধ্বতন রুট) কোনও CNAME রেকর্ড ব্যবহার করা যায় না কেন?


এটা একটা ক্যানোনিকাল প্রশ্ন অঞ্চলের apices (বা শিকড়) এ CNAMEs সম্পর্কে

এটা অপেক্ষাকৃত সাধারণ জ্ঞান যে CNAME একটি ডোমেন শীর্ষে রেকর্ড একটি নিষিদ্ধ অনুশীলন।

উদাহরণ: example.com. IN CNAME ithurts.example.net.

একটি সেরা ক্ষেত্রে দৃশ্যকল্প নাম সার্ভার সফ্টওয়্যার কনফিগারেশন লোড করতে অস্বীকার করতে পারে, এবং সবচেয়ে খারাপ ক্ষেত্রে এটি এই কনফিগারেশনটি গ্রহণ করতে পারে এবং example.com এর জন্য কনফিগারেশনটি অকার্যকর করে।

সম্প্রতি আমার কাছে একটি ওয়েব হোস্টিং কোম্পানি ছিল একটি ব্যবসায়িক ইউনিট যা আমরা আমাদের ডোমেনের শীর্ষস্থানীয় CNAME নামক একটি নতুন রেকর্ডে পাঠাতে নির্দেশ প্রদান করেছি। BIND তে খাওয়ানো হলে এটি আত্মহত্যা কনফিগারেশন হবে তা জানার জন্য, আমি তাদের পরামর্শ দিয়েছি যে আমরা মেনে চলতে পারব না এবং এটি সাধারণভাবে বক পরামর্শ ছিল। ওয়েব হোস্টিং কোম্পানিটি স্ট্যান্ট ডিফাইন্যিং RFCs এবং এটি দ্বারা নিষিদ্ধ নয় এমন অবস্থান গ্রহণ করেছে তাদের সফ্টওয়্যার এটি সমর্থন করে। যদি আমরা শীর্ষস্থানীয় CNAME না করতে পারতাম তবে তাদের পরামর্শ ছিল সর্বাধিক কোন রেকর্ড নেই এবং তারা পুনঃনির্দেশক ওয়েব সার্ভার সরবরাহ করবে না। ...কি?

আমাদের অধিকাংশ জানি যে RFC1912 যে জোর দেয় A CNAME record is not allowed to coexist with any other data., কিন্তু এখানে নিজেদের সাথে সৎ হতে দিন, যে RFC শুধুমাত্র তথ্যপূর্ণ। নিকটতম আমি verbiage জানি যে অনুশীলন নিষিদ্ধ করা হয় RFC1034:

যদি একটি CNAME RR একটি নোডে উপস্থিত থাকে তবে অন্য কোনও তথ্য থাকা উচিত নয়   উপস্থিত; এটি একটি ক্যানোনিকাল নাম এবং তার উপনাম জন্য তথ্য নিশ্চিত করে   ভিন্ন হতে পারে না।

দুর্ভাগ্যবশত আমি এতদিন ধরে শিল্পে ছিলাম যে "উচিত নয়" "না" হিসাবে একই না হওয়া উচিত এবং এটি বেশিরভাগ সফ্টওয়্যার ডিজাইনারদের জন্য নিজেদের সাথে ঝুলতে যথেষ্ট দড়ি। একটি স্ল্যাম ড্যাঙ্কের সংক্ষিপ্ত লিঙ্কের যেকোনও কিছু আমার সময়ের অপচয় হতে পারে তা জানার জন্য, আমি কোম্পানিকে কনফিগারেশনগুলির সুপারিশ করার জন্য একটি দোষ দিয়ে দূরে যেতে দেই, যা যথাযথ প্রকাশ ছাড়াই সাধারণভাবে ব্যবহৃত সফ্টওয়্যারটি ভাঙতে পারে।

এই আমাদের প্রশ্ন & এ এনেছে। একবার আমরা আমাদের পেতে চাই সত্যিই শীর্ষস্থানীয় CNAMEs এর উন্মাদনা সম্পর্কে প্রযুক্তিগত, এবং বিষয়টিকে প্রায়শই স্কার্ট হিসাবে নয়, যখন আমরা এই বিষয়টিতে পোস্ট করি তখন সাধারণত আমরা করি। RFC1912 সীমার বাইরে, অন্য যে কোনও তথ্যপূর্ণ RFC এখানে প্রযোজ্য যা আমি মনে করি না। আসুন এই শিশুর বন্ধ।


108
2017-07-19 10:53


উত্স


RFC 1034 বেশ কিছু সময় এবং অভিজ্ঞতা দ্বারা RFC 2119 পূর্বাভাস দেয়। - Michael Hampton♦


উত্তর:


CNAME রেকর্ড ছিল মূলত সংস্থার জন্য একটি একক "ক্যানোনিক্যাল নাম" থেকে আলাদা করার জন্য একই সংস্থান সরবরাহকারী একাধিক নামের অনুমতি দেওয়ার জন্য তৈরি করা হয়েছে। নাম ভিত্তিক ভার্চুয়াল হোস্টিংয়ের আবির্ভাবের সাথে, এটি আইপি ঠিকানা আলাইজিংয়ের জেনেরিক ফর্ম হিসাবে ব্যবহার করার পরিবর্তে এটি সাধারণ হয়ে উঠেছে। দুর্ভাগ্যবশত, একটি ওয়েব হোস্টিং পটভূমি থেকে আসা অধিকাংশ মানুষ আশা CNAME নির্দেশ নির্দেশ ডিএনএস সমার্থকতা, যা উদ্দেশ্য ছিল না। শীর্ষে রেকর্ড ধরনের যা রয়েছে না একটি ক্যানোনিকাল হোস্ট সম্পদ সনাক্তকরণ ব্যবহৃত (NS, SOA), যা একটি মৌলিক স্তরের মান ভাঙা ছাড়া aliased করা যাবে না। (বিশেষ করে ক্ষেত্রে জোন কাটা)

দুর্ভাগ্যবশত, মূল ডিএনএস স্ট্যান্ডার্ডগুলি মানসম্মত সংস্থাগুলি বুঝতে পেরেছিল যে সুস্পষ্ট শব্দের ধারাবাহিক আচরণ সংজ্ঞায়িত করার প্রয়োজনীয়তা ছিল তা উপলব্ধি করার আগে (আরএফসি 2119)। এটা তৈরি করা প্রয়োজন ছিল আরএফসি 2181 অস্পষ্ট শব্দকরণের কারণে বিভিন্ন কোণার ক্ষেত্রে স্পষ্ট করার জন্য, এবং আপডেট করা শব্দটি এটি পরিষ্কার করে তোলে যে a CNAME  না পারেন স্ট্যান্ডার্ড ভঙ্গ ছাড়াই শীর্ষ aliasing অর্জন করতে ব্যবহার করা হবে।

6.1। জোন কর্তৃপক্ষ

একটি জোন জন্য কর্তৃত্বপূর্ণ সার্ভার এনএস রেকর্ডের মধ্যে enumerated হয়      জোন উৎপত্তি, যা, কর্তৃপক্ষের একটি সূত্র বরাবর      (এসওএ) রেকর্ড প্রতিটি জোন বাধ্যতামূলক রেকর্ড।  যেমন একটি সার্ভার      কোনও অঞ্চলের সমস্ত সংস্থানের রেকর্ডগুলির জন্য অনুমোদিত নয়      অন্য জোন। একটি জোন কাট নির্দেশ করে যে NS রেকর্ড হয়      শিশু জোন সম্পত্তি, যেমন জন্য অন্য কোন রেকর্ড হিসাবে তৈরি      যে সন্তানের অঞ্চল, বা এর কোন উপ-ডোমেন উৎপত্তি। একটি জন্য একটি সার্ভার      অঞ্চল সম্পর্কিত প্রশ্নের জন্য আধিকারিক উত্তর ফেরত করা উচিত নয়      অন্য অঞ্চলে নাম, যা এনএস, এবং সম্ভবত একটি, রেকর্ড অন্তর্ভুক্ত      একটি জোন কাট এ, এটি অন্যের জন্য একটি সার্ভার হতে না হওয়া পর্যন্ত      মণ্ডল.

এই যে প্রতিষ্ঠিত SOA এবং NS রেকর্ড বাধ্যতামূলক, কিন্তু এটি সম্পর্কে কিছুই বলে না A অথবা এখানে প্রদর্শিত অন্যান্য ধরনের। এটা অসম্ভব বলে মনে হতে পারে যে আমি এইটি উদ্ধৃত করেছি, তবে এটি একটি মুহুর্তে আরও প্রাসঙ্গিক হয়ে উঠবে।

আরএফসি 1034 একটি যখন উঠতে পারে যে সমস্যা সম্পর্কে কিছুটা অস্পষ্ট ছিল CNAME অন্যান্য রেকর্ড ধরনের বরাবর বিদ্যমান। আরএফসি 2181 অস্পষ্টতা দূর করে এবং তাদের পাশাপাশি বিদ্যমান থাকতে পারে এমন রেকর্ড ধরনের স্পষ্টভাবে উল্লেখ করে:

10.1। CNAME সম্পদ রেকর্ড

DNS CNAME ("ক্যানোনিকাল নাম") রেকর্ডটি সরবরাহ করার জন্য বিদ্যমান      একটি উপনাম নাম সঙ্গে যুক্ত ক্যানোনিক্যাল নাম। শুধুমাত্র এক হতে পারে      যেকোনো একটি উপনাম জন্য যেমন ক্যানোনিকাল নাম। যে নাম সাধারণত করা উচিত      এমন একটি নাম যা DNS এর অন্যত্র বিদ্যমান, যদিও কিছু বিরল      সহগামী ক্যানোনিকাল নাম সঙ্গে উপাধি জন্য অ্যাপ্লিকেশন      DNS এ অনির্ধারিত। একটি উপনাম নাম (একটি CNAME রেকর্ড লেবেল) হতে পারে,      যদি DNSSEC ব্যবহারে থাকে, তবে SIG, NXT, এবং KEY RR আছে, তবে এটি থাকতে পারে      অন্যান্য তথ্য।  অর্থাৎ, 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 রেকর্ড। বুলেটযুক্ত তালিকাটি স্পষ্টভাবে পরিষ্কার করে দেয় যে a SOA, NS, এবং A রেকর্ড একটি নোড এ দেখা যাবে না যেখানে একটি CNAME এছাড়াও প্রদর্শিত হবে। যখন আমরা ধারা 6.1 এর সাথে এটি একত্রিত করি, এটির জন্য এটি অসম্ভব CNAME এটি বাধ্যতামূলক বরাবর বাস করতে হবে হিসাবে শীর্ষস্থানে বিদ্যমান SOA এবং NS রেকর্ড।

(এই কাজটি মনে হয়, কিন্তু যদি প্রমাণের জন্য একটি ছোট পথ থাকে তবে দয়া করে এতে একটি ক্র্যাক দিন।)


হালনাগাদ:

মনে হচ্ছে যে সাম্প্রতিক বিভ্রান্তি আসছে ক্লাউডফেলার এর সাম্প্রতিক সিদ্ধান্ত ডোমেনের শীর্ষস্থানে একটি অবৈধ CNAME রেকর্ড সংজ্ঞায়িত করার অনুমতি দিতে, যার জন্য তারা একটি রেকর্ড সংশ্লেষ করবে। লিঙ্কযুক্ত নিবন্ধটি বর্ণিত হিসাবে "RFC সম্মতিপ্রাপ্ত" প্রকৃতপক্ষে ক্লাউডফেলার দ্বারা সংশ্লেষিত রেকর্ডগুলি DNS এর সাথে চমত্কারভাবে খেলবে। এটি একটি সম্পূর্ণ কাস্টম আচরণ যে সত্য পরিবর্তন করে না।

আমার মতে এটি বৃহত্তর DNS সম্প্রদায়ের জন্য একটি অসদাচরণ: এটি আসলে একটি CNAME রেকর্ড নয়, এবং এটি বিশ্বাস করে যে অন্য সফ্টওয়্যারটি এটির অনুমতি না দেওয়ার জন্য অপ্রতুল। (আমার প্রশ্ন হিসাবে দেখায়)


87
2017-07-19 10:53



আমি এই প্রমাণের সাথে একমত এবং আমি মনে করি না প্রমাণের এই দুটি ধাপের পথটি বিশেষত লম্বা বা দৃঢ়। (1. জোন Apex অন্তত আছে নিশ্চিত করা হয় SOA + + NS রেকর্ড, 2। CNAME রেকর্ড অন্যান্য তথ্য সহ coexist করার অনুমতি দেওয়া হয় না) - Håkan Lindqvist
সামগ্রিকভাবে, আমি মনে করি এটি একটি খুব ভাল ব্যাখ্যা। কিছু যোগ করা যেতে পারে, আমি সম্ভবত এটি আরো ব্যাখ্যা করা হবে কি একটি CNAME রেকর্ড আসলে মানে, যে সম্ভবত সবচেয়ে ব্যাপকভাবে ভুল ধরনের রেকর্ড। যদিও এটি বিন্দু অতিক্রমের মতো, তবে আমি মনে করি এটি একটি প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী হল এটির একটি সঠিক ফলাফল নয় (সর্বাধিক?) CNAME। - Håkan Lindqvist
@ ডেনিস যেটি একটি মন্তব্যের মধ্যে ব্যাপকভাবে উত্তর দেওয়া যাবে না। সংক্ষিপ্ততম উত্তর হল আপনার RFCs (1034, 1035) পড়তে হবে এবং রেফারালগুলি কী, তা রেফারেলের প্রয়োজনীয় আচরণ (AUTHORITY, SOA রেকর্ড উপস্থিতি, ইত্যাদি) এবং কেন এই ধরণের "রেফারেল-কম" অ্যালাইজিং ক্রিয়ামূলক পর্যায়ে DNS সার্ভারগুলির অনেক প্রত্যাশা লঙ্ঘন করে। এবং যে ঠিক সঙ্গে শুরু। এই প্রশ্নটি এখানে জন্য একটি ভাল বিষয় নয় কারণ এটি কোনও সমস্যাযুক্ত এবং এটি সঠিকভাবে পরিকল্পিত, মানক সম্মতিশীল DNS সার্ভারের সাথে কাজ করতে পারে এমন একটি সমস্যাতে মূলত না। - Andrew B
@ ডেনিসহো সংক্ষিপ্তভাবে: NS এবং SOA রেকর্ড ছাড়া "একটি ডোমেন" এর মতো কোনও জিনিস নেই। যারা অ-ঐচ্ছিক রেকর্ড। - hakamadare
@ ইকোভো এক HTTP প্রয়োগকরণ দাবী করা উচিত যুক্তি দিতে পারেন SRV পরিবর্তে, এটিও এটি একটি অ-ইস্যু তৈরি করেছে। সমস্যা এখানে আলোচনা করা হয় কি সীমাবদ্ধ নয়; CNAME হয়, জনপ্রিয় বিশ্বাস বিপরীত, প্রয়োজন কি জন্য একটি মহান ম্যাচ নয়। শেষ পর্যন্ত, হিসাবে CNAME মানুষের মত কাজ করে না (!) এবং retroactively পুনরায় ডিজাইন করা যাবে না এবং HTTP বাস্তবায়ন হিসাবে ব্যবহার করা হয় না SRV মনে হচ্ছে যে "ওরফে" স্টাইল কার্যকারিতাটি HTTP এর পরিপূরক হওয়ার ক্ষেত্রে আরও বেশি প্রযোজ্য বলে মনে হয় (রেকর্ড দৃশ্যের নির্দিষ্ট ধরনের আলাইজিং দৃশ্যমান রেকর্ড টাইপের চেয়ে দৃশ্যগুলির পিছনে বাস্তবায়িত) - Håkan Lindqvist


আপনি যদি সম্পূর্ণ অঞ্চলটি পুনঃনির্দেশিত করেন তবে আপনাকে DNAME ব্যবহার করতে হবে। অনুসারে আরএফসি 667২,

DNAME RR এবং CNAME RR [RFC1034] একটি সন্ধানের কারণ করে      (সম্ভাব্য) একটি ডোমেন নাম পৃথক তথ্য ফেরত      জিজ্ঞাসিত ডোমেইন নাম থেকে। দুই মধ্যে পার্থক্য      সম্পদ রেকর্ডগুলি হল যে CNAME RR তথ্য সন্ধানের নির্দেশ দেয়      তার মালিক অন্য একক নাম, যেখানে একটি DNAME RR লুকআপ দেখায়      অনুরূপ নাম তার মালিক এর নাম বংশধর তথ্য জন্য      গাছের একটি পৃথক (একক) নোড অধীনে।

উদাহরণস্বরূপ, একটি জোন মাধ্যমে দেখুন (দেখুন 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 প্রকারের জন্য অনুসন্ধান করেন তবে আপনি এখনও একটি ম্যাচ পাবেন বর্তমান শীর্ষ নাম জন্য। থেকে আরএফসি 667২: "যদি কোনও অঞ্চলের ডিএনএ রেকর্ড জোনের শীর্ষস্থানে উপস্থিত থাকে তবে সেখানেও রীতিমতো SOA এবং NS সম্পদ রেকর্ড থাকা দরকার। এই ধরনের একটি DNAME ব্যবহার করতে পারা যায় না আয়না একটি অঞ্চল সম্পূর্ণরূপে, এটি না আয়না জোন Apex। " - Quuxplusone