VPN ద్వారా Azure ప్రైవేట్ DNS: resolver ఎండ్‌పాయింట్ లేదా forwarder
రెండు డిజైన్లు టన్నెల్ ద్వారా ప్రైవేట్ జోన్లకు సమాధానం ఇస్తాయి. నిర్వహిత ఇన్‌బౌండ్ ఎండ్‌పాయింట్‌ను forwarder VM తో పోల్చి, ఆ తర్వాత రెండు సందర్భాల్లోనూ ఉండాల్సిన మార్గాన్ని తనిఖీ చేయండి.
ఆన్-ప్రెమిసెస్‌లోని సర్వర్ ప్రైవేట్ చిరునామా ద్వారా Azure VM ను చేరుకుంటుంది, అయినా దాని ప్రైవేట్ హోస్ట్‌నామ్‌ను పరిష్కరించలేకపోతుంది, ఇది ప్రజలను విరిగిన టన్నెల్ వెతకడానికి పంపుతుంది. టన్నెల్ బాగానే ఉంది. లేనిది DNS సరిహద్దు: ఆన్-ప్రెమిసెస్ వైపు ఏదీ నిర్దిష్ట Azure ప్రైవేట్ జోన్‌కు VNet లోపలి resolver సమాధానం ఇవ్వాలని తెలియదు. రెండు డిజైన్లు ఈ అంతరాన్ని పూరిస్తాయి, అవి చివరికి మీరు ఏమి నిర్వహిస్తారనే దానిలో భిన్నంగా ఉంటాయి, క్వెరీలు పనిచేస్తాయా అనేదానిలో కాదు.
టన్నెల్ క్వెరీలను తీసుకువెళుతుంది, జోన్ జ్ఞానాన్ని కాదు
సైట్-టు-సైట్ కనెక్షన్ ప్యాకెట్లకు రెండు నెట్‌వర్క్‌ల మధ్య మార్గాన్ని ఇస్తుంది. ఏ నామస్థలం Azure కి చెందుతుంది లేదా ఏ చిరునామా సమాధానం ఇవ్వాలి అని ఆన్-ప్రెమిసెస్ DNS సర్వర్‌కు చెప్పదు, కాబట్టి క్వెరీ ఒకటి ఇంటర్నెట్‌కు వెళ్లి ఖాళీగా తిరిగి వస్తుంది, లేదా స్థానిక resolver ను ఎప్పుడూ వదలదు.
పరిష్కారానికి సులభంగా వేరు చేయగల రెండు సగాలు ఉన్నాయి. ఒక సగం టన్నెల్ ద్వారా వచ్చే క్వెరీలను అంగీకరించే VNet లోపలి resolver. మరొక సగం ఆన్-ప్రెమిసెస్ వైపు ఉన్న షరతు forwarder, ఇది సరిగ్గా ఒక నామస్థలాన్ని ఆ resolver కి పంపుతుంది. ఏ సగం ఒంటరిగా పనిచేయదు.
ఈ వివరణ మిగిలిన భాగానికి జోన్ cloud.corp.example అని ఊహించండి, ప్రతి చిరునామాను ఉదాహరణగా పరిగణించండి.
ఎంపిక A: నిర్వహిత ఇన్‌బౌండ్ ఎండ్‌పాయింట్
Azure DNS Private Resolver VNet వెలుపల నుండి వచ్చే DNS క్వెరీలను అంగీకరించే ఇన్‌బౌండ్ ఎండ్‌పాయింట్‌ను అందిస్తుంది. మీరు దాన్ని అంకిత ప్రతినిధి సబ్‌నెట్‌లో మోహరిస్తారు, ప్రైవేట్ జోన్‌ను ఆ VNet తో లింక్ చేస్తారు, సేవ ఇచ్చే ఇన్‌బౌండ్ చిరునామాను గుర్తిస్తారు.
తర్వాత ఆన్-ప్రెమిసెస్ DNS సర్వర్‌లో ఖచ్చితమైన నామస్థలం కోసం ఆ చిరునామా వైపు షరతు forwarder సృష్టిస్తారు:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft హైబ్రిడ్ DNS విధానం జోన్ లింక్ మరియు forwarder దశ రెండింటినీ నమోదు చేస్తుంది. నిర్వహిత మార్గం ప్యాచ్ చేయడానికి DNS సాఫ్ట్‌వేర్‌ను వదిలిపెట్టదు, ఎండ్‌పాయింట్ చిరునామా వనరు జీవితకాలం మొత్తం స్థిరంగా ఉంటుంది.
ధర ఏమిటంటే ఇప్పుడు మీకు resolver వనరు, దాని సబ్‌నెట్ ప్రతినిధిత్వం మరియు దాని ఖర్చు ఉన్నాయి, క్వెరీ పరిమాణం చాలా తక్కువగా ఉన్నా ఇది నిజమే.
ఎంపిక B: VNet లోపల forwarder VM
పాత డిజైన్ VNet లోని సాధారణ VM పై DNS సాఫ్ట్‌వేర్‌ను నడుపుతుంది: Windows DNS, BIND లేదా dnsmasq, ప్రైవేట్ జోన్ స్థానికంగా హోస్ట్ చేయబడుతుంది లేదా 168.63.129.16 వద్ద Azure resolver కి పంపబడుతుంది. ఆన్-ప్రెమిసెస్ షరతు forwarder ఆ VM ప్రైవేట్ చిరునామా వైపు చూపుతుంది.
ఈ ఎంపిక ఇప్పటికే DNS సర్వర్‌లను నిర్వహించే బృందాలకు పరిచయం, మరియు లాగింగ్ లేదా split-horizon సమాధానాల వంటి అదనపు తర్కాన్ని మోయగలదు. DNS సర్వర్ యొక్క ప్రతి కార్యాచరణ బాధ్యతను కూడా వారసత్వంగా పొందుతుంది: ప్యాచింగ్, లభ్యత కోసం రెండవ ఇన్‌స్టాన్స్, పర్యవేక్షణ, మరియు VM మార్చబడి దాని చిరునామా మారినప్పుడు పునర్నిర్మాణ మార్గం.
సాధారణ VNet హోస్ట్ DNS ప్రాక్సీ కాదు, సేవ ఇన్‌స్టాల్ అయి ఆ క్లయింట్లకు సమాధానం ఇవ్వడానికి అనుమతి లభించే వరకు, VM ను క్లోన్ చేసేటప్పుడు ప్రజలు దాటవేసే దశ అదే.
మీ కార్యాచరణకు ఏది సరిపోతుంది
పోలిక ఏ డిజైన్ వేగంగా ఉందనేది కాదు. DNS సాఫ్ట్‌వేర్‌ను మీరు నిర్వహించాలనుకుంటున్నారా, మరియు క్వెరీ పరిమాణం ఎండ్‌పాయింట్ మరియు క్వెరీ ప్రకారం బిల్ చేసే నిర్వహిత వనరును సమర్థిస్తుందా అనేది.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
ఏ వరుస నిర్ణయించినా, ఆన్-ప్రెమిసెస్ forwarder నియమం ఒకేలా కనిపిస్తుంది. ఈ భాగం రెండు డిజైన్లలోనూ ఉండాలి, Azure లోపలి నుండి పరిష్కారం పనిచేస్తుంది కానీ కార్యాలయం నుండి పనిచేయదని ఎవరైనా నివేదించినప్పుడు ఎక్కువగా లేని భాగం ఇదే.
మార్గాన్ని క్రమంగా తనిఖీ చేయండి
జోన్ resolver ఉన్న VNet తో లింక్ అయిందని, ఆన్-ప్రెమిసెస్ forwarder పేరెంట్ డొమైన్ కాదు నామస్థలాన్ని పేర్కొంటుందని నిర్ధారించండి. corp.example కోసం forwarder, resolver తానే ప్రతినిధిత్వం చేయకపోతే cloud.corp.example తో సరిపోలదు, ఈ అసమానత తప్పిపోయిన రికార్డులా కనిపించే స్పష్టమైన ప్రతికూల సమాధానాన్ని ఇస్తుంది.
తర్వాత క్వెరీ ఎండ్‌పాయింట్‌ను చేరుతుందా తనిఖీ చేయండి: ఆన్-ప్రెమిసెస్ మూలానికి resolver చిరునామాకు మార్గం మరియు తిరిగి వచ్చే మార్గం కావాలి, విధానం అనుమతించిన చోట UDP మరియు TCP రెండింటికీ పోర్ట్ 53 తెరిచి ఉండాలి. NSG తప్పిపోయిన జోన్ రికార్డును ఇవ్వలేదు, సరైన జోన్ ఎప్పుడూ రాని క్వెరీకి సమాధానం ఇవ్వలేదు.
నిర్ధారణ చేస్తున్నప్పుడు అడిగిన FQDN ను ఎంచుకున్న resolver పక్కన ఉంచండి, సమయం ముగియడాన్ని ప్రతికూల సమాధానం నుండి వేరు చేయండి. సమయం ముగియడం మార్గం లేదా విధాన సమస్య. ప్రతికూల సమాధానం అంటే క్వెరీ వచ్చింది, నామస్థలం సరిపోలలేదు. పని క్రమం: జోన్‌ను లింక్ చేయండి, షరతు forwarder జోడించండి, రెండు దిశల్లో పోర్ట్ 53 తెరవండి, ఆన్-ప్రెమిసెస్ నుండి ఒక పేరును పరీక్షించండి, ఆ తర్వాతే అప్లికేషన్ సొంత అనుమతిని చూడండి.