Yksityinen DNS Azuressa VPN:n yli: resolverin päätepiste vai forwarder
Molemmat mallit vastaavat yksityisiin vyöhykkeisiin tunnelin yli. Vertaa hallittua saapuvaa päätepistettä forwarder-VM:ään ja tarkista sitten polku, jonka on oltava olemassa kummassakin tapauksessa.
Paikallisen verkon palvelin tavoittaa Azure-VM:n yksityisellä osoitteella eikä silti pysty selvittämään sen yksityistä isäntänimeä, mikä saa ihmiset etsimään rikkinäistä tunnelia. Tunneli on kunnossa. Puuttuu DNS-raja: paikallisella puolella ei tiedä kukaan, että tiettyyn Azuren yksityiseen vyöhykkeeseen pitää vastata VNetin sisäisen resolverin. Kaksi mallia sulkee tämän aukon, ja ne eroavat siinä, mitä lopulta ylläpidät, eivät siinä, toimitko kyselyt.
Tunneli kuljettaa kyselyitä, ei vyöhyketietoa
Toimipisteiden välinen yhteys antaa paketeille reitin kahden verkon välillä. Se ei kerro paikalliselle DNS-palvelimelle, mikä nimiavaruus kuuluu Azurelle tai mikä osoite vastaa, joten kysely joko menee internetiin ja palaa tyhjänä tai ei koskaan poistu paikallisesta resolverista.
Korjauksessa on kaksi helposti erotettavaa puoliskoa. Toinen puolisko on VNetin sisäinen resolver, joka hyväksyy tunnelin kautta saapuvat kyselyt. Toinen on paikallisella puolella oleva ehdollinen forwarder, joka lähettää täsmälleen yhden nimiavaruuden sille resolverille. Kumpikaan puolisko ei toimi yksin.
Oletetaan, että vyöhyke on cloud.corp.example tämän kuvauksen loppuun asti, ja käsittele jokaista osoitetta havainnollisena.
Vaihtoehto A: hallittu saapuva päätepiste
Azure DNS Private Resolver tarjoaa saapuvan päätepisteen, joka hyväksyy DNS-kyselyitä VNetin ulkopuolelta. Ota se käyttöön erillisessä delegoidussa aliverkossa, linkitä yksityinen vyöhyke siihen VNetiin ja kirjaa ylös palvelun myöntämä saapuva osoite.
Paikallisella DNS-palvelimella luot sitten ehdollisen forwarderin täsmälliselle nimiavaruudelle kohti tuota osoitetta:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoftin hybridi-DNS-menettely dokumentoi sekä vyöhykelinkin että forwarder-vaiheen. Hallittu polku ei jätä yhtään DNS-ohjelmistoa paikattavaksi, ja päätepisteen osoite pysyy vakaana resurssin koko elinkaaren.
Hinta on, että omistat nyt resolver-resurssin, sen aliverkkodelegoinnin ja sen kustannuksen, joka on todellinen vaikka kyselymäärä olisi hyvin pieni.
Vaihtoehto B: forwarder-VM VNetin sisällä
Vanhempi malli ajaa DNS-ohjelmistoa tavallisessa VNetin VM:ssä: Windows DNS, BIND tai dnsmasq, ja yksityinen vyöhyke joko ylläpidetään paikallisesti tai välitetään Azuren resolverille osoitteessa 168.63.129.16. Paikallinen ehdollinen forwarder osoittaa tuon VM:n yksityiseen osoitteeseen.
Tämä vaihtoehto on tuttu tiimeille, jotka jo pyörittävät DNS-palvelimia, ja se voi kantaa lisälogiikkaa, kuten lokitusta tai split-horizon-vastauksia. Se perii myös DNS-palvelimen kaikki operatiiviset velvoitteet: paikkaukset, toinen instanssi käytettävyydelle, valvonnan ja uudelleenrakennuspolun, kun VM korvataan ja sen osoite muuttuu.
Tavallinen VNet-isäntä ei ole DNS-välityspalvelin ennen kuin palvelu on asennettu ja sillä on lupa vastata noille asiakkaille, ja juuri tuon vaiheen ihmiset ohittavat kloonatessaan VM:n.
Kumpi sopii toimintaasi
Vertailu ei kerro, kumpi malli on nopeampi. Se kertoo, haluatko ylipäätään ylläpitää DNS-ohjelmistoa ja oikeuttaako kyselymäärä hallitun resurssin, joka laskutetaan päätepisteen ja kyselyn mukaan.
| 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 |
Kumpi rivi tahansa ratkaisee, paikallinen forwarder-sääntö näyttää samalta. Juuri sen osan on oltava molemmissa malleissa, ja se on useimmin puuttuva osa, kun joku kertoo, että nimien selvitys toimii Azuren sisältä mutta ei toimistosta.
Tarkista polku järjestyksessä
Varmista, että vyöhyke on linkitetty VNetiin, jossa resolver on, ja että paikallinen forwarder nimeää nimiavaruuden eikä ylätason verkkotunnusta. corp.exampleille tehty forwarder ei täsmää cloud.corp.exampleiin, ellei resolver itse delegoi, ja ero tuottaa puhtaan kielteisen vastauksen, joka näyttää puuttuvalta tietueelta.
Tarkista sitten, että kysely saavuttaa päätepisteen: paikallinen lähde tarvitsee reitin resolverin osoitteeseen ja paluureitin, ja sekä UDP- että TCP-portin 53 pitäisi olla sallittu siellä, missä käytäntö sen sallii. NSG ei voi tarjota puuttuvaa vyöhyketietuetta, eikä oikea vyöhyke voi vastata kyselyyn, joka ei koskaan saavu.
Pidä pyydetty FQDN valitun resolverin vieressä, kun diagnosoit, ja erota aikakatkaisu kielteisestä vastauksesta. Aikakatkaisu on reitin tai käytännön ongelma. Kielteinen vastaus tarkoittaa, että kysely saapui eikä nimiavaruus täsmännyt. Työjärjestys: linkitä vyöhyke, lisää ehdollinen forwarder, avaa portti 53 molempiin suuntiin, testaa yksi nimi paikallisesta verkosta ja vasta sitten katso sovelluksen omaa valtuutusta.