10

मैं नेटवर्क प्रशासन के लिए काफी नया हूं और इसलिए पहले से ही एक DNS रिकॉर्ड सफलतापूर्वक स्थापित करने के लिए उत्साहित हूं।

अब मैं थोड़ा उलझन में हूँ, क्योंकि मैं इस URL को करना चाहता हूँ:

http://www.example.org:8080/fetch/characters/

वास्तव में इसके द्वारा पहुँचा जा सकता है

http://www.example.org/fetch/characters/

इसलिए उपयोगकर्ता पोर्ट को स्पष्ट रूप से सेट किए बिना पोर्ट 8080 पर सेवा तक पहुंच सकते हैं।

मैं यह कैसे कर सकता हूँ? क्या मुझे अपने सर्वर पर कुछ विशेष एप्लिकेशन की आवश्यकता है? या किसी भी पुनर्निर्देशित सामान को अनुरोधों पर लागू किया जाना है?

— xetra11
स्रोत

4

डिफ़ॉल्ट रूप से ब्राउज़र 8080 पोर्ट का उपयोग नहीं करता है। क्या यह टाइपिंग प्रश्न में गलती है?

— 11:42 पर ड्यूशॉ

एक डीएनएस क्या है और यह क्या करता है की गलत धारणा।

— CONvid19

@ Džuris ना यह मेरी सोच की एक गलती थी 8080 के बजाय http डिफ़ॉल्ट है 80

— xetra11

32

डीएनएस रिकॉर्ड बंदरगाहों को इंगित नहीं कर सकता (कुछ विशेष मामले अपवादों के साथ जो यहां लागू नहीं होते हैं)।

यदि आपके पास पोर्ट 8080 पर एक वेब सेवा है और इस पोर्ट को निर्दिष्ट किए बिना उस तक पहुंचना चाहते हैं, तो आपके पास 3 विकल्प हैं:

इसे वास्तव में पोर्ट 80 (या https के साथ 443) पर सुनें।
पोर्ट 8080 (रिवर्स प्रॉक्सी) पर आपकी सेवा के लिए अनुरोधों को अग्रेषित करने के लिए पोर्ट 80 पर पहले से ही जो कुछ भी है उसे कॉन्फ़िगर करें।
यदि आप रीडायरेक्ट के साथ रह सकते हैं, तो प्रॉक्सी के बजाय इसका उपयोग करें, लेकिन तब आपके ग्राहक :8080रीडायरेक्ट के बाद अपने एड्रेस बार में हिस्सा देखेंगे ।

— स्वेन
स्रोत

10

क्या होगा अगर हम SRV रिकॉर्ड का उपयोग कर सकते हैं और सेवाओं के लिए पोर्ट निर्दिष्ट कर सकते हैं ... बहुत बुरा ब्राउज़र इसका उपयोग नहीं करते हैं।

— याकूब इवांस

4

@JacobEvans: सब कुछ के लिए SRV रिकॉर्ड मेरा एक पुराना सपना है। यह इतना आसान (फ़ायरवॉल व्यवस्थापक जो अब सिर्फ 80 और 443 के अलावा सब कुछ ब्लॉक कर सकते हैं को छोड़कर) बातें बनाना होगा

— स्वेन

SRV रिकॉर्ड कुछ सेवाओं के लिए बहुत अच्छी तरह से काम करता है, जैसे XMPP ... लेकिन दुख की बात है बहुत (और निश्चित रूप से HTTP नहीं)

— जोश

विकल्प 4: एक फ़ायरवॉल द्वारा पोर्ट आगे

— जोएल कोएल

10

वेब सर्वर डिफ़ॉल्ट रूप से टीसीपी पोर्ट 80 को सुनते हैं। यदि आप URL में पोर्ट नंबर को स्पष्ट रूप से लिखना नहीं चाहते हैं, तो आपके पास कुछ विकल्प हैं:

आप पोर्ट 8080 के बजाय पोर्ट 80 का उपयोग करने के लिए अपने वेब सर्वर को फिर से कॉन्फ़िगर कर सकते हैं। यह वेब सर्वरों जैसे कि नगनेक्स या अपाचे के लिए अनुशंसित है लेकिन Gunicorn जैसे वेब सर्वर के लिए नहीं। यह विकल्प भी हमेशा संभव नहीं होता है क्योंकि यह पोर्ट पहले से ही एक अलग वेब सर्वर के उपयोग में हो सकता है।

इसके अलावा, जब आपका सर्वर NAT गेटवे के पीछे होता है, तो वह सार्वजनिक IP पते का मालिक नहीं होता है और उस सार्वजनिक NAT पते और पोर्ट 80 के संयोजन को पहले से ही एक अलग वेब सर्वर पर भेजा जा सकता है।
आप अपने वेब सर्वर के सामने एक रिवर्स प्रॉक्सी सर्वर रख सकते हैं जो टीसीपी पोर्ट 80 पर ट्रैफिक को स्वीकार करता है और इसे आपके वेब सर्वर को टीसीपी पोर्ट 8080 पर भेजता है। पोर्ट 80 पहले से उपयोग में है, तो यह भी काम करेगा। बस रिवर्स प्रॉक्सी सर्वर को दोनों वेब सर्वर के सामने रखें, जिससे दोनों को 80 के अलावा अन्य पोर्ट्स सुनने को मिलें।

बेहतर और अधिक विस्तृत सहायता प्रदान करने के लिए कौन सा विकल्प सबसे अच्छा और सीमाएं आदि हो सकता है, इसके लिए हमें आपके सेटअप के बारे में अधिक जानना होगा। उम्मीद है कि इस स्पष्टीकरण ने पहले ही चीजों को थोड़ा स्पष्ट कर दिया।

— Tommiie
स्रोत

मेरे पास पहले से ही मौजूद इन्फोस है! मैंने डिफ़ॉल्ट वेब पोर्ट 80 के लिए 8080

— xetra11

7

सरल उत्तर, प्रश्न के स्तर से संबंधित

DNS के बाहरी उपयोगों को अनदेखा करना, और DNS लुकअप (प्रश्न के लिए प्रासंगिक नहीं) को उल्टा करना, लगभग सभी DNS उपयोग फॉर्म का है:

क्लाइंट DNS सर्वर को डोमेन नाम (पूरी तरह से योग्य या अन्यथा) भेजता है
DNS सर्वर अपने रिकॉर्ड से डोमेन जानकारी देता है। आमतौर पर अनुरोध की जाने वाली महत्वपूर्ण जानकारी या तो उस डोमेन पर वेब / ईमेल के साथ संवाद करने के लिए आईपी पता है, या किसी अन्य DNS सर्वर का आईपी पता बेहतर है जो उस जानकारी को प्रदान करने में सक्षम है।

एक बार क्लाइंट ने सर्वर से संपर्क कर लिया, तो सर्वर खुद को संभाल लेगा और DNS सिस्टम तस्वीर से बाहर हो जाएगा।

इसका मतलब यह है कि, DNS सिस्टम को पोर्ट जानकारी की आपूर्ति करने की आवश्यकता नहीं है, और यह लगभग ऐसा कभी नहीं करता है। इसलिए यद्यपि प्रश्न का उद्देश्य मान्य है, और अक्सर किया जाता है, यह वास्तव में DNS सिस्टम नहीं है जो इसे करता है। इसलिए आप इसे काम नहीं कर सकते :)

विचार यह है कि एक बार जब आपका ग्राहक उस विशिष्ट मशीन या सर्वर का पता लगा सकता है जिसे वह ढूंढ रहा है, तो उस मशीन पर वह किसी भी पोर्ट को सुनने के लिए है जिसे वह चुनता है, और कॉन्फ़िगर किए गए किसी भी पोर्ट पर किसी भी प्रोटोकॉल को स्वीकार / अस्वीकार / स्वीकार करता है।

उदाहरण के लिए, HTTP वेब सेवाएं आमतौर पर पोर्ट 80 पर प्रदान की जाती हैं। इसका मतलब है कि एक बार क्लाइंट को मशीन आईपी पता है, तो यह मान सकता है कि पोर्ट 80 पर एक संदेश भेजने से उस संदेश को उस मशीन की वेब सेवा द्वारा पढ़ा / जवाब दिया जाएगा। लेकिन यह इस तरह से नहीं है। यदि पोर्ट 9000 पर वेब इनकमिंग अनुरोधों को सुनने के लिए सर्वर को कॉन्फ़िगर किया गया है, तो पोर्ट 9000 तक पहुंचने में सक्षम कोई भी क्लाइंट अपनी वेब सेवा तक पहुंचने में सक्षम होगा। यदि सर्वर एक प्रॉक्सी / NAT / राउटर के पीछे है जो 10000 को पोर्ट 9000 को रीडायरेक्ट करता है, और क्लाइंट पोर्ट 10000 पर एक वेब अनुरोध भेजता है, तो सर्वर इसे पोर्ट 9000 पर प्राप्त करेगा और साथ ही प्रतिक्रिया देगा।

वेब सर्वर के भीतर रीडायरेक्ट / मैपिंग

आपने किसी टिप्पणी में पुनर्निर्देशित मानचित्रण या पुनर्लेखन के बारे में पूछा। ये ऐसे कार्य हैं जो एक वेब सर्वर कर सकता है। मूल रूप से, आप वेब सर्वर (या अधिकांश / कई वेब सर्वर) को यह प्रबंधित करने के लिए कॉन्फ़िगर कर सकते हैं कि यह एक अनुरोध में प्राप्त URL को कैसे संभालता है। इसलिए यह अलग-अलग URL बनाने के लिए रसीद पर URL को आंतरिक रूप से संशोधित कर सकता है, या समान टाइपो (मैपिंग) को ठीक कर सकता है, या यह कुछ अलग, प्रतिस्थापन, URL का उपयोग करके ग्राहक को दूसरी बार पूछने के लिए वास्तव में जवाब दे सकता है। (पुन: निर्देशन)।

ये उनके उपयोग हैं, और सिद्धांत रूप में आपके उपयोग-मामले को संभाल सकते हैं, लेकिन ये आपके लिए "सही" समाधान की तरह ध्वनि नहीं करते हैं:

मुझे नहीं लगता कि मैपिंग से मदद मिलेगी । मैपिंग वेब सर्वर के लिए लगभग पूरी तरह से आंतरिक है, यह कहता है " इस URL को मानो कि यह URL है"। उदाहरण के लिए, आप किसी वेब साइट URL मैपिंग का उपयोग किसी उपयोगकर्ता को बहुत-पुराने, पुराने और वर्तमान URL (उपयोगकर्ता सुविधा के लिए) का उपयोग करके " https://example.com/index.php?area-=forum&topic " का उपयोग करने के लिए कर सकते हैं। = 2 "," https://example.com/forum.php?topic=2 "और भी" https://forum.example.com?topic=2 "", और इसे केवल एक बार संभालना है, इनमें से पहले दो को तीसरे URL पर आंतरिक रूप से मैप करके, क्वेरी को संभालने के पहले चरण के रूप में। जैसा कि यह लक्ष्य क्वेरी पथ को प्रभावित करता है न कि आईपी / पोर्ट, मैपिंग के लिए बहुत उपयोग नहीं है। पोर्ट प्रबंधन, और आपके मामले में, ग्राहक वास्तव में कभी भी 8080 पर सवाल नहीं उठाता है।
पुनर्निर्देशन काम करेगा, लेकिन वह नहीं हो सकता जो आप चाहते हैं । वेब सर्वर में पुनर्निर्देशन वास्तव में क्वेरी प्राप्त करने वाले वेब सर्वर पर निर्भर करता है (क्योंकि ये वेब सर्वर आंतरिक कार्य हैं)। तो वेब सर्वर को मूल क्वेरी, रीडायरेक्ट / मैप के साथ उत्तर देने के लिए पोर्ट 80 पर वैसे भी सुनना होगा। इसे पोर्ट 8080 पर भी सुनना होगा । कार्यात्मक रूप से, इसे फिर से "पोर्ट: 8080" URL का उपयोग करके क्वेरी करने के लिए किसी भी क्लाइंट को पोर्ट 80 को बताने के लिए एक रीडायरेक्ट नियम की आवश्यकता होगी, जो आपको जैसा लगता है वैसा नहीं है। करना। उपयोगकर्ता को इसमें ": 8080" के साथ नया URL भी दिखाई देगा, जबकि ऐसा लगता है कि आप चाहते हैं कि यह "पारदर्शी" हो और न दिखाया गया हो।
रीडायरेक्ट केवल एक मानक पोर्ट (80 या 443) को रीडायरेक्ट करने के लिए काम करेगा - आप 2000 से 8080 तक पोर्ट को रीडायरेक्ट नहीं कर सकते, क्योंकि क्लाइंट 2000 में डिफ़ॉल्ट रूप से, पहले स्थान पर क्वेरी नहीं करेगा, इसलिए यह कभी नहीं होगा भले ही यह 2000 पर सुन रहा था, वेब सर्वर को प्राप्त करें। हालांकि यह आपके लिए समस्या नहीं हो सकता है।

हालाँकि यदि आप "बुद्धिमान" पुनर्निर्देशन चाहते हैं, जहां केवल कुछ प्रश्नों को 8080 पर फिर से जोड़ा जाता है, तो यह जाने का तरीका हो सकता है, क्योंकि रीडायरेक्ट में तर्क शामिल हो सकते हैं कि कौन से URL को पुनर्निर्देशित किया जाना चाहिए, जबकि पोर्ट मैपिंग (नीचे) सब कुछ मैप करेगा ।

इसे सही ढंग से कैसे करें

आपके प्रश्न का उत्तर है, आप चाहते हैं कि वेब सर्वर वेब रिक्वेस्ट का जवाब दे जिसे क्लाइंट डिफ़ॉल्ट पोर्ट (80/443) पर भेजता है, लेकिन जो सर्वर वास्तव में पोर्ट 8080 पर प्राप्त करता है।

इसका मतलब है, जैसा कि आप देख सकते हैं, आपको क्लाइंट और सर्वर के बीच पोर्ट के नक्शे के बीच कुछ चाहिए । इस तरह, क्लाइंट पोर्ट 80 (वेब ब्राउज़र द्वारा उपयोग किया जाने वाला डिफ़ॉल्ट पोर्ट) पर भेजता है, लेकिन यह वास्तव में वेब सर्वर द्वारा पोर्ट 8080 पर प्राप्त होता है। बेशक, आपको पोर्ट 8080 पर सुनने के लिए वेब सर्वर को कॉन्फ़िगर करना होगा, क्योंकि यह मानक नहीं है, लेकिन यह आसान है और किसी भी वेब सर्वर को अपने सुनने के पोर्ट निर्दिष्ट करने में सक्षम होना चाहिए।

ऐसा करने का सबसे सामान्य तरीका पोर्ट मैपिंग के माध्यम से राउटर / फ़ायरवॉल के भीतर होगा।

साधारण शब्दों में, ऐसा करने के लिए, राउटर को एक नियम दिया जाता है, जो कुछ भी प्राप्त होता है, जिसमें गंतव्य आईपी और गंतव्य पोर्ट = 80 है, को लैन में पास किया जाना चाहिए, क्योंकि गंतव्य बंदरगाह बदले में 8080 है। न तो वेब सर्वर और न ही क्लाइंट को परिवर्तन के बारे में पता होगा (यह 100% राउटर द्वारा नियंत्रित किया जाता है), इसलिए यह उन दोनों के लिए 100% पारदर्शी होगा। क्लाइंट के पास इसके URL में ": 8080" नहीं होगा और उसे कुछ भी रीडायरेक्ट करने की आवश्यकता नहीं होगी, क्योंकि यह क्वेरी 80 पोर्ट करता है, और वेब सर्वर पोर्ट 80 को अनदेखा कर सकता है और 8080 पर ही सुन सकता है, क्योंकि इसे पोर्ट 80 पर कभी भी प्रश्न नहीं मिलते हैं। ।

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

— Stilez
स्रोत

मैं अक्सर अनुप्रेषित मानचित्रण या पुनर्लेखन के बारे में सुनता हूं? क्या ये समाधान भी हैं?

— xetra11

वे संशोधक हैं जो क्लाइंट की कमांड को संसाधित करने में वेब सर्वर के भीतर किक करते हैं। इसलिए यदि वेब सर्वर इसका समर्थन करता है, तो आप पोर्ट 8080 पर किसी भी जांच का स्वचालित रूप से जवाब दे सकते हैं , HTTP 8080 पर पोर्ट पर उसी URL पर अप्रत्यक्ष रूप से - आखिरकार, HTTP / 80 -> HTTPS / 443 रीडायरेक्ट एक ही चीज है। लेकिन इसे पहले क्वेरी प्राप्त करने में सक्षम होना पड़ता है, इसलिए यह उन पोर्ट पर काम नहीं करेगा जिन्हें सुनने के लिए कॉन्फ़िगर नहीं किया गया था, और क्लाइंट शायद: 8080 संशोधित URL देखता है। पोर्ट मैपिंग के माध्यम से इसे करने से क्लाइंट के लिए यह 100% अदृश्य हो जाता है, क्योंकि वे केवल पोर्ट 80 का उपयोग करते हैं (8080 केवल 100% आंतरिक है)

— Stilez

मैंने एक अनुभाग "वेब सर्वर के भीतर पुनर्निर्देशन / मैपिंग" जोड़ा है और आपके प्रश्न को और अधिक विस्तार से कवर करने के लिए अंतिम अनुभाग का विस्तार किया है। मुझे आशा है कि वे मदद करेंगे!

— स्टिलज

3

आप नहीं कर सकते।

मेरा मतलब है, तकनीकी रूप से यह किया जा सकता है। DNS एक डोमेन नाम प्रस्तुत करने और आईपी एड्रेस प्राप्त करने में सक्षम होने के लिए प्रसिद्ध है। हालाँकि, मैंने DNS प्रोटोकॉल का थोड़ा अध्ययन किया है, और वास्तव में DNS तकनीकी रूप से केवल डोमेन नाम और आईपी पते की तुलना में कहीं अधिक क्वेरी / प्रतिक्रिया तंत्र के रूप में कार्य करने में सक्षम है। एक संभावित दृष्टिकोण एक DNS संसाधन रिकॉर्ड का उपयोग करना होगा जो कि विशिष्ट A या AAAA प्रकार नहीं है, जैसे कि TXT रिकॉर्ड (जो तकनीकी रूप से सिर्फ पाठ है, और किसी भी चीज़ के लिए इस्तेमाल किया जा सकता है) या शायद SRV रिकॉर्ड, या कोई अन्य नए संसाधन रिकॉर्ड प्रकार जो आप चुनते हैं।

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

हालाँकि, यदि आप अपना स्वयं का नेटवर्किंग प्रोटोकॉल नहीं बना रहे हैं (उदाहरण के लिए, यदि आप HTTP का उपयोग करना चाहते हैं), तो आपको एक बड़ी समस्या का सामना करने की संभावना है, जो कि मौजूदा सॉफ़्टवेयर आपके कस्टम समाधान का उपयोग नहीं करेगा, जब तक कि आप उपयोग न करें। समाधान जो पहले से स्थापित हैं। वही बाधा बन रहा है। तकनीकी अयोग्यता नहीं। एक सामाजिक अवरोधक: क्या आप हर किसी को अपना काम करने के लिए मना सकते हैं?

अब जब मैंने समझाया है कि आप ऐसा क्यों नहीं कर सकते हैं, हालांकि, मेरे पास आपके लिए एक समाधान हो सकता है। पहले, आइए देखें कि हमारे पास आईपी पते और पोर्ट क्यों हैं।

आईपी एड्रेस और पोर्ट अलग-अलग चीजें करते हैं। IP पते का उद्देश्य नेटवर्क संचार के OSI मॉडल के परत 2 और 3 के लक्ष्यों को पूरा करना है। आईपी पते का उद्देश्य यह जानना है कि यातायात को किस कंप्यूटर पर जाना है। तथ्य यह है कि हम उस उद्देश्य के लिए एक पोर्ट नंबर का उपयोग कर सकते हैं, फायरवॉल / राउटर द्वारा पोर्ट संख्या की जांच करने के लिए NAPT (नेटवर्क एड्रेस पोर्ट-आधारित ट्रांसलेशन, जिसे कभी-कभी PNAT या सिर्फ NAT) भी कहा जाता है, एक नई तकनीक है जो एक का उपयोग करती है संसाधन (सूचना), लेकिन मूल डिजाइन का हिस्सा नहीं था। यदि हम पोर्ट संख्या के इस "दुरुपयोग" से एक मिनट के लिए दूर हो जाते हैं, और मूल डिजाइन पर विचार करते हैं, तो हम एक आसान समाधान खोजने में सक्षम हो सकते हैं। इंटरनेट के डिजाइन से, मशीनों को आईपी पते का उपयोग करके पाया जाना था।

टीसीपी और यूडीपी और कुछ विकल्पों द्वारा उपयोग किए जाने वाले एक "पोर्ट नंबर" का बिंदु, व्यक्तिगत वार्तालाप का ट्रैक रखने में सक्षम है। यह रनिंग प्रोग्राम के साथ संचार को लाइन करने में मदद करता है। इसलिए, यदि कोई मशीन TCP पोर्ट 80 पर ट्रैफ़िक प्राप्त करती है, तो मशीन को पता चल जाएगा कि नेटवर्क ट्रैफ़िक का उपयोग उस प्रोग्राम द्वारा किया जाना है जो वेब सर्वर है। यदि कोई वेब ब्राउज़र एक साथ कई ग्राफिक्स डाउनलोड करता है, तो "सोर्स पोर्ट" नंबर और "डेस्टिनेशन पोर्ट" नंबर का कॉम्बिनेशन ट्रैक कर सकता है कि कौन सा डेटा किस ग्राफिक के लिए है, इसलिए डेटा को मिलाए बिना एक साथ बातचीत हो सकती है।

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

IPv6 पर विचार करें। IPv6 आपको अधिक IP पते रखने में सक्षम बनाता है। इसके अलावा, IPv4 के कुछ कार्यान्वयन के विपरीत, IPv6 का उपयोग करने वाले डिवाइस आमतौर पर एक ही समय में कई सक्रिय IPv6 पतों का आसानी से समर्थन कर सकते हैं। इसलिए, यदि आप एक कंप्यूटर पर तीन अलग-अलग नेटवर्क प्रोटोकॉल चाहते हैं, तो आप एक ही कंप्यूटर पर कम से कम तीन अलग-अलग IPv6 पते असाइन कर सकते हैं। और फिर आप उन IPv6 पतों के साथ जो भी रूटिंग शीनीगन्स कर सकते हैं।

फिर, आप उस IPv6 पते पर नाम असाइन करने के लिए AAAA संसाधन रिकॉर्ड प्रकार का उपयोग कर सकते हैं, जिसे आपका नेटवर्क डिज़ाइन विशिष्ट कंप्यूटर पर विशिष्ट सेवा के लिए प्रभावी रूप से समर्पित होने के रूप में मान सकता है।

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

संभावित आपत्ति:
और अगर आप IPv4 से चिपके हुए महसूस करते हैं और सोचते हैं कि IPv6 किसी तरह से समर्थित नहीं है, तो मैं आपको उस समस्या से निपटने की कोशिश करने के लिए प्रोत्साहित करूंगा। उस समस्या को ठीक करना आसान होगा (शायद किसी प्रकार की टनलिंग का उपयोग करके), और संभवत: आपके द्वारा इसे लागू करने के बाद यह अधिक पुरस्कृत फिक्स होगा।

— TOOGAM
स्रोत

IPv6 हमेशा समर्थन करने के लिए अच्छा है, लेकिन मदद नहीं करेगा यदि किसी कारण से आपको अब पोर्ट 80 (या 443) का उपयोग करने की अनुमति है।

— पाओलो एबरमन

यह सच है, लेकिन अगर DNS एक पोर्ट नंबर को व्यक्त करने में कामयाब रहा, तो यह फ़ायरवॉल के आसपास भी काम नहीं करेगा जो एक विशिष्ट पोर्ट नंबर पर ट्रैफ़िक को रोकता है। इसके अलावा, IPv6 का उपयोग करने के बारे में मेरी व्याख्या वास्तव में केवल उत्तर का एक हिस्सा थी, और मुझे विश्वास है कि मेरे उत्तर के पहले भाग प्रश्न को संबोधित करते हैं।

— टोगैम

मेरा DNS रिकॉर्ड केवल IP पते की ओर इशारा कर सकता है। मैं इसे एक बंदरगाह तक कैसे पहुंचा सकता हूं?

वेब सर्वर के भीतर रीडायरेक्ट / मैपिंग

इसे सही ढंग से कैसे करें