Pochopení 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 Službu Active Directory Domain Services (AD DS) nebo Azure NetApp Files můžou způsobit přerušení přístupu klientů nebo vypršení 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 DNS pro správnou funkčnost. 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 s Active Directory a integraci 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:

Použití IP adres nástroje pro vyrovnávání zatížení s DNS ve službě Azure NetApp Files

Zařízení pro vyrovnávání zatížení je způsob, jak se jedna IP adresa využívá k obsluze více IP adres na 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 adresní záznamy, které udávají adresu IPv4 pro název hostitele. Záznamy AAAA uvádějí IPv6 adresu pro název hostitele. Azure NetApp Files používá záznamy A/AAAA následujícími způsoby: Maskování IP adres za uživatelsky přívětivé názvy hostitelů Žádosti instančního objektu Kerberos Dotazy na kořenovou doménu
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` pro 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 kanonického jména.
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 jsou prezentovány 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 pro požadavky NFS Kerberos. 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 jejich vytvoření, pokud používáte NFS Kerberos.

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

Poznámka:

Pro správné zjišťování a redundanci Key Distribution Center v NFS Kerberos 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ávnou funkčnost.

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

Zvážení

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 nasměrují server DNS k 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 deaktivováno zabezpečení DDNS nebo ověřování Kerberos selže, aktualizace DDNS nefungují.

Dynamický typ DNS Přístav

Standardní DNS UDP 53

Zabezpečení DNS TCP 53
Azure NetApp Files podporuje zabezpečené DDNS pouze se servery DNS Microsoft Active Directory.

Dynamický typ DNS	Přístav
Standardní DNS	UDP 53
Zabezpečení DNS	TCP 53

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

Provádí se dotaz typu 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 typu start of authority (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ů.

Provádí se dotaz typu 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:1111

Provede 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.local

Pro plně kvalifikovaný název domény (FQDN) svazku Azure NetApp Files se vytvoří dotaz typu start of authority (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:1111

Provede 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

Když je zabezpečené DNS povoleno, služba Azure NetApp Files vyjednává se serverem DNS o ověření prostřednictvím GSS pomocí ověřování transakcí tajného klíče pro DNS, čímž zajišťuje, že 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.

Provádí se dotaz typu DNS SOA na IP adresu rozhraní svazku Azure NetApp Files.
Výměna vstupenky služby Kerberos za DNS službu 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 na SOA DNS pro plně kvalifikovaný název domény (FQDN) svazku Azure NetApp Files a na dotaz se obdrží odpověď.
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ů

Provádí se dotaz typu 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:1111

Výměna vstupenky služby Kerberos za DNS službu 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-REP

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í.

    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 TSIG

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.

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 na SOA DNS pro plně kvalifikovaný název domény (FQDN) svazku Azure NetApp Files a na dotaz se obdrží odpověď.

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

Mezi 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 TSIG

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.

    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 pro dotazy DNS.

Prořezávání / vyřazování záznamů DNS

Většina serverů DNS poskytuje metody pro vyřazování a čištění záznamů, jejichž platnost vypršela. Vyřazování pomáhá zabránit tomu, aby zastaralé záznamy nezahlcovaly servery DNS, a tím předchází scénářům, v nichž existují duplicitní záznamy A/AAAA a/nebo PTR, které mohou vést k nepředvídatelným výsledkům pro svazky Azure NetApp Files.

Pokud několik záznamů PTR pro stejnou IP adresu ukazuje na různé názvy hostitelů, mohou žádosti Kerberos selhat, protože se během vyhledávání DNS načítá nesprávný hlavní název služby (SPN). DNS nerozlišuje, který záznam PTR patří ke kterému názvu hostitele; místo toho zpětné vyhledávání používá cyklické dotazování přes každý záznam A/AAAA pro každý nový dotaz.

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 vyžadující DNS pro správnou funkčnost, jako je SMB, duální protokol nebo NFSv4.1 s 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 umožnění 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 Kerberos SMB nebo NFS provedené pro datalake.contoso.com používají Kerberos SPN pro SMB-West-XXXX k poskytnutí přístupu ke svazku.

Použití nástroje nslookup a dig pro dotazy DNS

Servery DNS se dají ručně dotazovat pomocí nástrojů DNS, jako jsou nslookup (klienti Windows a Linuxu) 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 řešení problémů můžete také použít poradce při potížích s Azure připojením.

Příkazy nslookup a dig se dají spustit ze vzdáleného připojení k virtuálnímu počítači (například z Bastionu) nebo přímo na virtuálním počítači pomocí možnosti příkazu spustit na samotném virtuálním počítači.

ve spojení 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)

pracovat s Linuxem

# 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, které byly vytvořeny v organizační jednotce AD DS (uveďte v připojení Azure NetApp Files AD) pro podporu podepisování LDAP služby Azure NetApp Files, LDAP přes TLS, SMB, duálního protokolu nebo svazků 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. Azure NetApp Files neodebere ani neodstraní záznamy PTR za žádných podmínek.

Další kroky

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-06-24

Sdílet prostřednictvím

Pochopení systémů názvů domén ve službě Azure NetApp Files

Informace o serverech DNS

Integrace Azure DNS se službou Azure NetApp Files

Použití IP adres nástroje pro vyrovnávání zatížení s DNS ve službě Azure NetApp Files

Typy záznamů DNS ve službě Azure NetApp Files

Záznamy služeb (SRV) používané se službou Azure NetApp Files

Dynamické DNS

Zvážení

Podrobnosti o dynamické položce DNS

Jak funguje standardní dynamické DNS ve službě Azure NetApp Files

Dynamické DNS prostřednictvím zachytávání paketů

Jak zabezpečené DDNS funguje ve službě Azure NetApp Files

Dynamické DNS prostřednictvím zachytávání paketů

Ukládání DNS do mezipaměti

Prořezávání / vyřazování záznamů DNS

Aliasy DNS a záznamy CNAME (Canonical Name)

Použití nástroje nslookup a dig pro dotazy DNS

ve spojení s Windows

pracovat s Linuxem

Osvědčené postupy DNS ve službě Azure NetApp Files

Další kroky

Váš názor

Další materiály