Delen via

Naamomzetting voor resources in virtuele Azure-netwerken

  • Artikel

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:

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:

Notitie

Azure DNS-privézones is de voorkeursoplossing en biedt u flexibiliteit bij het beheren van uw DNS-zones en -records. Zie voor meer informatie Azure DNS gebruiken voor privédomeinen.

Notitie

Als u Azure Provided DNS gebruikt, wordt het juiste DNS-achtervoegsel automatisch toegepast op uw virtuele machines. Voor alle andere opties moet u FQDN (Fully Qualified Domain Names) gebruiken of handmatig het juiste DNS-achtervoegsel toepassen op uw virtuele machines.

Scenario Oplossing DNS-achtervoegsel
Naamomzetting tussen VM's in hetzelfde virtuele netwerk of azure Cloud Services-rolinstanties in dezelfde cloudservice. Privézones van Azure DNS of door Azure geleverde naamomzetting Hostnaam of FQDN
Naamomzetting tussen VM's in verschillende virtuele netwerken of rolinstanties in verschillende cloudservices. Privézones van Azure DNS, privé-resolver van Azure DNS of door de klant beheerde DNS-servers die query's doorsturen tussen virtuele netwerken voor omzetting door Azure (DNS-proxy). Zie Naamomzetting met uw eigen DNS-server. Alleen FQDN
Naamomzetting van een Azure-app-service (web-app, functie of bot) met behulp van integratie van virtuele netwerken met rolinstanties of VM's in hetzelfde virtuele netwerk. Azure DNS Private Resolver of door de klant beheerde DNS-servers doorsturen query's tussen virtuele netwerken voor omzetting door Azure (DNS-proxy). Zie Naamomzetting met uw eigen DNS-server. Alleen FQDN
Naamomzetting van App Service Web Apps naar VM's in hetzelfde virtuele netwerk. Azure DNS Private Resolver of door de klant beheerde DNS-servers doorsturen query's tussen virtuele netwerken voor omzetting door Azure (DNS-proxy). Zie Naamomzetting met uw eigen DNS-server. Alleen FQDN
Naamomzetting van App Service Web Apps in één virtueel netwerk naar VM's in een ander virtueel netwerk. Azure DNS Private Resolver of door de klant beheerde DNS-servers doorsturen query's tussen virtuele netwerken voor omzetting door Azure (DNS-proxy). Zie Naamomzetting met uw eigen DNS-server. Alleen FQDN
Oplossing van on-premises computer- en servicenamen van VM's of rolinstanties in Azure. Azure DNS Private Resolver of door de klant beheerde DNS-servers (on-premises domeincontroller, lokale alleen-lezen domeincontroller of een secundaire DNS-synchronisatie met zoneoverdrachten, bijvoorbeeld). Zie Naamomzetting met uw eigen DNS-server. Alleen FQDN
Oplossing van Azure-hostnamen van on-premises computers. Query's doorsturen naar een door de klant beheerde DNS-proxyserver in het bijbehorende virtuele netwerk, stuurt de proxyserver query's door naar Azure voor omzetting. Zie Naamomzetting met uw eigen DNS-server. Alleen FQDN
Omgekeerde DNS voor interne IP-adressen. Azure DNS-privézones, door Azure geleverde naamomzetting, Azure DNS Private Resolver of Naamomzetting met behulp van uw eigen DNS-server. Niet van toepassing
Naamomzetting tussen VM's of rolinstanties in verschillende cloudservices, niet in een virtueel netwerk. Niet van toepassing. Connectiviteit tussen VM's en rolinstanties in verschillende cloudservices wordt niet ondersteund buiten een virtueel netwerk. Niet van toepassing

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.

Notitie

Wanneer u web- en werkrollen van cloudservices gebruikt, hebt u ook toegang tot de interne IP-adressen van rolinstanties met behulp van de REST API van Azure Service Management. Zie de Naslaginformatie over de Rest API voor Service Management voor meer informatie. Het adres is gebaseerd op de rolnaam en het exemplaarnummer.

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 aan DNS 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.

Notitie

Omgekeerde DNS-records (PTR) worden niet opgeslagen in een privé-DNS-zone voor doorsturen. Omgekeerde DNS-records worden opgeslagen in een omgekeerde DNS-zone (in-addr.arpa). De standaard omgekeerde DNS-zone die is gekoppeld aan een vnet, kan niet worden weergegeven of bewerkt.

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.

Notitie

Omdat privézones van Azure DNS globaal zijn, kunt u een omgekeerde DNS-zoekactie maken om meerdere virtuele netwerken te omvatten. Hiervoor maakt u een Azure DNS-privézone voor reverse lookups (een in-addr.arpa-zone ) en koppelt u deze aan de virtuele netwerken. U moet de omgekeerde DNS-records voor de VIRTUELE machines handmatig beheren.

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:

RHEL (maakt gebruik van NetworkManager):

  1. Installeer het dnsmasq-pakket met de volgende opdracht:

    sudo yum install dnsmasq

  2. Schakel de dnsmasq-service in met de volgende opdracht:

    systemctl enable dnsmasq.service

  3. Start de dnsmasq-service met de volgende opdracht:

    systemctl start dnsmasq.service

  4. Gebruik een teksteditor om toe te voegen prepend domain-name-servers 127.0.0.1; aan /etc/dhclient-eth0.conf:

  5. Gebruik de volgende opdracht om de netwerkservice opnieuw op te starten:

    service network restart

Notitie

Het dnsmasq-pakket is slechts een van de vele DNS-caches beschikbaar voor Linux. Voordat u deze gebruikt, controleert u de geschiktheid voor uw specifieke behoeften en controleert u of er geen andere cache is geïnstalleerd.

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:

RHEL (maakt gebruik van NetworkManager):

  1. Gebruik een teksteditor om de regel RES_OPTIONS="options timeout:1 attempts:5" toe te voegen aan het bestand /etc/sysconfig/network-scripts/ifcfg-eth0.

  2. Gebruik de volgende opdracht om de NetworkManager-service opnieuw op te starten:

    systemctl restart NetworkManager.service

Naamomzetting waarbij je eigen DNS-server wordt gebruikt

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

Notitie

Azure DNS Private Resolver vervangt de noodzaak om OP VM's gebaseerde DNS-servers in een virtueel netwerk te gebruiken. De volgende sectie wordt gegeven als u een OP VM gebaseerde DNS-oplossing wilt gebruiken, maar er zijn veel voordelen voor het gebruik van azure DNS Private Resolver, waaronder kostenreductie, ingebouwde hoge beschikbaarheid, schaalbaarheid en flexibiliteit.

VM's en rolinstanties

Uw naamomzettingsbehoeften kunnen verder gaan dan de functies van Azure. U moet bijvoorbeeld Microsoft Windows Server Active Directory-domeinen gebruiken om DNS-namen tussen virtuele netwerken om te zetten. 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.

Belangrijk

Als VPN Gateway wordt gebruikt in deze set, samen met aangepaste DNS-server-IP's op VNet, moet Azure DNS IP (168.63.129.16) worden toegevoegd in de lijst en om niet-onderbroken service te onderhouden.

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.

Notitie

Een rolinstantie kan naamomzetting van VM's binnen hetzelfde virtuele netwerk uitvoeren. Dit doet u met behulp van de FQDN, die bestaat uit de hostnaam van de VIRTUELE machine en internal.cloudapp.net DNS-achtervoegsel. In dit geval is naamomzetting echter alleen geslaagd als de naam van het rolexemplaren de naam van de virtuele machine heeft gedefinieerd in het rolschema (.cscfg-bestand). <Role name="<role-name>" vmName="<vm-name>">

Rolinstanties die naamomzetting van VM's in een ander virtueel netwerk (FQDN met behulp van het achtervoegsel internal.cloudapp.net ) moeten uitvoeren met behulp van de methode die in dit gedeelte wordt beschreven (aangepaste DNS-servers doorsturen tussen de twee virtuele netwerken).

Diagram van DNS tussen virtuele netwerken

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:

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.

Notitie

  • Als u azure-VM's als DNS-servers gebruikt, moet IPv6 worden uitgeschakeld voor de beste prestaties.
  • NSG's fungeren als firewalls voor uw DNS-resolver-eindpunten. U moet uw NSG-beveiligingsregels wijzigen of overschrijven om toegang toe te staan voor UDP-poort 53 (en optioneel TCP-poort 53) naar uw DNS-listener-eindpunten. Zodra aangepaste DNS-servers zijn ingesteld op een netwerk, wordt het verkeer via poort 53 omzeild door de NSG's van het subnet.

Belangrijk

Als u Windows DNS-servers gebruikt als aangepaste DNS-servers die DNS-aanvragen doorsturen naar Azure DNS-servers, moet u ervoor zorgen dat u de time-outwaarde voor doorsturen langer dan 4 seconden verhoogt, zodat Azure Recursieve DNS-servers de juiste recursiebewerkingen kunnen uitvoeren.

Zie time-outs voor doorstuurservers en voorwaardelijke doorstuurservers voor meer informatie over dit probleem.

Deze aanbeveling kan ook van toepassing zijn op andere DNS-serverplatforms met een time-outwaarde van 3 seconden of minder.

Als u dit niet doet, kan dit ertoe leiden dat Privé-DNS zonerecords worden omgezet met openbare IP-adressen.

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.

Notitie

Eigenschappen van netwerkverbindingen, zoals IP-adressen van DNS-servers, mogen niet rechtstreeks binnen VM's worden bewerkt. Dit komt doordat ze mogelijk worden gewist tijdens het herstellen van de service wanneer de virtuele netwerkadapter wordt vervangen. Dit is van toepassing op zowel Windows- als Linux-VM's.

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.

Notitie

Als u kiest voor een aangepaste DNS-server voor uw virtuele netwerk, moet u ten minste één IP-adres van de DNS-server opgeven; anders negeert het virtuele netwerk de configuratie en gebruikt het door Azure geleverde DNS.

Notitie

Als u de DNS-instellingen wijzigt voor een virtueel netwerk of virtuele machine die al is geïmplementeerd, moet u voordat de nieuwe DNS-instellingen van kracht worden, een DHCP-leasevernieuwing uitvoeren op alle betrokken VM's in het virtuele netwerk. Voor VM's met het Windows-besturingssysteem kunt u dit doen door rechtstreeks in de VIRTUELE machine te typen ipconfig /renew . De stappen variëren afhankelijk van het besturingssysteem. Raadpleeg de relevante documentatie voor uw type besturingssysteem.

Volgende stappen

Azure Resource Manager-implementatiemodel: