Aracılığıyla paylaş

Azure sanal ağlarındaki kaynaklar için ad çözümlemesi

Azure'da hizmet olarak altyapı (IaaS), hizmet olarak platform (PaaS) ve karma çözümler barındırabilirsiniz. Sanal ağdaki VM'ler ve diğer kaynaklar arasında iletişimi etkinleştirmek için birbirleriyle iletişim kurmalarına izin vermelisiniz. Kolay hatırlanan ve tutarlı adlar kullanmak, IP adreslerine güvenmek yerine iletişim sürecini basitleştirir.

Sanal ağlara dağıtılan kaynakların etki alanı adlarını iç IP adreslerine çözümlemesi gerektiğinde, dört yöntemden birini kullanabilir:

Kullandığınız ad çözümlemesi türü, kaynaklarınızın birbirleriyle nasıl iletişim kurmaları gerektiğine bağlıdır. Aşağıdaki tabloda senaryolar ve buna karşılık gelen ad çözümleme çözümleri gösterilmektedir.

Azure Özel DNS bölgeleri tercih edilen çözümdür ve DNS bölgelerinizi ve kayıtlarınızı yönetme konusunda size esneklik sağlar. Daha fazla bilgi için bkz. Azure DNS'yi özel etki alanları için kullanma.

Not

Azure tarafından sağlanan DNS kullanıyorsanız, vm'lerinize uygun DNS son eki otomatik olarak uygulanır. Diğer tüm seçenekler için, tam etki alanı adlarını (FQDN' ler) kullanmanız veya vm'lerinize uygun DNS son ekini el ile uygulamanız gerekir.

Senaryo Çözüm DNS son eki
Aynı sanal ağda bulunan VM'ler veya aynı bulut hizmetindeki Azure Cloud Services rol örnekleri arasında ad çözümlemesi. Azure Özel DNS bölgeleri veya Azure tarafından sağlanan ad çözümlemesi Ana bilgisayar adı veya FQDN
Farklı sanal ağlardaki VM'ler veya farklı bulut hizmetlerindeki rol örnekleri arasında ad çözümlemesi. Azure Özel DNS bölgeleri, Azure DNS Özel Çözümleyicisi veya azure tarafından çözümlenmek üzere sanal ağlar arasında sorgular ileten müşteri tarafından yönetilen DNS sunucuları (DNS ara sunucusu). Bkz. Kendi DNS sunucunuzu kullanarak ad çözümleme. Yalnızca FQDN
Aynı sanal ağdaki rol örneklerine veya VM'lere, sanal ağ tümleştirmesi kullanarak bir Azure Uygulama Hizmeti'nden (web uygulaması, işlev veya bot) ad çözümlemesi. Azure DNS Özel Çözümleyicisi veya azure tarafından çözümlenmek üzere sanal ağlar arasında sorgular ileten müşteri tarafından yönetilen DNS sunucuları (DNS ara sunucusu). Bkz. Kendi DNS sunucunuzu kullanarak ad çözümleme. Yalnızca FQDN
App Service web uygulamalarından aynı sanal ağdaki VM'lere isim çözümlemesi. Azure DNS Özel Çözümleyicisi veya azure tarafından çözümlenmek üzere sanal ağlar arasında sorgular ileten müşteri tarafından yönetilen DNS sunucuları (DNS ara sunucusu). Bkz. Kendi DNS sunucunuzu kullanarak ad çözümleme. Yalnızca FQDN
Bir sanal ağdaki App Service web uygulamalarından, farklı bir sanal ağdaki VM'lere ad çözümlemesi. Azure DNS Özel Çözümleyicisi veya azure tarafından çözümlenmek üzere sanal ağlar arasında sorgular ileten müşteri tarafından yönetilen DNS sunucuları (DNS ara sunucusu). Bkz. Kendi DNS sunucunuzu kullanarak ad çözümleme. Yalnızca FQDN
Azure'daki VM'lerden veya rol örneklerinden şirket içi bilgisayar ve hizmet adlarının çözümü. Azure DNS Özel Çözümleyicisi veya müşteri tarafından yönetilen DNS sunucuları (örneğin, şirket içi etki alanı denetleyicisi, yerel salt okunur etki alanı denetleyicisi veya bölge aktarımları kullanılarak eşitlenen bir DNS ikincil sunucusu). Bkz. Kendi DNS sunucunuzu kullanarak ad çözümleme. Yalnızca FQDN
Şirket içi bilgisayarlardan Azure ana bilgisayar adlarının çözümü. Sorguları ilgili sanal ağda müşteri tarafından yönetilen bir DNS proxy sunucusuna iletin. Ara sunucu, çözümleme için sorguları Azure'a iletir. Bkz. Kendi DNS sunucunuzu kullanarak ad çözümleme. Yalnızca FQDN
İç IP'ler için TERS DNS. Kendi DNS sunucunuzu kullanarak Azure Özel DNS bölgeleri, Azure tarafından sağlanan ad çözümlemesi, Azure DNS Özel Çözümleyicisi veya Ad çözümleme. Uygulanamaz
Sanal ağda değil, farklı bulut hizmetlerinde bulunan VM'ler veya rol örnekleri arasındaki ad çözümlemesi. Uygulanamaz. Sanal ağ dışında farklı bulut hizmetlerindeki VM'ler ve rol örnekleri arasındaki bağlantı desteklenmez. Uygulanamaz

Azure tarafından sağlanan ad çözümlemesi

Azure tarafından sağlanan ad çözümlemesi yalnızca temel yetkili DNS özellikleri sağlar. Azure tarafından sağlanan DNS'yi kullanıyorsanız DNS bölgesi adlarını ve kayıtlarını Azure yönetir. DNS bölge adlarını veya DNS kayıtlarının yaşam döngüsünü denetleyemezsiniz. Sanal ağlarınız için tam özellikli bir DNS çözümüne ihtiyacınız varsa, Azure Özel DNS bölgelerini Müşteri tarafından yönetilen DNS sunucuları veya Azure DNS Özel Çözümleyici ile kullanabilirsiniz.

Azure, genel DNS adlarının çözümlenmesiyle birlikte, aynı sanal ağ veya bulut hizmetinde bulunan VM'ler ve rol örnekleri için iç ad çözümlemesi sağlar. Bir bulut hizmetindeki VM'ler ve örnekler aynı DNS sonekini paylaştığından yalnızca ana makine adı yeterlidir. Ancak klasik dağıtım modeli kullanılarak dağıtılan sanal ağlarda farklı bulut hizmetleri farklı DNS son eklerine sahiptir. Bu durumda, farklı bulut hizmetleri arasındaki adları çözümlemek için FQDN'ye ihtiyacınız vardır.

Azure Resource Manager dağıtım modeli kullanılarak dağıtılan sanal ağlarda DNS soneki, bir sanal ağ içindeki tüm VM'lerde tutarlı olduğundan FQDN gerekli değildir. HEM VM'lere hem de ağ arabirimlerine DNS adları atayabilirsiniz. Azure tarafından sağlanan ad çözümlemesi herhangi bir yapılandırma gerektirmese de, önceki tabloda açıklandığı gibi tüm dağıtım senaryoları için uygun seçenek değildir.

Not

Azure Cloud Services web ve çalışan rollerini kullandığınızda, Azure Hizmet Yönetimi REST API'sini kullanarak rol örneklerinin iç IP adreslerine de erişebilirsiniz. Daha fazla bilgi için bkz . Hizmet Yönetimi REST API başvurusu. Adres, rol adını ve örnek numarasını temel alır.

Özellikler

Azure tarafından sağlanan ad çözümlemesi aşağıdaki özellikleri içerir:

  • Hiçbir şeyi yapılandırmanız gerekmez.
  • Yüksek kullanılabilirlik nedeniyle kendi DNS sunucularınızın kümelerini oluşturmanız ve yönetmeniz gerekmez.
  • Hem şirket içi hem de Azure ana bilgisayar adlarını çözümlemek için hizmeti kendi DNS sunucularınızla kullanabilirsiniz.
  • FQDN'ye gerek kalmadan, aynı bulut hizmeti içindeki VM'ler ve rol örnekleri arasında ad çözümlemesi kullanabilirsiniz.
  • FQDN'ye gerek kalmadan Resource Manager dağıtım modelini kullanan sanal ağlardaki VM'ler arasında ad çözümlemesi kullanabilirsiniz. Klasik dağıtım modelindeki sanal ağlar, farklı bulut hizmetlerindeki adları çözümlerken bir FQDN gerektirir.
  • Otomatik olarak oluşturulan adlarla çalışmak yerine dağıtımlarınızı en iyi açıklayan konak adlarını kullanabilirsiniz.

Dikkat edilmesi gereken noktalar

Azure tarafından sağlanan ad çözümlemesini kullanırken aşağıdaki noktaları göz önünde bulundurun:

  • Azure tarafından oluşturulan DNS soneki değiştirilemez.
  • DNS araması, bir sanal ağla sınırlıdır. Bir sanal ağ için oluşturulan DNS adları diğer sanal ağlardan çözümlenemez.
  • Kendi kayıtlarınızın el ile kaydedilmesine izin verilmez.
  • WINS ve NetBIOS desteklenmez. Windows Gezgini'nde VM'lerinizi göremezsiniz.
  • Ana bilgisayar adları DNS ile uyumlu olmalıdır. Adlar yalnızca 0 - 9, a - z ve kısa çizgi (-) kullanmalıdır. Adlar kısa çizgiyle başlayamaz veya bitemez.
  • DNS sorgu trafiği her VM için kısıtlanır. Bant genişliği kısıtlaması çoğu uygulamayı etkilememelidir. İstek kısıtlamasını gözlemlerseniz, istemci tarafı önbelleğinin etkinleştirildiğinden emin olun. Daha fazla bilgi için bkz . DNS istemci yapılandırması.
  • DNS çözümleme sorunlarını önlemek için bir sanal ağdaki her VM için farklı bir ad kullanılmalıdır.
  • Klasik dağıtım modelindeki her sanal ağ için yalnızca ilk 180 bulut hizmetindeki VM'ler kaydedilir. Bu sınır Resource Manager'daki sanal ağlar için geçerli değildir.
  • Azure DNS IP adresi 168.63.129.16'dır. Bu adres statik bir IP adresidir ve değişmez.

Ters DNS ile ilgili dikkat edilmesi gerekenler

Vm'ler için ters DNS, Resource Manager'a dayalı tüm sanal ağlarda desteklenir. İşaretçi (PTR) olarak da bilinen Azure tarafından yönetilen ters DNS, vm başlattığınızda form \[vmname\].internal.cloudapp.net kayıtları otomatik olarak DNS'ye eklenir. VM durdurulduğunda (serbest bırakıldığında) kaldırılırlar. Aşağıdaki örneğe bakın:

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

Ters internal.cloudapp.net DNS bölgesi Azure tarafından yönetilir ve doğrudan görüntülenemez veya düzenlenemez. Form \[vmname\].internal.cloudapp.net FQDN'si üzerinden yapılan ileri arama, VM'ye atanmış IP adresini çözümler.

Bir Azure Özel DNS bölgesi sanal ağ bağlantısıyla sanal ağa bağlıysa ve bu bağlantıda otomatik kayıt etkinleştirildiyse, ters DNS sorguları iki kayıt döndürür. Kayıtlardan biri şu şekilde \[vmname\].[privatednszonename], diğeri ise şu şekilde \[vmname\].internal.cloudapp.net. Aşağıdaki örneğe bakın:

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

Daha önce gösterildiği gibi iki PTR kaydı döndürüldüğünde, her iki FQDN'nin ileri araması VM'nin IP adresini döndürür.

Ters DNS sorgulamalarının kapsamı, diğer sanal ağlarla bağlantılı olsa bile belirli bir sanal ağla sınırlıdır. Eşlenmiş sanal ağlarda bulunan VM'lerin IP adresleri için yapılan ters DNS sorguları NXDOMAIN döndürür.

Ters DNS (PTR) kayıtları ileriye dönük özel DNS bölgesinde depolanmaz. Ters DNS kayıtları ters DNS (in-addr.arpa) bölgesinde depolanır. Sanal ağ ile ilişkili varsayılan ters DNS bölgesi görüntülenebilir veya düzenlenebilir değildir.

Sanal ağda ters DNS işlevini devre dışı bırakabilirsiniz. Azure Özel DNS bölgelerini kullanarak kendi geriye doğru arama bölgenizi oluşturun. Ardından bu bölgeyi sanal ağınıza bağlayın. Örneğin, sanal ağınızın IP adresi alanı 10.20.0.0/16 ise, boş bir özel DNS bölgesi 20.10.in-addr.arpa oluşturabilir ve sanal ağa bağlayabilirsiniz. Bu bölge, sanal ağ için varsayılan geriye doğru arama bölgelerini geçersiz kılar. Bu bölge boş. Bu girdileri el ile oluşturmadığınız sürece TERS DNS döndürür NXDOMAIN .

PTR kayıtlarının otomatik olarak kaydı desteklenmez. Girdiler oluşturmak istiyorsanız, bunları el ile girin. Diğer bölgeler için etkinleştirilmişse sanal ağda otomatik kaydı devre dışı bırakmanız gerekir. Bu sınırlama, otomatik kayıt etkinleştirildiğinde yalnızca bir özel bölgenin bağlanmasına izin veren kısıtlamalardan dolayıdır. Özel DNS bölgesi oluşturma ve bunu bir sanal ağa bağlama hakkında bilgi için bkz. Azure Özel DNS hızlı başlangıcı.

Not

Azure DNS özel bölgeleri genel olduğundan, birden çok sanal ağa yayılacak ters DNS araması oluşturabilirsiniz. Ters aramalar (bölge) için bir in-addr.arpa oluşturmanız ve bunu sanal ağlara bağlamanız gerekir. VM'ler için ters DNS kayıtlarını el ile yönetmeniz gerekir.

DNS istemci yapılandırması

Bu bölüm, istemci tarafı önbelleğe alma ve istemci tarafı yeniden denemelerini kapsar.

İstemci taraflı önbellekleme

Her DNS sorgusunun ağ üzerinden gönderilmesine gerek yok. İstemci tarafı önbelleğe alma, yerel önbellekten yinelenen DNS sorgularını çözümleyerek gecikme süresini azaltmaya ve ağ blips dayanıklılığını geliştirmeye yardımcı olur. DNS kayıtları, önbelleğin kaydın güncelliğini etkilemeden kaydı mümkün olduğunca uzun süre depolamasına olanak tanıyan bir yaşam süresi mekanizması içerir. İstemci tarafı önbelleğe alma çoğu durumda uygundur.

Varsayılan Windows DNS istemcisinin yerleşik bir DNS önbelleği vardır. Bazı Linux dağıtımları varsayılan olarak önbelleğe almayı içermez. Henüz yerel bir önbellek olmadığını fark ederseniz, her Linux VM'sine bir DNS önbelleği ekleyin.

Birçok farklı DNS önbelleğe alma paketi mevcuttur (örneğin dnsmasq). En yaygın dağıtımlara şu şekilde yüklenir dnsmasq :

RHEL (NetworkManager kullanır)

  1. dnsmasq Paketi aşağıdaki komutla yükleyin:

    sudo yum install dnsmasq

  2. dnsmasq Hizmeti aşağıdaki komutla etkinleştirin:

    systemctl enable dnsmasq.service

  3. dnsmasq Hizmeti aşağıdaki komutla başlatın:

    systemctl start dnsmasq.service

  4. prepend domain-name-servers 127.0.0.1; öğesini /etc/dhclient-eth0.conf öğesine eklemek için bir metin düzenleyicisi kullanın.

  5. Ağ hizmetini yeniden başlatmak için aşağıdaki komutu kullanın:

    service network restart

Not

Paket dnsmasq , Linux için kullanılabilen birçok DNS önbelleğinden yalnızca biridir. Kullanmadan önce, özel gereksinimlerinize uygun olup olmadığını denetleyin ve başka bir önbelleğin yüklü olup olmadığını denetleyin.

İstemci tarafı yeniden denemeleri

DNS öncelikli olarak bir Kullanıcı Veri Birimi Protokolüdür (UDP). UDP protokolü ileti teslimini garanti etmediğinden, dns protokolünde yeniden deneme mantığı işlenir. Her DNS istemcisi (işletim sistemi), oluşturucunun tercihlerine bağlı olarak farklı yeniden deneme mantığı sergileyebilir:

  • Windows işletim sistemleri bir saniye sonra yeniden dener ve ardından iki saniye, dört saniye ve başka bir dört saniye sonra yeniden dener.
  • Varsayılan Linux kurulumu beş saniye sonra yeniden denenir. Yeniden deneme belirtimlerini bir saniyelik aralıklarla beş kez olarak değiştirmenizi öneririz.

ile cat /etc/resolv.confbir Linux VM'sinde geçerli ayarları denetleyin. Satıra options bakın, örneğin:

options timeout:1 attempts:5

Dosya resolv.conf otomatik olarak oluşturulur ve düzenlenmemelidir. options satırını eklemek için belirli adımlar dağıtımdan dağıtıma farklılık gösterir.

RHEL (NetworkManager kullanır)

  1. Satırı RES_OPTIONS="options timeout:1 attempts:5" dosyasına /etc/sysconfig/network-scripts/ifcfg-eth0eklemek için bir metin düzenleyicisi kullanın.

  2. Hizmeti yeniden başlatmak NetworkManager için aşağıdaki komutu kullanın:

    systemctl restart NetworkManager.service

Kendi DNS sunucunuzu kullanan ad çözümlemesi

Bu bölüm VM'leri, rol örneklerini ve web uygulamalarını kapsar.

Not

Azure DNS Özel Çözümleyicisi , sanal ağda VM tabanlı DNS sunucularını kullanma gereksiniminin yerini alır. VM tabanlı bir DNS çözümü kullanmak istiyorsanız aşağıdaki bölüm sağlanır. Azure DNS Özel Çözümleyicisi'ni kullanmanın birçok avantajı maliyet azaltma, yerleşik yüksek kullanılabilirlik, ölçeklenebilirlik ve esnekliktir.

VM'ler ve rol örnekleri

Ad çözümleme gereksinimleriniz Azure tarafından sağlanan özelliklerin ötesine geçebilir. Örneğin, sanal ağlar arasındaki DNS adlarını çözümlemek için Windows Server Active Directory etki alanlarını kullanmanız gerekebilir. Bu senaryoları ele almak için kendi DNS sunucularınızı kullanabilirsiniz.

Sanal ağ içindeki DNS sunucuları, DNS sorgularını Azure'daki özyinelemeli çözümleyicilere iletebilir. Bu yordamı kullanarak, bu sanal ağ içindeki konak adlarını çözümleyebilirsiniz. Örneğin, Azure'da çalışan bir etki alanı denetleyicisi (DC), etki alanları için DNS sorgularını yanıtlayabilir ve diğer tüm sorguları Azure'a iletebilir. sorguları iletme, VM'lerin hem şirket içi kaynaklarınızı (DC aracılığıyla) hem de Azure tarafından sağlanan konak adlarını (iletici aracılığıyla) görmesini sağlar. Azure'da özyinelemeli çözümleyicilere 168.63.129.16 sanal IP üzerinden erişim sağlanır.

Önemli

Azure VPN Gateway bu kurulumda sanal ağdaki özel DNS sunucusu IP'leriyle birlikte kullanılıyorsa, bozulmamış hizmeti korumak için Azure DNS IP'sinin (168.63.129.16) listeye eklenmesi gerekir.

DNS iletme ayrıca sanal ağlar arasında DNS çözümlemesini etkinleştirir ve şirket içi makinelerinizin Azure tarafından sağlanan konak adlarını çözümlemesine olanak tanır. Bir VM'nin ana bilgisayar adını çözümlemek için DNS sunucusu VM'sinin aynı sanal ağda bulunması ve konak adı sorgularını Azure'a iletecek şekilde yapılandırılması gerekir. DNS soneki her sanal ağda farklı olduğundan, dns sorgularını çözümlemek üzere doğru sanal ağa göndermek için koşullu iletme kurallarını kullanabilirsiniz.

Aşağıdaki diyagramda gösterildiği gibi iki sanal ağ ve bir şirket içi ağ, sanal ağlar arasında DNS çözümlemesi yapmak için bu yöntemi kullanır. Örnek bir DNS ileticisi, Azure Hızlı Başlangıç Şablonları galerisinde ve GitHub'da kullanılabilir.

Not

Rol örneği, aynı sanal ağ içindeki VM'lerin ad çözümlemesini gerçekleştirebilir. VM'nin ana bilgisayar adı ve internal.cloudapp.net DNS son ekinden oluşan FQDN'yi kullanır. Bu durumda, ad çözümlemesi yalnızca rol örneğinin Rol Şemasında (.cscfg dosyası) tanımlanan VM adına sahip olması durumunda başarılı olur: <Role name="<role-name>" vmName="<vm-name>">.

Başka bir sanal ağdaki VM'lerin ad çözümlemesini (sonekini kullanarak internal.cloudapp.net FQDN) gerçekleştirmesi gereken rol örneklerinin bu bölümde açıklanan yöntemi kullanması gerekir (iki sanal ağ arasında iletilen özel DNS sunucuları).

Sanal ağlar arasındaki DNS'yi gösteren diyagram .

Azure tarafından sağlanan ad çözümlemesini kullandığınızda, Azure Dinamik Ana Bilgisayar Yapılandırma Protokolü (DHCP) her vm için bir iç DNS son eki (.internal.cloudapp.net) sağlar. Bu sonek, ana bilgisayar adı kayıtları internal.cloudapp.net bölgesinde bulunduğu için konak adı çözümlemesini etkinleştirir. Kendi ad çözümleme çözümünüzü kullandığınızda, bu sonek diğer DNS mimarileriyle (etki alanına katılmış senaryolar gibi) etkileşime girdiği için VM'lere sağlanmaz. Bunun yerine Azure, işlevsiz bir yer tutucu (reddog.microsoft.com) sağlar.

Gerekirse, PowerShell'i veya API'yi kullanarak iç DNS sonekini belirleyebilirsiniz.

Resource Manager dağıtım modellerindeki sanal ağlar için, ek bilgileri ağ arabirimi REST API'si, Get-AzNetworkInterface PowerShell cmdleti ve az network nic show Azure CLI komutu aracılığıyla alabilirsiniz.

Sorguları Azure'a iletmek gereksinimlerinize uygun değilse kendi DNS çözümünüzü sağlayın veya Azure DNS Özel Çözümleyicisi'ne dağıtın.

Kendi DNS çözümünüzü sağlarsanız aşağıdakiler gerekir:

  • Örneğin, dinamik DNS (DDNS) aracılığıyla uygun ana bilgisayar adı çözümlemesini sağlayın. DDNS kullanıyorsanız DNS kaydı atma özelliğini devre dışı bırakmanız gerekebilir. Azure DHCP kiralamaları uzun ve temizleme işlemi DNS kayıtlarını erken kaldırabilir.
  • Dış etki alanı adlarının çözümlenebilmesi için uygun özyinelemeli çözümü temin edin.
  • Hizmet verdiği istemciler tarafından erişilebilir olmalı (bağlantı noktası 53'te TCP ve UDP) ve internet erişimine açık olmalıdır.
  • Dış aracılar tarafından ortaya konan tehditleri azaltmak için İnternet'ten erişime karşı güvenlik altına alın.

En iyi performans için Azure VM'lerini DNS sunucusu olarak kullandığınızda IPv6 devre dışı bırakılmalıdır.

Ağ güvenlik grupları (NSG), DNS çözümleyici uç noktalarınız için güvenlik duvarı görevi görür. DNS dinleyici uç noktalarınıza UDP Bağlantı Noktası 53 (ve isteğe bağlı olarak TCP Bağlantı Noktası 53) erişimine izin vermek için NSG güvenlik kurallarınızı değiştirin veya geçersiz kılın. Bir ağda özel DNS sunucuları ayarlandıktan sonra, 53 numaralı bağlantı noktası üzerinden gelen trafik alt ağın ve NIC'nin NSG'lerini atlar.

Önemli

Dns isteklerini Azure DNS sunucularına ileten özel DNS sunucuları olarak Windows DNS sunucularını kullanıyorsanız, Azure özyinelemeli DNS sunucularının düzgün özyineleme işlemleri gerçekleştirmesine izin vermek için İletme Zaman Aşımı değerini dört saniyeden fazla artırdığınızdan emin olun.

Bu sorun hakkında daha fazla bilgi için İleticiler ve koşullu ileticiler çözümleme zaman aşımı konusunda bilgi edinebilirsiniz.

Bu öneri, iletme zaman aşımı değerleri üç saniye veya daha kısa olan diğer DNS sunucusu platformları için de geçerli olabilir.

Bunun başarısız olması, Özel DNS bölge kayıtlarının genel IP adresleriyle çözümlenmesine neden olabilir.

Web uygulamaları

Bir sanal ağa bağlı app Service kullanılarak oluşturulan web uygulamanızdan aynı sanal ağdaki VM'lere ad çözümlemesi yapmanız gerektiğini varsayalım. Sorguları Azure'a (sanal IP 168.63.129.16) ileden DNS ileticisi olan özel bir DNS sunucusu ayarlamaya ek olarak, aşağıdaki adımları gerçekleştirin:

  • Henüz yapmadıysanız, Uygulamanızı sanal ağ ile tümleştirme bölümünde açıklandığı gibi web uygulamanız için sanal ağ tümleştirmesini etkinleştirin.
  • Sanal ağa bağlı web uygulamanızdan (App Service kullanılarak oluşturulan) aynı özel bölgeye bağlı olmayan farklı bir sanal ağdaki VM'lere ad çözümlemesi gerçekleştirmeniz gerekiyorsa, her iki sanal ağda da özel DNS sunucuları veya Azure DNS Özel Çözümleyicileri kullanın.

Özel DNS sunucularını kullanmak için:

  • Azure'da özyinelemeli çözümleyiciye (sanal IP 168.63.129.16) sorgu iletebilen bir VM üzerinde hedef sanal ağınızda bir DNS sunucusu ayarlayın. Örnek bir DNS ileticisi, Azure Hızlı Başlangıç Şablonları galerisinde ve GitHub'da kullanılabilir.
  • Vm'deki kaynak sanal ağda bir DNS ileticisi ayarlayın. Sorguları hedef sanal ağınızdaki DNS sunucusuna iletmek için bu DNS ileticisini yapılandırın.
  • Kaynak sanal ağınızın ayarlarında kaynak DNS sunucunuzu yapılandırın.
  • Uygulamanızı sanal ağ ile tümleştirme başlığındaki yönergeleri izleyerek web uygulamanızın kaynak sanal ağa bağlanması için sanal ağ tümleştirmesini etkinleştirin.

Azure DNS Özel Çözümleyicisi'ni kullanmak için bkz . Kural kümesi bağlantıları.

DNS sunucularını belirtme

Kendi DNS sunucularınızı kullandığınızda, sanal ağ başına birden çok DNS sunucusu belirtebilirsiniz. Ağ arabirimi başına (Resource Manager için) veya bulut hizmeti başına (klasik dağıtım modeli için) birden çok DNS sunucusu da belirtebilirsiniz. Bir ağ arabirimi veya bulut hizmeti için belirtilen DNS sunucuları, sanal ağ için belirtilen DNS sunucularına göre önceliklidir.

Not

DNS sunucusu IP'leri gibi ağ bağlantısı özellikleri doğrudan VM'ler içinde düzenlenmemelidir. Sanal ağ bağdaştırıcısı değiştirildiğinde hizmet bakımı sırasında silinebilirler. Bu uyarı hem Windows hem de Linux VM'leri için geçerlidir.

Resource Manager dağıtım modelini kullandığınızda, sanal ağ ve ağ arabirimi için DNS sunucuları belirtebilirsiniz. Daha fazla bilgi için bkz . Sanal ağı yönetme ve Ağ arabirimini yönetme.

Sanal ağınız için özel DNS sunucusunu tercih ederseniz en az bir DNS sunucusu IP adresi belirtmeniz gerekir. Aksi takdirde, sanal ağ yapılandırmayı yoksayar ve bunun yerine Azure tarafından sağlanan DNS'yi kullanır.

Not

Zaten dağıtılmış bir sanal ağ veya VM'nin DNS ayarlarını değiştirirseniz, yeni DNS ayarlarının etkili olması için, sanal ağdaki tüm etkilenen VM'lerde DHCP kira yenilemesi gerçekleştirmeniz gerekir. Windows işletim sistemini çalıştıran VM'ler için doğrudan VM'ye girin ipconfig /renew . Adımlar işletim sistemine bağlı olarak değişir. İşletim sistemi türünüz için ilgili belgelere bakın.

İlgili içerik

Azure Resource Manager dağıtım modeli: