Principy systémů názvů domén ve službě Azure NetApp Files
Azure NetApp Files podporuje použití integrovaných serverů DNS nebo samostatných serverů DNS služby Active Directory a vyžaduje spolehlivý přístup ke službám DNS (Domain Name System) a aktuálním záznamům DNS. Špatné síťové připojení mezi Azure NetApp Files a servery DNS může způsobit přerušení přístupu klientů nebo vypršení časového limitu klienta. Neúplné nebo nesprávné záznamy DNS pro Doména služby Active Directory Services (AD DS) nebo Azure NetApp Files můžou způsobit přerušení přístupu klientů nebo vypršení časového limitu klienta.
Služba DNS je důležitou součástí přístupu k datům ve službě Azure NetApp Files. Přístup k souborovým protokolům přes protokol SMB, NFSV4.1 Kerberos, LDAP a zjišťování lokalit služby Active Directory výrazně využívají DNS pro své operace. Použití názvu hostitele centrálně umístěného v DNS zjednodušuje přístup ke svazku a chrání před scénáři při změně IP adresy. Místo toho, aby správce potřeboval informovat uživatele o nové IP adrese, můžou uživatelé dál používat uživatelsky přívětivý název hostitele.
Servery DNS se konfigurují v rámci připojení služby Active Directory. Můžete přidat primární a sekundární server a také název DNS služby Active Directory.
Poznámka:
Osvědčeným postupem je nakonfigurovat více než jeden server DNS pro redundanci.
Informace o serverech DNS
Azure NetApp Files vyžaduje připojení Active Directory pro funkce protokolu SMB a NFSv4.1 Kerberos. Služba Active Directory vyžaduje, aby služba DNS správně funkčnosti. Ve většině případů se nasazení služby Active Directory instalují se servery DNS integrovanými s řadiči domény. Tato konfigurace je osvědčeným postupem microsoftu pro snadné použití a zajištění vytvoření všech požadovaných záznamů DNS pro doménové služby.
V některých případech je možné externí servery DNS (například BIND) používat místo (nebo kromě) služeb DNS hostovaných službou Active Directory. Tomu se říká nesouvislý obor názvů.
Azure NetApp Files podporuje použití integrovaných i externích serverů DNS, ale pokud používáte externí servery DNS bez integrace služby Active Directory, je důležité zajistit, aby se do DNS přidaly potřebné záznamy služby (SRV), aby se zajistilo správné funkce a redundance služeb. Špatné síťové připojení mezi Azure NetApp Files a servery DNS může způsobit přerušení přístupu klientů nebo vypršení časového limitu klienta. Nekompletní nebo nesprávné záznamy DNS pro SLUŽBU AD DS nebo Azure NetApp Files můžou způsobit přerušení přístupu klientů nebo vypršení časového limitu klienta.
Seznam záznamů SRV, které služba používá, najdete v záznamech DNS ve službě Azure NetApp Files . Projděte si také pokyny pro DNS se službou Active Directory a integrací služby AD DS do stávající infrastruktury DNS.
Integrace Azure DNS se službou Azure NetApp Files
Azure DNS je hostovaná služba pro správu a překlad názvů DNS v Microsoft Azure. Můžete ho použít k vytvoření veřejných nebo privátních názvů DNS pro jiné aplikace a služby, které nasadíte v Azure – včetně Azure NetApp Files. Nasazení DNS v Azure brání nutnosti odesílat požadavky DNS (přes port 53) přímo mezi Azure NetApp Files a místním DNS nebo doménou Active Directory. Kromě toho je možné použít Azure DNS k vytváření podmíněných předávacích procesů (pomocí překladače Azure Privátní DNS), které je možné použít k odesílání požadavků DNS ze služby Azure NetApp Files na konkrétní servery DNS prostřednictvím privátních serverů DNS hostovaných v Azure, které je možné zadat pro použití v připojení Active Directory.
Informace o používání Azure DNS:
- Jak Azure DNS funguje s dalšími službami Azure
- Rychlý start: Vytvoření zóny a záznamu Azure DNS pomocí webu Azure Portal
- Rychlý start: Vytvoření privátní zóny DNS Azure pomocí webu Azure Portal
- Rychlý start: Vytvoření privátního překladače Azure DNS pomocí webu Azure Portal
Použití IP adres nástroje pro vyrovnávání zatížení s DNS ve službě Azure NetApp Files
Zařízení nástroje pro vyrovnávání zatížení je způsob, jak se jedna IP adresa používá k poskytování služby více IP adres v back-endu. To zajišťuje zabezpečení prostřednictvím obfuskace a také výhod výkonu a redundance pro podniková prostředí.
Nástroj pro vyrovnávání zatížení DNS může obsluhovat požadavky a odesílat je na několik serverů DNS určených ve fondu. Microsoft Azure poskytuje nativní služby vyrovnávání zatížení pro více případů použití.
Azure NetApp Files podporuje použití nástrojů pro vyrovnávání zatížení DNS za předpokladu, že poskytují IP adresu jako koncový bod a tato IP adresa může komunikovat přes port 53 se sítěmi Azure NetApp Files. Azure Traffic Manager například poskytuje vyrovnávání zatížení DNS na vrstvě 7, ale poskytuje pouze front-endový název hostitele pro použití. Připojení Active Directory služby Azure NetApp Files umožňují zadat pouze IP adresy pro servery DNS.
Typy záznamů DNS ve službě Azure NetApp Files
Azure NetApp Files používá pro přístup k souborovým službám různé typy záznamů DNS.
| Typ záznamu DNS | Definice |
|---|---|
| A/AAAA | Záznamy DNS A jsou záznamy adres, které označují adresu IPv4 pro název hostitele. Záznamy AAAA označují adresu IPv6 názvu hostitele. Azure NetApp Files používá záznamy A/AAAA následujícími způsoby:
|
| Záznamy ukazatelů (PTR) | Záznam PTR mapuje IP adresu na název hostitele prostřednictvím zóny zpětného vyhledávání. Záznamy PTR se primárně používají v případě, že je pro připojení nebo sdílenou složku v Azure NetApp Files zadaná IP adresa. Použití IP adresy v žádostech o připojení nebo sdílení může mít vliv na použitou metodu ověřování. Další informace najdete v tématu IP adresy pro přístup pomocí protokolu Kerberos. |
| Záznamy služeb (SRV) |
Záznamy SRV se používají k určení, kteří hostitelé a porty se používají pro konkrétní službu, jako je LDAP, NFS, CIFS, Kerberos atd. Záznamy SRV ve službě Azure NetApp Files se silně využívají pro zabezpečení souborové služby (například Kerberos), zjišťování lokalit ve službě Active Directory, dotazy na server LDAP a další. Je důležité ověřit existenci těchto záznamů pro správné funkce služeb Azure NetApp Files. Záznamy SRV je možné dotazovat pomocí nslookup příkazů nebo dig příkazů. Příklady najdete v tématu Použití nslookup a dig dotazy DNS. |
| Kanonické názvy (CNAME) | Záznam CNAME představuje způsob, jak poskytnout aliasy DNS pro záznamy A/AAAA. Záznamy CNAME jsou volitelné, ale můžou být užitečné ke snížení složitosti záznamů názvu hostitele poskytovaných službou Azure NetApp Files. Další informace najdete v tématu Aliasy DNS a záznamy Canonical Name. |
| Identifikátor URI (Uniform Resource Identifier) |
Záznam URI je způsob, jak mapovat názvy hostitelů a IP adresy pro služby na identifikátory URI. Identifikátory URI se zobrazují ve formátu: service://fqdn.contoso.com. Azure NetApp Files využívá dotazy na záznamy URI pouze při vyhledávání Kerberos KDC protokolu Kerberos pro požadavky NFS. Záznamy URI se ve výchozím nastavení nevytvořily v nasazeních DNS služby Active Directory. Proto požadavky vyhledávání identifikátoru URI obvykle selžou a přejdou zpět na vyhledávání záznamů SRV. |
Záznamy služeb (SRV) používané se službou Azure NetApp Files
Azure NetApp Files používá následující záznamy SRV:
-
NFS Kerberos*
- _kerberos-master._tcp. CONTOSO.COM (port 88)*
- _kerberos-master._tcp. CONTOSO.COM (port 88)*
-
Zjišťování lokality SMB/Active Directory**
- _kerberos.CONTOSO.COM (port 88)
- _kerberos._tcp. CONTOSO.COM (port 88)
- _kerberos._tcp.dc_msdcs. CONTOSO.COM (port 88)
- _kpasswd._tcp.dc._msdcs. CONTOSO.COM (port 464)
- _kpasswd._tcp. CONTOSO.COM (port 464)
- _kerberos._tcp. Default-First-Site-Name._sites.dc._msdcs. CONTOSO.COM (port 88)
- _kerberos._tcp. {other site names}._sites.dc._msdcs. CONTOSO.COM (port 88)
- _kerberos.udp.CONTOSO.COM (port 88)
- _kerberos._udp.dc_msdcs. CONTOSO.COM (port 88)
- _kpasswd._udp.dc._msdcs. CONTOSO.COM (port 464)
- _kpasswd._udp. CONTOSO.COM (port 464)
- _kerberos._udp. Default-First-Site-Name._sites.dc._msdcs. CONTOSO.COM (port 88)
- _kerberos._udp. {other site names}._sites.dc._msdcs. CONTOSO.COM (port 88)
-
LDAP**
- _ldap.CONTOSO.COM (port 389)
- _ldap._tcp. CONTOSO.COM (port 389)
- _ldap._udp. CONTOSO.COM (port 389)
* Dns služby Active Directory ve výchozím nastavení tyto záznamy SRV nevytvoří. Důrazně doporučujeme je vytvořit, pokud používáte kerberos systému souborů NFS.
** Dns služby Active Directory vytvoří tyto záznamy SRV ve výchozím nastavení.
Další informace o tom, jak Azure NetApp Files používá záznamy SRV, najdete tady:
- Vysvětlení použití protokolu LDAP ve službě Azure NetApp Files
- Informace o protokolu Kerberos ve službě Azure NetApp Files
Poznámka:
Pro správné zjišťování a redundanci centra distribuce klíčů v protokolu Kerberos systému souborů NFS musí být vytvořeny záznamy URI nebo záznamy SRV hlavního serveru kerberos.
Dynamické DNS
Svazky Azure NetApp Files poskytují jednu IP adresu svazku, který se pak automaticky přidá do DNS prostřednictvím dynamického DNS (DDNS) (pokud je na serveru DNS podporován dynamický DNS). Názvy hostitelů (místo IP adres) se používají pro cesty připojení svazků v konkrétních konfiguracích. Použití názvů hostitelů v cestách připojení vyžaduje dns pro správné funkce:
- Svazky SMB
- Kerberos NFSv4.1
- Svazky se dvěma protokoly
Kerberos NFSv4.1:
SMB
Duální protokol
IP adresa se používá pro cestu připojení, když svazek Azure NetApp File nevyžaduje DNS, například NFSv3 nebo NFSv4.1 bez protokolu Kerberos.
NFSv3
Důležité informace
Dynamické aktualizace DNS v Azure NetApp Files odesílají na nakonfigurovaný server DNS dva různé požadavky: jeden pro PTR a jeden pro vytvoření nebo aktualizaci záznamu A/AAAA.
Svazky Azure NetApp Files vytvořené s názvy hostitelů automaticky upozorní server DNS na vytvoření záznamu A/AAAA. K tomu dochází okamžitě po dokončení vytváření svazku.
Pokud záznam DNS A/AAAAA již existuje pro kombinaci NÁZVU IP adresy nebo hostitele, nebudou vytvořeny žádné nové záznamy.
Pokud záznam DNS A/AAAAA existuje pro stejný název hostitele s jinou IP adresou, vytvoří se druhý záznam A/AAAAA se stejným názvem.
U svazků Azure NetApp Files vytvořených bez názvů hostitelů (například svazků NFSv3) nevytvoří dynamické DNS záznamy DNS, protože ve službě není přiřazen žádný název hostitele. Záznamy musí být vytvořeny ručně.
Pokud existuje zóna zpětného vyhledávání pro podsíť PROTOKOLU IP rozhraní, server DNS vytvoří také záznam PTR. Pokud potřebná zóna zpětného vyhledávání neexistuje, záznam PTR se nedá vytvořit automaticky. Záznam PTR musíte vytvořit ručně.
Pokud se na serveru DNS odstraní položka DNS vytvořená dynamickým DNS, vytvoří se do 24 hodin novou dynamickou aktualizací DNS ze služby Azure NetApp Files.
Zabezpečené DDNS se povolí při vytváření svazků SMB nebo duálních protokolů. Svazky NFS nepovolují zabezpečené DDNS, ale umožňují DDNS. Pokud je na serveru DNS zakázané zabezpečené DDNS nebo ověřování Kerberos selže, aktualizace DDNS nefungují.
Dynamický typ DNS Port Standardní DNS UDP 53 Zabezpečení DNS TCP 53 Azure NetApp Files podporuje zabezpečené DDNS pouze se servery DNS Microsoft Active Directory.
Podrobnosti o dynamické položce DNS
Když Azure NetApp Files vytvoří záznam DNS A/AAAAA prostřednictvím dynamického DNS, použijí se následující konfigurace:
- Je zaškrtnuto přidružené pole záznamu PTR: Pokud existují zóny zpětného vyhledávání pro podsíť, záznamy A/AAAA automaticky vytvářejí záznamy PTR bez zásahu správce.
- Zaškrtnuto políčko Odstranit tento záznam, když se stane zastaralým: Když se záznam DNS změní na zastaralý, DNS záznam odstraní, za předpokladu, že je povolené odstraňování pro DNS.
- Hodnota TTL záznamu DNS je nastavená na jeden den (24 hodin): Nastavení hodnoty TTL může podle potřeby upravit správce DNS. Hodnota TTL záznamu DNS určuje dobu, po kterou záznam DNS existuje v mezipaměti DNS klienta.
Poznámka:
Pokud chcete zobrazit časová razítka a hodnotu TTL (Time to Live), když byl záznam DNS vytvořen v DNS služby Windows Active Directory, přejděte do nabídky Zobrazení správce DNS a pak vyberte Upřesnit. Odtud vyberte položku záznamu A/AAAA A a zobrazte vlastnosti.
Jak funguje standardní dynamické DNS ve službě Azure NetApp Files
Azure NetApp Files se řídí čtyřmi základními kroky pro vytvoření dynamických aktualizací DNS na nakonfigurovaných serverech DNS. Standardní dynamické aktualizace DNS (DDNS) procházejí přes port UDP 53.
- Provede se dotaz DNS SOA na IP adresu rozhraní svazku Azure NetApp Files.
- Provede se aktualizace DDNS pro PTR. Pokud PTR neexistuje, vytvoří se.
- Pro plně kvalifikovaný název domény (FQDN) svazku Azure NetApp Files se vytvoří dotaz NA ZAČÁTEK AUTORITY (SOA).
- Provede se aktualizace DDNS pro záznam A/AAAA. Pokud záznam neexistuje, vytvoří se.
Dynamické DNS prostřednictvím zachytávání paketů
Zachytávání paketů může být užitečné při řešení potíží se službou, které nemusí mít k dispozici protokolování k analýze. Rozbalte toto zobrazení, kde najdete podrobné informace o zachytávání paketů.
Provede se dotaz DNS SOA na IP adresu rozhraní svazku Azure NetApp Files.
143 x.x.x.y x.x.x.x DNS 86 Standard query 0x77c8 SOA y.x.x.x.in-addr.arpa 144 x.x.x.x x.x.x.y DNS 229 Standard query response 0x77c8 No such name SOA y.x.x.x.in-addr.arpa SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111 AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111Provede se aktualizace DDNS pro PTR. Pokud PTR neexistuje, vytvoří se.
145 x.x.x.y x.x.x.x DNS 121 Dynamic update 0x1a43 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local 146 x.x.x.x x.x.x.y DNS 121 Dynamic update response 0x1a43 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.localPro plně kvalifikovaný název domény (FQDN) svazku Azure NetApp Files se vytvoří dotaz NA ZAČÁTEK AUTORITY (SOA).
147 x.x.x.y x.x.x.x DNS 81 Standard query 0xcfab SOA ANF1234.anf.local 148 x.x.x.x x.x.x.y DNS 214 Standard query response 0xcfab No such name SOA ANF1234.anf.local SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111Provede se aktualizace DDNS pro záznam A/AAAA. Pokud záznam neexistuje, vytvoří se.
149 x.x.x.y x.x.x.x DNS 97 Dynamic update 0x83b2 SOA anf.local A x.x.x.y 150 x.x.x.x x.x.x.y DNS 97 Dynamic update response 0x83b2 SOA anf.local A x.x.x.y
Jak zabezpečené DDNS funguje ve službě Azure NetApp Files
Pokud je povolené zabezpečené DNS, Služba Azure NetApp Files vyjedná se serverem DNS k ověření prostřednictvím služby GSS pomocí ověřování pomocí transakce tajného klíče pro DNS a zajišťuje, aby požadované aktualizace pocházejí z legitimního zdroje. Následující postup ukazuje kroky použité během tohoto procesu. Zabezpečené aktualizace DDNS procházejí přes port TCP 53.
- Provede se dotaz DNS SOA na IP adresu rozhraní svazku Azure NetApp Files.
- Lístek služby Kerberos se vyměňuje pro službu DNS na serveru DNS.
- Lístek se pak použije v dotazu DNS na klíč transakce (TKEY) ze služby Azure NetApp Files na server DNS, který se předává pomocí GSS-TSIG (podpis transakce) k ověření.
- Po úspěšném ověření se pomocí TKEY odešle zabezpečená dynamická aktualizace DNS k vytvoření PTR pomocí GSS-TSIG. Pokud záznam ještě neexistuje, vytvoří se.
- Odešle se dotaz SOA DNS pro plně kvalifikovaný název domény (FQDN) svazku Azure NetApp Files a odpoví na.
- Mezi serverem DNS a službou Azure NetApp Files se vyměňuje nové ID TKEY.
- K vytvoření záznamu A/AAAA pro plně kvalifikovaný název domény se odešle zabezpečená dynamická aktualizace DNS. Pokud záznam již existuje se stejnou IP adresou, neprovedou se žádné změny.
Dynamické DNS prostřednictvím zachytávání paketů
Zachytávání paketů může být užitečné při řešení potíží se službou, které nemusí mít k dispozici protokolování k analýze. Rozbalte toto zobrazení, kde najdete podrobné informace o zachytávání paketů.
Provede se dotaz DNS SOA na IP adresu rozhraní svazku Azure NetApp Files.
1135 x.x.x.y x.x.x.x DNS 86 Standard query 0xd29a SOA y.x.x.x.in-addr.arpa 1136 x.x.x.x x.x.x.y DNS 229 Standard query response 0xd29a No such name SOA y.x.x.x.in-addr.arpa SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111Lístek služby Kerberos se vyměňuje pro službu DNS na serveru DNS.
1141 x.x.x.y x.x.x.x KRB5 406 TGS-REQ • SNameString: DNS • SNameString: dc1.anf.local 1143 x.x.x.x x.x.x.y KRB5 1824 TGS-REPLístek se pak použije v dotazu DNS na klíč transakce (TKEY) ze služby Azure NetApp Files na server DNS, který se předává pomocí GSS-TSIG (podpis transakce) k ověření.
1152 x.x.x.y x.x.x.x DNS 191 Standard query 0x147c TKEY 1492998148.sig-dc1.anf.local TKEY • Name: 1492998148.sig-dc1.anf.local • Type: TKEY (249) (Transaction Key) • Algorithm name: gss-tsig 1154 x.x.x.x x.x.x.y DNS 481 Standard query response 0x147c TKEY 1492998148.sig-dc1.anf.local TKEY TSIGPo úspěšném ověření se pomocí TKEY odešle zabezpečená dynamická aktualizace DNS k vytvoření PTR pomocí GSS-TSIG. Pokud záznam ještě neexistuje, vytvoří se.
1155 x.x.x.y x.x.x.x DNS 240 Dynamic update 0xf408 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local TSIG • Zone o x.x.x.in-addr.arpa: type SOA, class IN o y.x.x.x.in-addr.arpa: type PTR, class IN, ANF1234.anf.local • Type: PTR (12) (domain name PoinTeR) o Additional records o 1492998148.sig-dc1.anf.local: type TSIG, class ANY 1156 x.x.x.x x.x.x.y DNS 240 Dynamic update response 0xf408 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local TSIG • Updates o y.x.x.x.in-addr.arpa: type PTR, class IN, ANF1234.anf.local o Type: PTR (12) (domain name PoinTeR)Odešle se dotaz SOA DNS pro plně kvalifikovaný název domény (FQDN) svazku Azure NetApp Files a odpoví na.
1162 x.x.x.y x.x.x.x DNS 81 Standard query 0xe872 SOA ANF1234.anf.local 1163 x.x.x.x x.x.x.y DNS 214 Standard query response 0xe872 No such name SOA ANF1234.anf.local SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111 AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111Mezi serverem DNS a službou Azure NetApp Files se vyměňuje nové ID TKEY.
1165 x.x.x.y x.x.x.x DNS 191 Standard query 0x020e TKEY 1260534462.sig-dc1.anf.local TKEY 1167 x.x.x.x x.x.x.y DNS 481 Standard query response 0x020e TKEY 1260534462.sig-dc1.anf.local TKEY TSIGK vytvoření záznamu A/AAAA pro plně kvalifikovaný název domény se odešle zabezpečená dynamická aktualizace DNS. Pokud záznam již existuje se stejnou IP adresou, neprovedou se žádné změny.
1168 x.x.x.y x.x.x.x DNS 216 Dynamic update 0x014a SOA anf.local A x.x.x.y TSIG • Zone o anf.local: type SOA, class IN • Updates o ANF1234.anf.local: type A, class IN, addr x.x.x.y o Type: A (1) (Host Address) o Address: x.x.x.y • Additional records o 1260534462.sig-dc1.anf.local: type TSIG, class ANY 1170 x.x.x.x x.x.x.y DNS 216 Dynamic update response 0x014a SOA anf.local A x.x.x.y TSIG • Updates o ANF1234.anf.local: type A, class IN, addr x.x.x.y o Type: A (1) (Host Address)
Ukládání DNS do mezipaměti
Aby se snížilo zatížení serverů DNS, používají klienti DNS koncepty ukládání do mezipaměti k ukládání předchozích dotazů do paměti, aby se opakované požadavky na název hostitele, IP adresu nebo službu uchovávaly místně po dobu definovanou TTL záznamu DNS.
Azure NetApp Files využívá mezipaměti DNS stejně jako jakýkoli jiný standardní klient DNS. Když služba požádá o záznam DNS, má tento záznam definovaný hodnotu TTL. Ve výchozím nastavení mají položky DNS služby Active Directory hodnotu TTL 600 sekund (10 minut), pokud není uvedeno jinak. Pokud se záznam DNS aktualizuje a žije v mezipaměti Azure NetApp Files a hodnota TTL je 10 minut, nový záznam se v Azure NetApp Files neaktualizuje, dokud se mezipaměť nevyprázdní po vypršení časového limitu. V současné době neexistuje způsob, jak tuto mezipaměť ručně vyprázdnit. Pokud potřebujete nižší hodnotu TTL, proveďte změnu ze serveru DNS.
Při použití externích serverů DNS (například BIND) se výchozí hodnoty časového limitu můžou lišit. Pokud není definováno, hodnota TTL záznamu DNS BIND je 604 800 sekund (sedm dní), protože efektivní ukládání do mezipaměti DNS je příliš dlouhé. Proto při ručním vytváření záznamů DNS je důležité ručně nastavit hodnotu TTL záznamu na rozumnou hodnotu. Použití výchozího nastavení Microsoftu 10 minut se doporučuje pro kombinaci výkonu a spolehlivosti vyhledávání DNS.
Hodnotu TTL záznamu DNS můžete zadat ručně pomocí nslookup příkazů nebo dig příkazů. Příklady najdete v tématu Použití nslookup a dig dotazy DNS.
Vyřazování záznamů DNS / scavenging
Většina serverů DNS poskytuje metody pro vyřazování a scavenge záznamů s vypršenou platností. Vyřazování pomáhá zabránit zastaralým záznamům v nepotřebných serverech DNS a vytváření scénářů, kdy existují duplicitní záznamy A/AAAA a/nebo PTR, které můžou vytvářet nepředvídatelné výsledky pro svazky Azure NetApp Files.
Pokud několik záznamů PTR pro stejný bod IP adresy na různé názvy hostitelů může selhat, protože se během vyhledávání DNS načítá nesprávný hlavní název služby (SPN). DNS nerozpozná, který záznam PTR patří do kterého názvu hostitele; zpětné vyhledávání místo toho provádí vyhledávání pomocí kruhového dotazování prostřednictvím každého záznamu A/AAAA pro každý nový vyhledávání.
Například:
C:\> nslookup x.x.x.x
Server: contoso.com
Address: x.x.x.x
Name: ANF-1234.contoso.com
Address: x.x.x.x
C:\> nslookup x.x.x.x
Server: contoso.com
Address: x.x.x.x
Name: ANF-5678.contoso.com
Address: x.x.x.x
Aliasy DNS a záznamy CNAME (Canonical Name)
Azure NetApp Files vytvoří název hostitele DNS pro svazek, který je nakonfigurovaný pro protokol, který vyžaduje DNS pro správné funkce, jako je SMB, duální protokol nebo NFSv4.1 s Protokolem Kerberos. Vytvořený název používá formát serveru SMB (účet počítače) jako předponu při vytváření připojení služby Active Directory pro účet NetApp; Přidají se nadbytečné alfanumerické znaky, aby více položek svazků ve stejném účtu NetApp měly jedinečné názvy. Ve většině případů se několik svazků, které vyžadují názvy hostitelů a existují ve stejném účtu NetApp, pokusí použít stejné názvy hostitelů nebo IP adresy. Pokud je například název serveru SMB SMB-West.contoso.com, položky názvu hostitele se řídí formátem SMB-West-XXXX.contoso.com.
V některých případech nemusí být název používaný službou Azure NetApp Files dostatečně uživatelsky přívětivý k předání koncovým uživatelům nebo správci můžou chtít, aby při migraci dat z místního úložiště do služby Azure NetApp Files používali lépe známé názvy DNS (tj. pokud byl původní název DNS datalake.contoso.com, můžou koncoví uživatelé chtít tento název dál používat).
Azure NetApp Files nativně neumožňuje specifikaci použitých názvů hostitelů DNS. Pokud požadujete alternativní název DNS se stejnou funkcí, měli byste použít alias DNS nebo kanonický název (CNAME).
Použití záznamu CNAME (místo dalšího záznamu A/AAAA), který odkazuje na záznam A/AAAA svazku Azure NetApp Files, využívá stejný hlavní název služby (SPN) jako server SMB k povolení přístupu kerberos pro záznam A/AAAA I CNAME. Představte si příklad záznamu A/AAAAA SMB-West-XXXX.contoso.com. Záznam CNAME datalake.contoso.com je nakonfigurovaný tak, aby odkazoval zpět na záznam A/AAAA SMB-West-XXXX.contoso.com. Požadavky protokolu KERBEROS protokolu SMB nebo NFS provedené pro datalake.contoso.com k poskytnutí přístupu ke svazku pomocí hlavního názvu služby Kerberos pro SMB-West-XXXX.
Použití nástroje nslookup a dig pro dotazy DNS
Servery DNS se dají ručně dotazovat pomocí nástrojů DNS, jako nslookup jsou (klienti Windows a Linux) a dig (klienti Linuxu). Použití těchto nástrojů je užitečné ve scénářích, včetně pokusu o ověření funkčnosti služeb, testování názvu hostitele nebo překladu IP adres, vyhledávání existujících nebo zastaralých záznamů DNS, kontrola konfigurace serveru, ověření hodnoty TTL. K dalšímu řešení problémů můžete použít také poradce při potížích s připojením Azure.
Příkazy nslookup a dig příkazy se dají spustit ze vzdáleného připojení k virtuálnímu počítači (například z Bastionu) nebo přímo k virtuálnímu počítači prostřednictvím možnosti příkazu spustit na samotném virtuálním počítači.
nslookup s Windows
Můžete spustit nslookup shromažďování základních informací o IP adresách bez jakýchkoli možností:
C:\>nslookup anf.local
Server: dns.anf.local
Address: x.x.x.a
Name: anf.local
Addresses: x.x.x.x
x.x.x.y
Pokud chcete dotazovat pouze informace TTL záznamu -query=hinfo , použijte možnost příkazu.
C:\>nslookup -query=hinfo anf.local
Server: dns.anf.local
Address: x.x.x.a
anf.local
primary name server = dns.anf.local
responsible mail addr = root.dns.anf.local
serial = 7
refresh = 604800 (7 days)
retry = 86400 (1 day)
expire = 2419200 (28 days)
default TTL = 604800 (7 days)
Tuto -debug možnost můžete použít také ke shromáždění podrobnějších informací o záznamu DNS.
C:\>nslookup -debug anf.local
------------
Got answer:
HEADER:
opcode = QUERY, id = 1, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
x.x.x.x.in-addr.arpa, type = PTR, class = IN
ANSWERS:
-> x.x.x.x.in-addr.arpa
name = dns.anf.local
ttl = 604800 (7 days)
------------
Server: dns.anf.local
Address: x.x.x.a
------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
anf.local.ANF.LOCAL, type = A, class = IN
AUTHORITY RECORDS:
-> anf.local
ttl = 604800 (7 days)
primary name server = dns.anf.local
responsible mail addr = root.dns.anf.local
serial = 7
refresh = 604800 (7 days)
retry = 86400 (1 day)
expire = 2419200 (28 days)
default TTL = 604800 (7 days)
dig with Linux
# dig anf.local
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> anf.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12196
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;anf.local. IN A
;; ANSWER SECTION:
anf.local. 604800 IN A x.x.x.x
anf.local. 604800 IN A x.x.x.y
;; Query time: 0 msec
;; SERVER: 10.193.67.250#53(10.193.67.250)
;; WHEN: Thu Aug 29 15:27:47 EDT 2024
;; MSG SIZE rcvd: 70
Osvědčené postupy DNS ve službě Azure NetApp Files
Ujistěte se, že splňujete následující požadavky na konfiguraci DNS:
- V konfiguraci DNS zadejte více než jeden server DNS pro redundanci.
- Nejlepších výsledků dosáhnete pomocí DNS integrovaného a/nebo nainstalovaného se službou Active Directory.
- Pokud používáte samostatné servery DNS:
- Ujistěte se, že servery DNS mají síťové připojení k delegované podsíti Služby Azure NetApp Files hostující svazky Azure NetApp Files.
- Ujistěte se, že síťové porty UDP 53 a TCP 53 nejsou blokovány branami firewall nebo skupinami zabezpečení sítě.
- Ujistěte se, že byly záznamy SRV zaregistrované službou AD DS Net Logon vytvořeny na serverech DNS a také záznamy služby uvedené v typech záznamů DNS v Azure NetApp Files.
- Ujistěte se, že se záznamy PTR pro řadiče domény AD DS používané službou Azure NetApp Files vytvořily na serverech DNS ve stejné doméně jako vaše konfigurace Azure NetApp Files.
- Azure NetApp Files podporuje standardní a zabezpečené dynamické aktualizace DNS. Pokud požadujete zabezpečené dynamické aktualizace DNS, ujistěte se, že jsou zabezpečené aktualizace nakonfigurované na serverech DNS.
- Ujistěte se, že pro podsíť Azure NetApp Files byla vytvořena zóna zpětného vyhledávání, která umožňuje dynamickému DNS vytvářet záznamy PTR kromě záznamu A/AAAA.
- Pokud se vyžaduje alias DNS, použijte záznam CNAME. Nasměrujte záznam CNAME na záznamy A/AAAA pro Azure NetApp Files.
- Pokud nepoužíváte dynamické aktualizace DNS, musíte ručně vytvořit záznam A a záznam PTR pro účty počítačů služby AD DS vytvořené v organizační jednotce SLUŽBY AD DS (zadané v připojení Azure NetApp Files AD) pro podporu podepisování protokolu LDAP Služby Azure NetApp Files, PROTOKOLU LDAP přes TLS, SMB, duální protokol nebo svazky Kerberos NFSv4.1.
- U složitých nebo rozsáhlých topologií služby AD DS se můžou vyžadovat zásady DNS nebo stanovení priorit podsítě DNS pro podporu svazků NFS s podporou protokolu LDAP.
- Pokud je povolené scavenging DNS (kde se automaticky vyřadí zastaralé položky DNS na základě časového razítka/stáří) a dynamické DNS se použilo k vytvoření záznamů DNS pro svazek Azure NetApp Files, může proces scavengeru neúmyslně vyřazení záznamů pro svazek. Toto vyřazení může vést k výpadku služby pro dotazy založené na názvech. Dokud se tento problém nevyřeší, ručně vytvořte záznamy DNS A/AAAA a PTR pro svazek Azure NetApp Files, pokud je povolené vytváření dns.