Naamomzetting voor resources in virtuele Azure-netwerken

Afhankelijk van hoe u Azure gebruikt om IaaS-, PaaS- en hybride oplossingen te hosten, moet u mogelijk toestaan dat de virtuele machines (VM's) en andere resources die in een virtueel netwerk zijn geïmplementeerd, met elkaar kunnen communiceren. Hoewel u communicatie kunt inschakelen met behulp van IP-adressen, is het veel eenvoudiger om namen te gebruiken die gemakkelijk kunnen worden onthouden en die niet veranderen.

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

• Azure DNS privézones instellen
• Door Azure geleverde naamoplossing
• Naamresolutie die gebruikmaakt van uw eigen DNS-server (die mogelijk query's doorsturen naar de door Azure geleverde DNS-servers)

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 naamoplossing:

Door Azure geleverde naamoplossing

De door Azure geboden naamoplossing biedt alleen elementaire gezaghebbende DNS-mogelijkheden. Als u deze optie gebruikt, worden de DNS-zonenamen en -records automatisch beheerd door Azure en kunt u de DNS-zonenamen of de levenscyclus van DNS-records niet beheren. Als u een volledig uitgeruste DNS-oplossing voor uw virtuele netwerken nodig hebt, moet u Azure DNS privézones of door de klant beheerde DNS-servers gebruiken.

Naast de resolutie van openbare DNS-namen biedt Azure interne naamom oplossing voor VM's en rol instances die zich in hetzelfde virtuele netwerk of dezelfde cloudservice bevinden. VM's en exemplaren in een cloudservice delen hetzelfde DNS-achtervoegsel, zodat alleen de hostnaam 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 voor alle virtuele machines in een virtueel netwerk, waardoor de FQDN niet nodig is. DNS-namen kunnen worden toegewezen aan zowel VM's als netwerkinterfaces. Hoewel voor naamoplossing door Azure geen configuratie is vereist, is dit niet de juiste keuze voor alle implementatiescenario's, zoals beschreven in de vorige tabel.

Functies

Door Azure geleverde naamoplossing 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 in combinatie met uw eigen DNS-servers om zowel on-premises als Azure-hostnamen op te lossen.
• U kunt naamom oplossing gebruiken tussen VM's en rol-exemplaren binnen dezelfde cloudservice, zonder dat u een FQDN nodig hebt.
• U kunt naamomzet 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 wilt oplossen.
• U kunt hostnamen gebruiken die uw implementaties het beste beschrijven, in plaats van te werken met automatisch gegenereerde namen.

Overwegingen

Punten om rekening mee te houden wanneer u door Azure geleverde naamoplossing gebruikt:

• Het door Azure gemaakte DNS-achtervoegsel kan niet worden gewijzigd.
• DNS-zoekactie is beperkt tot een virtueel netwerk. DNS-namen die zijn gemaakt voor één virtueel netwerk, kunnen niet worden opgelost 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 Explorer.
• 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 VM. Beperking heeft geen invloed 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.
• 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 Azure DNS IP-adres is 168.63.129.16. Dit is een statisch IP-adres en verandert niet.

Overwegingen voor omgekeerde DNS

Omgekeerde DNS wordt ondersteund in alle virtuele netwerken op basis van ARM. U kunt omgekeerde DNS-query's (PTR-query's) uitgeven om IP-adressen van virtuele machines toe te voegen aan FQDN's van virtuele machines.

• Alle PTR-query's voor IP-adressen van virtuele machines retourneren FQDN's van de vorm [ vmname ] .internal.cloudapp.net
• Forward lookup op FQDN's van de vorm vmname .internal.cloudapp.net wordt opgelost naar [ het IP-adres dat is toegewezen aan de virtuele ] machine.
• Als het virtuele netwerk is gekoppeld aan een Azure DNS privézones als een virtueel registratienetwerk, retourneren de omgekeerde DNS-query's twee records. Eén record heeft de vorm [ vmname ] .[ privatednszonename] en de andere heeft de vorm [ vmname ] .internal.cloudapp.net
• Omgekeerde DNS-zoekactie is beperkt tot een bepaald virtueel netwerk, zelfs als het is verbonden met andere virtuele netwerken. Omgekeerde DNS-query's (PTR-query's) voor IP-adressen van virtuele machines die zich in peered virtuele netwerken bevinden, retourneren NXDOMAIN.
• Als u omgekeerde DNS-functie in een virtueel netwerk wilt uitschakelen, kunt u dit doen door een zone voor reverse lookup te maken met behulp van Azure DNS privézones en deze zone 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 maken 20.10.in-addr.arpa en deze koppelen aan het virtuele netwerk. Tijdens het koppelen van de zone aan uw virtuele netwerk moet u automatische registratie op de koppeling uitschakelen. Deze zone overschrijven de standaard zones voor reverse lookup voor het virtuele netwerk en omdat deze zone leeg is, krijgt u NXDOMAIN voor uw omgekeerde DNS-query's. Zie onze Snelstartgids voor meer informatie over het maken van een privé-DNS-zone en het koppelen ervan aan een virtueel netwerk.

CONFIGURATIE van DNS-client

In deze sectie worden caching aan de clientzijde en nieuwe nieuwe aan de clientzijde beslaat.

Caching aan clientzijde

Niet elke DNS-query hoeft via het netwerk te worden verzonden. Caching aan de clientzijde helpt de latentie te verminderen en de tolerantie voor netwerkproblemen te verbeteren door terugkerende DNS-query's uit een lokale cache om te zetten. DNS-records bevatten een TTL-mechanisme (Time to Live), waarmee de cache de record zo lang mogelijk kan opslaan zonder dat dit van invloed is op de nieuwheid van records. 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 vindt dat er nog geen lokale cache is, voegt u een DNS-cache toe aan elke Linux-VM.

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

• Ubuntu (maakt gebruik van resolvconf):
  • Installeer het pakket dnsmasq met sudo apt-get install dnsmasq .
• SUSE (maakt gebruik van netconf):
  • Installeer het pakket dnsmasq met sudo zypper install dnsmasq .
  • Schakel de dnsmasq-service in met systemctl enable dnsmasq.service .
  • Start de service dnsmasq met systemctl start dnsmasq.service .
  • Bewerk /etc/sysconfig/network/config en wijzig NETCONFIG_DNS_FORWARDER="" in dnsmasq.
  • Werk resolve.conf bij met netconfig update om de cache in te stellen als de lokale DNS-resolver.
• CentOS (maakt gebruik van NetworkManager):
  • Installeer het pakket dnsmasq met sudo yum install dnsmasq .
  • Schakel de dnsmasq-service in met systemctl enable dnsmasq.service .
  • Start de service dnsmasq met systemctl start dnsmasq.service .
  • Voeg prepend domain-name-servers 127.0.0.1; toe aan /etc/dhclient-eth0.conf.
  • Start de netwerkservice opnieuw op met service network restart om de cache in te stellen als de lokale DNS-resolver.

Nieuwe nieuwe proberen aan de clientzijde

DNS is voornamelijk een UDP-protocol. Omdat het UDP-protocol berichtbezorging niet garandeert, 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 het na één seconde opnieuw proberen en daarna na nog eens twee, vier seconden en nog eens vier seconden.
• De standaardinstellingen voor Linux worden na vijf seconden opnieuw ingesteld. We raden u aan de specificaties voor nieuwe poging vijf keer te wijzigen, met intervallen van één seconde.

Controleer de huidige instellingen op een Linux-VM met cat /etc/resolv.conf . Bekijk de optieregel, bijvoorbeeld:

options timeout:1 attempts:5

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

• Ubuntu (maakt gebruik van resolvconf):
  1. Voeg de optiesregel toe aan /etc/resolvconf/resolv.conf.d/tail.
  2. Voer uit resolvconf -u om bij te werken.
• SUSE (maakt gebruik van netconf):
  1. Voeg time-out:1 attempts:5 toe aan de parameter NETCONFIG_DNS_RESOLVER_OPTIONS="" in /etc/sysconfig/network/config.
  2. Voer uit netconfig update om bij te werken.
• CentOS (maakt gebruik van NetworkManager):
  1. Voeg de regel RES_OPTIONS="options timeout:1 attempts:5" toe aan het bestand /etc/sysconfig/network-scripts/ifcfg-eth0.
  2. Werk bij met systemctl restart NetworkManager.service .

Naamresolutie die gebruikmaakt van uw eigen DNS-server

In deze sectie worden VM's, rol instances en web-apps beslaat.

VM's en rol-exemplaren

Uw naamoplossingsbehoeften kunnen verder gaan dan de functies van Azure. U moet bijvoorbeeld Microsoft-Windows Server Active Directory gebruiken en DNS-namen tussen virtuele netwerken oplossen. Voor deze scenario's biedt Azure u de mogelijkheid om uw eigen DNS-servers te gebruiken.

DNS-servers in een virtueel netwerk kunnen DNS-query's doorsturen naar de recursieve resolvers in Azure. Hiermee kunt u hostnamen in dat virtuele netwerk oplossen. Een domeincontroller (DC) die wordt uitgevoerd in Azure kan bijvoorbeeld reageren op DNS-query's voor de domeinen en alle andere query's doorsturen naar Azure. Door query's door te geven, kunnen VM's zowel uw on-premises resources (via de DC) als door Azure geleverde hostnamen (via de doorsturende functie) zien. Toegang tot de recursieve resolvers in Azure wordt geboden via het virtuele IP-adres 168.63.129.16.

Doorsturen via DNS maakt ook DNS-resolutie tussen virtuele netwerken mogelijk en biedt uw on-premises machines de mogelijkheid om door Azure geleverde hostnamen om te zetten. 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 in elk virtueel netwerk verschilt, kunt u regels voor voorwaardelijk doorsturen gebruiken om DNS-query's naar het juiste virtuele netwerk te verzenden voor oplossing. In de volgende afbeelding ziet u twee virtuele netwerken en een on-premises netwerk met DNS-resolutie tussen virtuele netwerken, met behulp van deze methode. Er is een voorbeeld van een DNS-doorsturende server beschikbaar in de galerie Azure-quickstartsjablonen en GitHub.

Wanneer u door Azure geleverde naamresolutie gebruikt, biedt Azure Dynamic Host Configuration Protocol (DHCP) een intern DNS-achtervoegsel (.internal.cloudapp.net) voor elke VM. Dit achtervoegsel maakt hostnaamresolutie mogelijk omdat de hostnaamrecords zich in de internal.cloudapp.net zone. Wanneer u uw eigen oplossing voor naamomoplossing gebruikt, wordt dit achtervoegsel niet aan VM's geleverd omdat het andere DNS-architecturen verstoort (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 netwerkinterface REST API,de PowerShell-cmdlet Get-AzNetworkInterface en de Azure CLI-opdracht az network nic show.
• In klassieke implementatiemodellen is het achtervoegsel beschikbaar via de aanroep Implementatie-API of de cmdlet Get-AzureVM -Debug.

Als het doorsturen van query's naar Azure niet aan uw behoeften past, moet u uw eigen DNS-oplossing bieden. Uw DNS-oplossing moet:

• Geef de juiste hostnaamresolutie op, bijvoorbeeld via DDNS. Als u DDNS gebruikt, moet u het opruimen van DNS-records mogelijk 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 gebruikt en toegang hebben tot internet.
• Wees beveiligd tegen toegang via internet om bedreigingen van externe agents te beperken.

Web-apps

Stel dat u naamomoplossing 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. Naast het instellen van een aangepaste DNS-server met een DNS-doorsturendeserver die query's doorsturen naar Azure (virtueel IP-adres 168.63.129.16), moet u de volgende stappen uitvoeren:

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

2. Selecteer in Azure Portal het App Service-abonnement dat als host voor de web-app wordt gebruikt de optie Netwerk synchroniseren onder Netwerken , Virtual Network Integration.

   

Als u naamom oplossing wilt uitvoeren vanuit uw web-app die is gebouwd met behulp van App Service, gekoppeld aan een virtueel netwerk, naar VM's in een ander virtueel netwerk, moet u als volgt aangepaste DNS-servers op beide virtuele netwerken gebruiken:

• Stel een DNS-server in het virtuele doelnetwerk in op een virtuele machine die ook query's kan doorsturen naar de recursieve resolver in Azure (virtueel IP-adres 168.63.129.16). Er is een voorbeeld van een DNS-doorsturende server beschikbaar in de galerie Azure-quickstartsjablonen en GitHub.
• Stel een DNS-doorsturende machine in het virtuele bronnetwerk in op een virtuele machine. Configureer deze DNS-doorsturen voor het doorsturen van query's 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 met het virtuele bronnetwerk.Volg de instructies in Uw app integreren met een virtueel netwerk.
• Selecteer in Azure Portal het App Service-abonnement dat als host voor de web-app wordt gebruikt de optie Netwerk synchroniseren onder Netwerken , Virtual Network Integration.

DNS-servers opgeven

Wanneer u uw eigen DNS-servers gebruikt, biedt Azure de mogelijkheid om meerdere DNS-servers per virtueel netwerk op te geven. 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 implementatiemodel Azure Resource Manager, kunt u DNS-servers opgeven voor een virtueel netwerk en een netwerkinterface. Zie Manage a virtual network (Een virtueel netwerk beheren) en Manage a network interface (Een netwerkinterface beheren) voor meer informatie.

Wanneer u het klassieke implementatiemodel gebruikt, kunt u DNS-servers voor het virtuele netwerk opgeven in het Azure Portal of het netwerkconfiguratiebestand. Voor cloudservices kunt u DNS-servers opgeven via het serviceconfiguratiebestand of met behulp van PowerShell, met New-AzureVM.

Volgende stappen

Azure Resource Manager implementatiemodel:

• Een virtueel netwerk beheren
• Een netwerkinterface beheren

Klassiek implementatiemodel:

• Azure-serviceconfiguratieschema
• Virtual Network-configuratieschema
• Een Virtual Network configureren met behulp van een netwerkconfiguratiebestand