क्या वाइल्डकार्ड DNS रिकॉर्ड खराब प्रैक्टिस है?

Question

मैंने अपने होस्टर से तीन सबडोमेन को जोड़ने के लिए कहा, जो एक रिकॉर्ड के आईपी की ओर इशारा करते हैं। ऐसा लगता है कि उन्होंने केवल एक वाइल्डकार्ड डीएनएस रिकॉर्ड जोड़ा है क्योंकि कोई भी यादृच्छिक उपडोमेन अब मेरे आईपी में बदल जाता है। यह मेरे लिए तकनीकी दृष्टि से ठीक है, क्योंकि कहीं और कोई उप डोमेन इंगित नहीं कर रहा है। फिर मैं उसे पसंद नहीं करता जो मैंने पूछा था। और इसलिए मुझे आश्चर्य है कि क्या उसे बदलने के लिए कहने के अन्य कारण हैं। क्या वहां पर कोई?

केवल नकारात्मक मैंने पाया कि कोई मेरी साइट का उपयोग करके लिंक कर सकता है http://i.dont.like.your.website.mywebsite.tld।

Comments

कोई " i.dont.like.your.website.mywebsite.tld " का उपयोग करके आपके सर्वर से लिंक कर सकता है, लेकिन आपका सर्वर तब तक प्रतिक्रिया नहीं दे सकता है जब तक कि वह इसका जवाब देने के लिए कॉन्फ़िगर नहीं किया जाता है (होस्टहेड या वर्चुअलहॉस्ट्स के माध्यम से)।

— जोकेवर्टी

कुछ मामलों में वाइल्डकार्ड की आवश्यकता हो सकती है। उदाहरण के लिए, वर्डप्रेस जैसे मल्टी-टेनेंट वेबैप को उप-डोमेन का उपयोग करके स्वचालित रूप से नए इंस्टेंस को कॉन्फ़िगर करने के लिए कॉन्फ़िगर किया जा सकता है - जैसे साइट 1।blog.example.com, site2.blog.example.com - इसके लिए वाइल्डकार्ड के साथ *.blog.example.com, आप डॉन इनमें से प्रत्येक को व्यक्तिगत रूप से कॉन्फ़िगर करने की आवश्यकता नहीं है।

— jscott

Answer 1

यदि आप कभी भी उस डोमेन में एक कंप्यूटर डालते हैं, तो आपको विचित्र डीएनएस विफलताएं मिलेंगी, जहां जब आप इंटरनेट पर कुछ यादृच्छिक साइट पर जाने का प्रयास करते हैं, तो आप इसके बजाय आपके पास पहुंचते हैं।

विचार करें: आप डोमेन के मालिक हैं example.com। आप अपना वर्कस्टेशन सेट करते हैं और उसे नाम देते हैं। ... आइए कहते हैं, yukon.example.com। अब आप देखेंगे कि इसकी /etc/resolv.confलाइन है:

search example.com

यह सुविधाजनक है क्योंकि इसका मतलब है कि आप होस्टनाम लुकअप के लिए कर सकते हैं, उदाहरण के लिए wwwजो तब www.example.comआपके लिए स्वचालित रूप से खोज करेगा। लेकिन इसका एक स्याह पक्ष है: यदि आप Google पर जाते हैं, कहते हैं, तो यह खोज करेगा www.google.com.example.com, और यदि आपके पास वाइल्डकार्ड डीएनएस है, तो वह आपकी साइट पर हल हो जाएगा, और Google तक पहुंचने के बजाय आप अपनी साइट पर हवा करेंगे।

यह उस सर्वर पर समान रूप से लागू होता है जिस पर आप अपनी वेब साइट चला रहे हैं! यदि इसे कभी बाहरी सेवाओं को कॉल करना है, तो होस्टनाम लुकअप उसी तरह से विफल हो सकता है। तो api.twitter.comउदाहरण के लिए अचानक बन जाता है api.twitter.com.example.com, मार्ग सीधे आपकी साइट पर वापस आ जाता है , और निश्चित रूप से विफल हो जाता है।

यही कारण है कि मैं वाइल्डकार्ड डीएनएस का उपयोग कभी नहीं करता हूं ।

Comments

@ChrisLively "सहायक" होने और इसे जोड़ने के लिए आधुनिक लिनक्स सिस्टम को दोष देते हैं। BTW, ".local" का उपयोग करना वास्तव में बुरा अभ्यास है, और न केवल विंडोज वातावरण में।

— माइकल हैम्पटन

मैंने वास्तव में विंडोज वातावरण के संबंध में इस बारे में ब्लॉग किया है । यह उल्लेख करने के लिए नहीं कि कम से कम तीन समूहों ने अब .lLD TLD पर बोली लगाई है कि ICANN उन्हें पर्याप्त पर्याप्त बटुए के साथ किसी को भी बेच रहा है। .localआरक्षित नहीं है और इसका उपयोग नहीं किया जाना चाहिए। ऐसा करने से RFC का उल्लंघन होता है और यह बिल्कुल भी आवश्यक नहीं है। आंतरिक संसाधनों जैसे कि एक प्रतिनिधि तीसरे स्तर के उपडोमेन का उपयोग करना सबसे अच्छा अभ्यास है internal.company.com। सिर्फ इसलिए कि आप कुछ देखते हैं यह सही नहीं है।

— एमडीएमरा

क्या आप कृपया मुझे RFC 2606 के सेक्शन की ओर संकेत कर सकते हैं जो आरक्षित है .local? मैंने इस RFC को कम से कम एक दर्जन बार लोगों के साथ पढ़ा है जो इस तर्क में इसका उपयोग करते हैं और मैं आपको निश्चितता के साथ बता सकता हूं कि यह नहीं है।

— एमडीमैरा

@Zypher यह वास्तव में Microsoft द्वारा अनुशंसित नहीं था (यह मेरे ब्लॉग पोस्ट में भी डिबंक किया गया है। इसे पढ़ें, यह एक अच्छा है), लेकिन यह तथ्य कि एसबीएस ने .localडिफ़ॉल्ट रूप से उपयोग किए गए एमएस को उस संबंध में गड़बड़ की तरह देखा। एसबीएस ने उस कॉन्फ़िगरेशन के साथ भेज दिया क्योंकि यह कम तकनीकी ज्ञान वाले गैर-तकनीकी ग्राहकों के लिए था। यह कम से कम प्रतिरोध का मार्ग था, लेकिन वास्तविक AD डॉक्स W2K युग में सभी तरह से एक तीसरे स्तर के उपडोमेन की सिफारिश करते हैं।

— एमडीएमरा

ओह, और कुछ वर्षों में प्रमाण पत्र प्राप्त करना बहुत मुश्किल होने वाला है। Lync / एक्सचेंज के लिए UCC / SAN सेर्ट्स का मतलब है जो एक आंतरिक CA द्वारा हस्ताक्षरित किया जाना चाहिए, यदि आप बाहरी गैर-डोमेन में शामिल हो गए हैं तो यह दर्दनाक हो सकता है। उपयोगकर्ताओं।

— एमडीएमरा

Answer 2

क्या वाइल्डकार्ड DNS रिकॉर्ड खराब प्रैक्टिस है?

व्यक्तिगत रूप से, मुझे यह पसंद नहीं है। खासकर जब उस डोमेन में मशीनें हों। टाइपो अनियंत्रित हो जाते हैं, त्रुटियां कम स्पष्ट होती हैं ... लेकिन इसमें मूलभूत रूप से कुछ भी गलत नहीं है।

केवल नकारात्मक मैंने पाया है कि कोई व्यक्ति http: //i.dont.like.your.website.mywebsite.tld का उपयोग करके मेरी साइट से लिंक कर सकता है ।

अपने http सर्वर को ऐसे सभी अनुरोधों को उचित, विहित पते पर पुनर्निर्देशित करें, या बिल्कुल भी जवाब न दें। Nginx के लिए कुछ इस तरह होगा :

server {
    listen 80;
    server_name *.mywebsite.tld;
    return 301 $scheme://mywebsite.tld$request_uri;
    }

और फिर नियमित

server {
    listen  80;
    server_name mywebsite.tld;
    [...]
    }

Answer 3

यह सब राय का विषय है। मेरे लिए यह बुरा अभ्यास नहीं है।

मैं एक मल्टी-टेनेंट ऐप बना रहा हूं जो प्रति किरायेदार एक डेटाबेस का उपयोग करता है। यह तब उपडोमेन के आधार पर उपयोग किए जाने वाले डेटाबेस का चयन करता है।

उदाहरण के लिए डेटाबेस का milkman.example.comउपयोग करेगा tenant_milkman।

इस तरह मैं एक किरायेदार के लिए टेबल अलग किया है, जैसे, tenant_milkman.users, tenant_fisherman.users, tenant_bobs_garage.users, मेरी राय में एक बहुत बड़ा बहुत आसान बजाय एक ही तालिका में सभी कंपनियों से सभी उपयोगकर्ताओं होने के, इस विशिष्ट अनुप्रयोग के लिए बनाए रखने के लिए है।

[edit - Michael Hampton has a good point]

कहा जा रहा है, अगर आपके पास किसी भी (चर) उपडोमेन को स्वीकार करने का कोई विशिष्ट कारण नहीं है, जैसे कि मैं करता हूं, तो आपको उन्हें स्वीकार नहीं करना चाहिए।

Comments

वाइल्डकार्ड DNS का उपयोग करने के लिए आपके पास एक अच्छा तकनीकी कारण है। ज्यादातर लोग नहीं करते हैं।

— माइकल हैम्पटन

तथ्य की बात के रूप में, यह मेरे लिए अत्यधिक खतरनाक लगता है - यह आपको डोमेन नाम बदलकर एक मनमाना डेटाबेस तक पहुंचने की अनुमति देता है। मेरा तर्क है कि यह इंजेक्शन भेद्यता का एक प्रकार है। बेशक यह जरूरी शोषक नहीं है - लेकिन क्यों संभावना है?

— सालेके

@ स्लेसके यह नहीं है, क्योंकि उपयोगकर्ता को उस उप डोमेन (उस डेटाबेस के लिए) के खिलाफ प्रमाणित करना होगा। यदि वह स्विच करता है, तो उसे फिर से प्रमाणित करने की आवश्यकता होगी, क्योंकि इसे पूरी तरह से अलग "साइट" के रूप में देखा जाता है।

— पेड्रो मोरिरा

@PedroMoreira: हाँ, जो हमले की सतह को कम करता है। फिर भी, मनमाने डेटाबेस तक पहुँच प्रदान करना खतरनाक लगता है। उदाहरण के लिए, क्या होगा यदि समान क्रेडेंशियल के साथ बैकअप डेटाबेस है, लेकिन डेटा जो मुख्य डीबी से शुद्ध किया गया था - यह किसी को भी एक्सेस करने की अनुमति देगा जो नाम जानता है। फिर भी, मुझे एहसास है कि सुरक्षा हमेशा एक व्यापार है - बस निहित खतरे को इंगित करना चाहता था।

— सालेस्के

@ स्लेसके यही कारण है कि सभी सुलभ डेटाबेस के साथ उपसर्ग हैं tenant_। मैंने यह सुनिश्चित कर लिया कि आवेदन उनसे जुड़ भी नहीं सकता।

— पेड्रो मोरिरा

Answer 4

यहां एक और मुद्दा एसईओ है: यदि सभी *.example.comएक ही सामग्री दिखा रहे हैं, तो आपकी वेबसाइट को बुरी तरह से संदर्भित किया जाएगा, कम से कम Google ( https://support.google.com/webmasters/answer/66359 ) द्वारा।

Comments

दोनों बिंदु ओर्थोगोनल हैं। यहां तक ​​कि अगर सभी नाम एक ही आईपी को इंगित करते हैं, तो वेबसर्वर अनुरोधित नाम प्राप्त करता है और पूरी तरह से अलग सामग्री वितरित कर सकता है।

— पैट्रिक मेवज़ेक

इसलिए मैंने "यदि सभी * .example.com एक ही सामग्री दिखा रहे हैं" को वरीयता दी है ... एसईओ जोखिम मुझे उल्लेख करने के लिए कुछ दिलचस्प लगता है।

— क्लेमेंट मौलिन - सिंपल रीजो 16

"एसईओ जोखिम मुझे कुछ दिलचस्प लगता है जिसका उल्लेख करना है।" हो सकता है लेकिन वे वाइल्डकार्ड का उपयोग करने के लिए पूरी तरह से असंबंधित हों या नहीं। आपके पास किसी भी प्रकार के वाइल्डकार्ड के बिना एक एकल आईपी पते पर हल करने वाले कई अलग-अलग नाम हो सकते हैं और इसलिए आपके द्वारा बोले गए एसईओ जोखिमों के होने या न होने के कारण। वाइल्डकार्ड के उपयोग से यहां किसी भी दिशा में कुछ भी नहीं बदलता है।

— पैट्रिक मेव्ज़ेक

Answer 5

यह वास्तव में एक बुरा विचार है, यदि आप एक वेब सर्वर में एक उपडोमेन डॉट कॉम.कॉम होस्ट करना चाहते हैं, और दूसरे वेब सर्वर में b.company.com, एक और आईएसपी हो सकता है। आप क्या करोगे ?। तो वाइल्डकार्ड डीएनएस एक विकल्प नहीं है, यह सटीक होना चाहिए, प्रत्येक उप डोमेन के लिए ए रिकॉर्ड बनाएं और प्रासंगिक आईपी को इंगित करें। संभावना है कि आपके वेब सर्वर को एक आईएसपी से दूसरे आईएसपी में स्थानांतरित किया जाए, इस मामले में आप क्या करेंगे?

Answer 6

मुझे पता है कि यह एक पुराना सवाल है, हालांकि मैं एक वास्तविक दुनिया उदाहरण साझा करना चाहता हूं जहां वाइल्डकार्ड डोमेन का उपयोग करने से समस्याएं हो सकती हैं। हालाँकि मैं डोमेन नाम बदलने जा रहा हूँ और शर्मिंदगी से बचाने के लिए पूरा SPF रिकॉर्ड भी छिपा रहा हूँ।

मैं किसी ऐसे व्यक्ति की मदद कर रहा था जो DMARC के साथ समस्या कर रहा था, चेक के भाग के रूप में मैं हमेशा DIGARC रिकॉर्ड को DIG के साथ देखता हूं

;; ANSWER SECTION:
_dmarc.somedomain.com. 21599 IN      CNAME   somedomain.com.
somedomain.com.      21599   IN      TXT     "v=spf1 <rest of spf record> -all"

मुझे भी यही परिणाम मिला जब उनके डीकेआईएम रिकॉर्ड की तलाश की गई।

नतीजतन, इस डोमेन से भेजे गए ईमेलों को डीकेआईएम विफल हो जाएगा क्योंकि डीकेआईएम मॉड्यूल एक डीकेआईएम कुंजी के लिए एसपीएफ रिकॉर्ड को पार्स करने की कोशिश करेगा और असफल हो जाएगा, और इसी कारण से डीएमएआरसी के लिए एक अनुमति भी प्राप्त होगी।

वाइल्डकार्ड डोमेन एक अच्छे विचार की तरह लग सकते हैं लेकिन गलत तरीके से सेट होने पर वे सभी प्रकार के मुद्दों का कारण बन सकते हैं।

Answer 7

क्या वाइल्डकार्ड DNS रिकॉर्ड खराब प्रैक्टिस है?

नहीं, और दूसरों के विपरीत, मेरा मानना ​​है कि यह अच्छा अभ्यास है।

अधिकांश इंटरनेट उपयोगकर्ता किसी बिंदु पर एक DNS नाम पर उंगली करते हैं। वे टाइप करेंगे ww.mycompany.comया wwe.mycompany.com आप क्या करेंगे बल्कि एक "उफ़ हम उस साइट को नहीं ढूंढ सकते" या उनके लिए अपने प्राथमिक होम पेज को खींच सकते हैं? अधिक बार उन्हें अपने प्राथमिक होम पेज को नहीं खींचने से बेहतर है। जो कि बहुत सारे लोग करते हैं।

यहां तक ​​कि अगर कोई इसके लिए एक लिंक डालता है, i.dont.like.your.website.whatever.comतब भी आपका होम पेज खिंच जाएगा , जो वास्तव में आप चाहते हैं। आखिरकार, वे उस i.dont....साइट को अपने सर्वर पर नहीं जा सकते , आप अभी भी DNS रूटिंग को नियंत्रित करते हैं, इसलिए यह आपके पास जाता है।

Comments

इस तर्क के साथ मुझे जो समस्या है, वह यह है कि 1. यह त्रुटि से निपटने को तोड़ता है, 2. यह पूरी तरह से www-केंद्रित है जबकि आपके वाइल्डकार्ड रिकॉर्ड अन्य प्रोटोकॉल को भी प्रभावित करेंगे। इसका परिणाम यह है कि आपने अन्य चीजों के लिए त्रुटि से निपटने में त्रुटि की है जहां आपने चीजों को पैच करने का कोई प्रयास नहीं किया है।

— हाकन लिंडक्विस्ट

Answer 8

मुझे लगता है कि पहली जगह में वाइल्डकार्ड डीएनएस रिकॉर्ड न होने का सबसे अच्छा कारण एक संभावित हमलावर को अपना सर्वर आईपी पता देने से बचना है और डीडीओएस हमलों के लिए प्रदर्शनी को कम करना है। Cloudflare द्वारा यह भी सिफारिश की जाती है: https://blog.cloudflare.com/ddos-prevention-protecting-the-origin/

Comments

वाइल्डकार्ड डोमेन का उपयोग करने से इस तरह के हमलों के संपर्क में नहीं आता है। और लिंक आपके गलत दावों का समर्थन नहीं करता है। सभी लिंक यह कहते हैं कि क्लाउडफ्लेयर वाइल्डकार्ड डोमेन के लिए अधिक कीमत वसूलता है। यह केवल Cloudflare के व्यवसाय मॉडल के बारे में कुछ कहता है और वाइल्डकार्ड डोमेन का उपयोग करने के अभ्यास के बारे में कुछ भी नहीं है।

— कसपर

यदि आप क्लाउडफ़ेयर के साथ वाइल्डकार्ड डीएनएस का उपयोग करते हैं, क्योंकि यह क्लाउडफ़ेयर के माध्यम से नहीं जाता है (जब तक कि आप उद्यम का भुगतान नहीं करते हैं, तो सबसे अधिक नहीं) कोई भी किसी भी उप-डोमेन को पिंग कर सकता है और अपना असली आईपी पा सकता है। वाइल्डकार्ड के बिना वे नहीं कर सकते। यही सब है इसके लिए।

— माइकल रोजर्स

ऐसी सेवा के मामले में, वे वाइल्डकार्ड सुरक्षा के लिए आपसे अधिक शुल्क ले सकते हैं। यद्यपि यह प्रश्न उन प्रकार की सेवाओं के बारे में नहीं है जो वाइल्डकार्डिंग डीएनएस के बारे में हैं और यह सामान्य परिस्थितियों में किया जाना चाहिए या नहीं।

— क्रिस