Naamomzetting voor resources in virtuele Azure-netwerken

Azure kan worden gebruikt voor het hosten van IaaS-, PaaS- en hybride oplossingen. Om de communicatie tussen de virtuele machines (VM's) en andere resources die zijn geïmplementeerd in een virtueel netwerk te vergemakkelijken, kan het nodig zijn om ze in staat te stellen met elkaar te communiceren. Het gebruik van gemakkelijk onthouden en onveranderlijke namen vereenvoudigt het communicatieproces in plaats van te vertrouwen op IP-adressen.

Wanneer resources die in virtuele netwerken zijn geïmplementeerd, domeinnamen moeten omzetten in interne IP-adressen, kunnen ze een van de volgende vier methoden gebruiken:

• Privézones van Azure DNS

• Door Azure geleverde naamomzetting

• Naamomzetting die gebruikmaakt van uw eigen DNS-server (die query's naar de door Azure geleverde DNS-servers kan doorsturen)

• Azure DNS Private Resolver

Welk type naamomzetting u gebruikt, is afhankelijk van hoe uw resources met elkaar moeten communiceren. In de volgende tabel ziet u scenario's en bijbehorende oplossingen voor naamomzetting:

Door Azure geleverde naamomzetting

De opgegeven naamomzetting van Azure biedt alleen algemene gezaghebbende DNS-mogelijkheden. Azure beheert de DNS-zonenamen en -records als u de DNS gebruikt die door Azure wordt geleverd. U kunt de DNS-zonenamen of de levenscyclus van DNS-records niet beheren. Als u een volledig functionele DNS-oplossing voor uw virtuele netwerken nodig hebt, kunt u privézones van Azure DNS gebruiken met door de klant beheerde DNS-servers of een privé-resolver van Azure DNS.

Samen met de omzetting van openbare DNS-namen biedt Azure interne naamomzetting voor VM's en rolinstanties die zich in hetzelfde virtuele netwerk of dezelfde cloudservice bevinden. VM's en exemplaren in een cloudservice delen hetzelfde DNS-achtervoegsel, zodat de hostnaam alleen voldoende is. Maar in virtuele netwerken die zijn geïmplementeerd met het klassieke implementatiemodel, hebben verschillende cloudservices verschillende DNS-achtervoegsels. In dit geval hebt u de FQDN nodig om namen tussen verschillende cloudservices op te lossen. In virtuele netwerken die zijn geïmplementeerd met behulp van het Azure Resource Manager-implementatiemodel, is het DNS-achtervoegsel consistent op alle virtuele machines binnen een virtueel netwerk, dus de FQDN is niet nodig. DNS-namen kunnen worden toegewezen aan vm's en netwerkinterfaces. Hoewel door Azure geleverde naamomzetting geen configuratie vereist, is dit niet de juiste keuze voor alle implementatiescenario's, zoals beschreven in de vorige tabel.

Functies

Door Azure geleverde naamomzetting bevat de volgende functies:

• Gebruiksgemak. Er is geen configuratie vereist.

• Hoge beschikbaarheid. U hoeft geen clusters van uw eigen DNS-servers te maken en te beheren.

• U kunt de service gebruiken met uw eigen DNS-servers om zowel on-premises als Azure-hostnamen om te zetten.

• U kunt naamomzetting tussen VM's en rolinstanties binnen dezelfde cloudservice gebruiken, zonder dat u een FQDN nodig hebt.

• U kunt naamomzetting gebruiken tussen VIRTUELE machines in virtuele netwerken die gebruikmaken van het Azure Resource Manager-implementatiemodel, zonder dat u een FQDN nodig hebt. Voor virtuele netwerken in het klassieke implementatiemodel is een FQDN vereist wanneer u namen in verschillende cloudservices omzet.

• U kunt hostnamen gebruiken die uw implementaties het beste beschrijven in plaats van met automatisch gegenereerde namen te werken.

Overwegingen

Punten om rekening mee te houden wanneer u azure-opgegeven naamomzetting gebruikt:

• Het door Azure gemaakte DNS-achtervoegsel kan niet worden gewijzigd.

• DNS-zoekopdracht is gericht op een virtueel netwerk. DNS-namen die voor één virtueel netwerk zijn gemaakt, kunnen niet worden omgezet vanuit andere virtuele netwerken.

• U kunt uw eigen records niet handmatig registreren.

• WINS en NetBIOS worden niet ondersteund. U kunt uw VM's niet zien in Windows Verkenner.

• Hostnamen moeten compatibel zijn met DNS. Namen mogen alleen 0-9, a-z en '-' gebruiken en mogen niet beginnen of eindigen met een '-'.

• DNS-queryverkeer wordt beperkt voor elke VIRTUELE machine. Beperking mag niet van invloed zijn op de meeste toepassingen. Als aanvraagbeperking wordt waargenomen, moet u ervoor zorgen dat caching aan de clientzijde is ingeschakeld. Zie dns-clientconfiguratie voor meer informatie.

• Gebruik een andere naam voor elke virtuele machine in een virtueel netwerk om PROBLEMEN met DNS-omzetting te voorkomen.

• Alleen VM's in de eerste 180 cloudservices worden geregistreerd voor elk virtueel netwerk in een klassiek implementatiemodel. Deze limiet geldt niet voor virtuele netwerken in Azure Resource Manager.

• Het IP-adres van Azure DNS is 168.63.129.16. Dit adres is een statisch IP-adres en verandert niet.

Overwegingen voor omgekeerde DNS

Omgekeerde DNS voor VM's wordt ondersteund in alle virtuele netwerken op basis van Azure Resource Manager. PtR-records (Reverse DNS) die door Azure worden beheerd, worden automatisch toegevoegd wanneer u een virtuele machine start en verwijderd wanneer de VIRTUELE machine wordt gestopt (toewijzing opgeheven). Zie het volgende voorbeeld:

C:\>nslookup -type=ptr 10.11.0.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa  name = myeastspokevm1.internal.cloudapp.net

De internal.cloudapp.net omgekeerde DNS-zone wordt beheerd door Azure en kan niet rechtstreeks worden bekeken of bewerkt. Forward lookup on the FQDN of form [vmname].internal.cloudapp.net wordt omgezet in het IP-adres dat is toegewezen aan de virtuele machine.

Als een privézone van Azure DNS is gekoppeld aan het virtuele netwerk met een koppeling naar een virtueel netwerk en automatisch registreren is ingeschakeld op die koppeling, retourneert omgekeerde DNS-query's twee records. Eén record is van het formulier [vmname].[ privatednszonename] en de andere is van het formulier [vmname].internal.cloudapp.net. Zie het volgende voorbeeld:

C:\>nslookup -type=ptr 10.20.2.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa  name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa  name = mywestvm1.azure.contoso.com

Wanneer twee PTR-records worden geretourneerd zoals eerder weergegeven, retourneert forward lookup van een van beide FQDN's het IP-adres van de virtuele machine.

Omgekeerde DNS-zoekacties zijn gericht op een bepaald virtueel netwerk, zelfs als deze is gekoppeld aan andere virtuele netwerken. Omgekeerde DNS-query's voor IP-adressen van virtuele machines in gekoppelde virtuele netwerken retourneren NXDOMAIN.

U kunt de omgekeerde DNS-functie in een virtueel netwerk uitschakelen door uw eigen zone voor reverse lookup te maken met behulp van privézones van Azure DNS en deze zone vervolgens te koppelen aan uw virtuele netwerk. Als de IP-adresruimte van uw virtuele netwerk bijvoorbeeld 10.20.0.0/16 is, kunt u een lege privé-DNS-zone 20.10.in-addr.arpa maken en deze koppelen aan het virtuele netwerk. Deze zone overschrijft de standaard zones voor reverse lookup voor het virtuele netwerk. Deze zone is leeg. Omgekeerde DNS retourneert NXDOMAIN , tenzij u deze vermeldingen handmatig maakt.

Automatische registratie van PTR-records wordt niet ondersteund. Als u vermeldingen wilt maken, voert u deze handmatig in. U moet automatisch registreren uitschakelen in het virtuele netwerk als dit is ingeschakeld voor andere zones. Deze beperking wordt veroorzaakt door beperkingen waarmee slechts één privézone kan worden gekoppeld als automatisch registreren is ingeschakeld. Zie de snelstartgids voor privé-DNS voor meer informatie over het maken van een privé-DNS-zone en het koppelen aan een virtueel netwerk.

DNS-clientconfiguratie

In deze sectie worden cache- en nieuwe pogingen aan de clientzijde behandeld.

Cache aan clientzijde

Niet elke DNS-query moet via het netwerk worden verzonden. Caching aan de clientzijde helpt de latentie te verminderen en de tolerantie voor netwerklips te verbeteren door terugkerende DNS-query's uit een lokale cache op te lossen. DNS-records bevatten een TTL-mechanisme (Time To Live), waardoor de cache de record zo lang mogelijk kan opslaan zonder dat dit van invloed is op de nieuwheid van de record. Caching aan de clientzijde is dus geschikt voor de meeste situaties.

De standaard Windows DNS-client heeft een ingebouwde DNS-cache. Sommige Linux-distributies bevatten standaard geen caching. Als u merkt dat er nog geen lokale cache is, voegt u een DNS-cache toe aan elke Virtuele Linux-machine.

Er zijn veel verschillende DNS-cachingpakketten beschikbaar (zoals dnsmasq). U kunt als volgt dnsmasq installeren op de meest voorkomende distributies:

Nieuwe pogingen aan de clientzijde

DNS is voornamelijk een UDP-protocol. Omdat het UDP-protocol niet garandeert dat berichten worden bezorgd, wordt logica voor opnieuw proberen verwerkt in het DNS-protocol zelf. Elke DNS-client (besturingssysteem) kan verschillende logica voor opnieuw proberen vertonen, afhankelijk van de voorkeur van de maker:

• Windows-besturingssystemen proberen het opnieuw na één seconde en vervolgens na nog eens twee seconden, vier seconden en nog eens vier seconden.
• De standaardinstellingen voor Linux worden na vijf seconden opnieuw geprobeerd. We raden u aan om de specificaties voor opnieuw proberen te wijzigen in vijf keer, met intervallen van één seconde.

Controleer de huidige instellingen op een Virtuele Linux-machine met cat /etc/resolv.conf. Bekijk de regel met opties , bijvoorbeeld:

options timeout:1 attempts:5

Het bestand resolv.conf wordt automatisch gegenereerd en mag niet worden bewerkt. De specifieke stappen voor het toevoegen van de optielijn variëren per distributie:

Naamomzetting waarbij je eigen DNS-server wordt gebruikt

In deze sectie worden VM's, rolinstanties en web-apps behandeld.

VM's en rolinstanties

Uw naamomzettingsbehoeften kunnen verder gaan dan de functies van Azure. U moet bijvoorbeeld Microsoft Windows Server Active Directory-domeinen gebruiken, DNS-namen tussen virtuele netwerken omzetten. Om deze scenario's te behandelen, kunt u met Azure uw eigen DNS-servers gebruiken.

DNS-servers in een virtueel netwerk kunnen DNS-query's doorsturen naar de recursieve resolvers in Azure. Met deze procedure kunt u hostnamen in dat virtuele netwerk omzetten. Een domeincontroller (DC) die in Azure wordt uitgevoerd, kan bijvoorbeeld reageren op DNS-query's voor de domeinen en alle andere query's doorsturen naar Azure. Met het doorsturen van query's kunnen VM's zowel uw on-premises resources (via de DC) als door Azure geleverde hostnamen (via de doorstuurserver) zien. De toegang tot recursieve omzetfuncties in Azure wordt verleend via het virtuele IP-adres 168.63.129.16.

Dns-doorsturen maakt ook DNS-omzetting tussen virtuele netwerken mogelijk en stelt uw on-premises machines in staat om door Azure geleverde hostnamen op te lossen. Als u de hostnaam van een VIRTUELE machine wilt oplossen, moet de DNS-server-VM zich in hetzelfde virtuele netwerk bevinden en worden geconfigureerd voor het doorsturen van hostnaamquery's naar Azure. Omdat het DNS-achtervoegsel verschilt in elk virtueel netwerk, kunt u regels voor voorwaardelijk doorsturen gebruiken om DNS-query's naar het juiste virtuele netwerk te verzenden voor omzetting. In de volgende afbeelding ziet u twee virtuele netwerken en een on-premises netwerk dat DNS-omzetting tussen virtuele netwerken uitvoert met behulp van deze methode. Een voorbeeld van een DNS-doorstuurserver is beschikbaar in de galerie Azure Quickstart-sjablonen en GitHub.

Wanneer u azure-opgegeven naamomzetting gebruikt, biedt DHCP (Dynamic Host Configuration Protocol) een intern DNS-achtervoegsel (.internal.cloudapp.net) voor elke VIRTUELE machine. Met dit achtervoegsel wordt hostnaamomzetting ingeschakeld omdat de hostnaamrecords zich in de internal.cloudapp.net zone bevinden. Wanneer u uw eigen oplossing voor naamomzetting gebruikt, wordt dit achtervoegsel niet geleverd aan VM's omdat dit in strijd is met andere DNS-architecturen (zoals scenario's die lid zijn van een domein). In plaats daarvan biedt Azure een niet-functionerende tijdelijke aanduiding (reddog.microsoft.com).

Indien nodig kunt u het interne DNS-achtervoegsel bepalen met behulp van PowerShell of de API:

• Voor virtuele netwerken in Azure Resource Manager-implementatiemodellen is het achtervoegsel beschikbaar via de REST API van de netwerkinterface, de PowerShell-cmdlet Get-AzNetworkInterface en de az network nic show Azure CLI-opdracht.

Als het doorsturen van query's naar Azure niet aan uw behoeften voldoet, geeft u uw eigen DNS-oplossing op of implementeert u een privé-resolver van Azure DNS.

Als u uw eigen DNS-oplossing opgeeft, moet u het volgende doen:

• Geef bijvoorbeeld de juiste hostnaamomzetting op via DDNS. Als u DDNS gebruikt, moet u mogelijk het opruimen van DNS-records uitschakelen. Azure DHCP-leases zijn lang en opruiming kan DNS-records voortijdig verwijderen.

• Geef de juiste recursieve resolutie op om het oplossen van externe domeinnamen mogelijk te maken.

• Toegankelijk zijn (TCP en UDP op poort 53) van de clients die het bedient en toegang hebben tot internet.

• Worden beveiligd tegen toegang vanaf internet, om bedreigingen van externe agents te beperken.

Web-apps

Stel dat u naamomzetting moet uitvoeren vanuit uw web-app die is gebouwd met behulp van App Service, gekoppeld aan een virtueel netwerk, naar VM's in hetzelfde virtuele netwerk. Voer naast het instellen van een aangepaste DNS-server met een DNS-doorstuurserver die query's doorstuurt naar Azure (virtueel IP 168.63.129.16) de volgende stappen uit:

Schakel integratie van virtuele netwerken in voor uw web-app, als deze nog niet is voltooid, zoals beschreven in Uw app integreren met een virtueel netwerk.

Als u naamomzetting wilt uitvoeren vanuit uw gekoppelde vnet-web-app (gebouwd met behulp van App Service) naar VM's in een ander vnet dat niet is gekoppeld aan dezelfde privézone, gebruikt u aangepaste DNS-servers of privé-resolvers van Azure DNS op beide vets.

Aangepaste DNS-servers gebruiken:

• Stel een DNS-server in uw virtuele doelnetwerk in op een virtuele machine die ook query's naar de recursieve resolver in Azure kan doorsturen (virtueel IP 168.63.129.16). Een voorbeeld van een DNS-doorstuurserver is beschikbaar in de galerie Azure Quickstart-sjablonen en GitHub.

• Stel een DNS-doorstuurserver in het virtuele bronnetwerk in op een virtuele machine. Configureer deze DNS-doorstuurserver om query's door te sturen naar de DNS-server in uw virtuele doelnetwerk.

• Configureer de DNS-bronserver in de instellingen van het virtuele bronnetwerk.

• Schakel integratie van virtuele netwerken in voor uw web-app om een koppeling te maken naar het virtuele bronnetwerk. Volg hiervoor de instructies in Uw app integreren met een virtueel netwerk.

Als u een privé-resolver van Azure DNS wilt gebruiken, raadpleegt u de regelsetkoppelingen.

DNS-servers opgeven

Wanneer u uw eigen DNS-servers gebruikt, kunt u met Azure meerdere DNS-servers per virtueel netwerk opgeven. U kunt ook meerdere DNS-servers opgeven per netwerkinterface (voor Azure Resource Manager) of per cloudservice (voor het klassieke implementatiemodel). DNS-servers die zijn opgegeven voor een netwerkinterface of cloudservice krijgen voorrang op DNS-servers die zijn opgegeven voor het virtuele netwerk.

Wanneer u het Azure Resource Manager-implementatiemodel gebruikt, kunt u DNS-servers opgeven voor een virtueel netwerk en een netwerkinterface. Zie Een virtueel netwerk beheren en een netwerkinterface beheren voor meer informatie.

Volgende stappen

Azure Resource Manager-implementatiemodel:

• Een virtueel netwerk beheren

• Een netwerkinterface beheren