Förstå domännamnssystem i Azure NetApp Files
Azure NetApp Files stöder användning av Active Directory-integrerade DNS- eller fristående DNS-servrar och kräver tillförlitlig åtkomst till DNS-tjänster (Domain Name System) och uppdaterade DNS-poster. Dålig nätverksanslutning mellan Azure NetApp Files- och DNS-servrar kan orsaka avbrott i klientåtkomsten eller tidsgränser för klienten. Ofullständiga eller felaktiga DNS-poster för Active Directory-domän Services (AD DS) eller Azure NetApp Files kan orsaka avbrott i klientåtkomst eller tidsgränser för klienten.
DNS-tjänsten är en viktig komponent för dataåtkomst i Azure NetApp Files. Filprotokollåtkomst via SMB, NFSV4.1 Kerberos, LDAP och Active Directory Site Discovery använder alla DNS i betydande grad för sina åtgärder. Att använda ett värdnamn centralt i DNS förenklar åtkomsten till en volym och skyddar mot scenarier när en IP-adress ändras. I stället för att en administratör behöver informera användarna om en ny IP-adress kan användarna fortsätta att använda det användarvänliga värdnamnet.
DNS-servrar konfigureras under Active Directory-anslutningar. En primär och sekundär server kan läggas till, samt Active Directory DNS-namnet.
Kommentar
Vi rekommenderar att du konfigurerar mer än en DNS-server för redundans.
Om DNS-servrar
Azure NetApp Files kräver en Active Directory-anslutning för SMB- och NFSv4.1 Kerberos-funktioner. Active Directory kräver DNS för rätt funktioner. I de flesta fall installeras Active Directory-distributioner med DNS-servrar som är integrerade med domänkontrollanterna. Den här konfigurationen är microsofts bästa praxis för både användarvänlighet och för att säkerställa att alla nödvändiga DNS-poster skapas för domäntjänster.
I vissa fall kan externa DNS-servrar (till exempel BIND) användas i stället för (eller utöver) Active Directory-värdbaserade DNS-tjänster. Detta kallas för ett osammanhängande namnområde.
Azure NetApp Files stöder användning av både integrerade och externa DNS-servrar, men när du använder externa DNS-servrar utan Active Directory-integrering är det viktigt att se till att nödvändiga tjänstposter (SRV) läggs till i DNS för korrekt funktionalitet och redundans av tjänster. Dålig nätverksanslutning mellan Azure NetApp Files- och DNS-servrar kan orsaka avbrott i klientåtkomsten eller tidsgränser för klienten. Ofullständiga eller felaktiga DNS-poster för AD DS eller Azure NetApp Files kan orsaka avbrott i klientåtkomsten eller tidsgränser för klienten.
En lista över SRV-poster som tjänsten använder finns i DNS-poster i Azure NetApp Files . Läs även riktlinjerna för DNS med Active Directory och integrera AD DS i en befintlig DNS-infrastruktur.
Azure DNS-integrering med Azure NetApp Files
Azure DNS är en värdbaserad DNS-hanterings- och namnmatchningstjänst i Microsoft Azure. Du kan använda den för att skapa offentliga eller privata DNS-namn för andra program och tjänster som du distribuerar i Azure – inklusive Azure NetApp Files. Om du distribuerar DNS i Azure hindrar du behovet av att skicka DNS-begäranden (via port 53) direkt mellan Azure NetApp Files och lokal DNS och/eller en Active Directory-domän. Dessutom kan Azure DNS användas för att skapa villkorsstyrda vidarebefordrare (med hjälp av Azure Privat DNS resolver) som kan användas för att skicka DNS-begäranden från Azure NetApp Files till specifika DNS-servrar via de privata DNS-servrar som finns i Azure, som kan anges för användning i Active Directory-anslutningen.
Information om hur du använder Azure DNS:
- Så här fungerar Azure DNS med andra Azure-tjänster
- Snabbstart: Skapa en Azure DNS-zon och post med hjälp av Azure Portal
- Snabbstart: Skapa en privat DNS-zon i Azure med hjälp av Azure Portal
- Snabbstart: Skapa en privat Lösning för Azure DNS med hjälp av Azure Portal
Använda IP-adresser för lastbalanserare med DNS i Azure NetApp Files
En lastbalanserare är ett sätt för en enskild IP-adress att användas för att betjäna flera IP-adresser på serverdelen. Detta ger säkerhet via fördunkling, samt prestanda- och redundansfördelar för företagsmiljöer.
En DNS-lastbalanserare kan skicka begäranden och skicka dem till flera DNS-servrar som har angetts i en pool. Microsoft Azure tillhandahåller interna belastningsutjämningstjänster för flera användningsfall.
Azure NetApp Files stöder användning av DNS-lastbalanserare, förutsatt att de anger en IP-adress som en slutpunkt och att IP-adressen kan kommunicera via port 53 till Azure NetApp Files-nätverken. Azure Traffic Manager tillhandahåller till exempel DNS-belastningsutjämning på nivå 7, men tillhandahåller bara ett klientdelsvärdnamn för användning. Azure NetApp Files Active Directory-anslutningar tillåter endast att IP-adresser anges för DNS-servrar.
Typer av DNS-poster i Azure NetApp Files
Azure NetApp Files använder olika typer av DNS-poster för åtkomst till filtjänster.
| DNS-posttyp | Definition |
|---|---|
| A/AAAA | DNS A-poster är adressposter som anger IPv4-adressen för ett värdnamn. AAAA-poster anger IPv6-adressen för ett värdnamn. Azure NetApp Files använder A/AAAA-poster på följande sätt:
|
| Pekarposter (PTR) | En PTR-post mappar en IP-adress till ett värdnamn via en omvänd uppslagszon. PTR-poster används främst när en IP-adress anges för en montering/resurs i Azure NetApp Files. Användning av en IP-adress i monterings-/resursbegäranden kan påverka den autentiseringsmetod som används. Mer information finns i IP-adresser för åtkomst med Kerberos. |
| Tjänstposter (SRV) |
SRV-poster används för att ange vilka värdar och portar som används för en specifik tjänst, till exempel LDAP, NFS, CIFS, Kerberos osv. SRV-poster i Azure NetApp Files används mycket för filtjänstsäkerhet (till exempel Kerberos), platsidentifiering i Active Directory, LDAP-serverfrågor med mera. Det är viktigt att verifiera att dessa poster finns för korrekt funktionalitet i Azure NetApp Files-tjänster. SRV-poster kan efterfrågas med hjälp av nslookup eller dig kommandon. Exempel finns i Använda nslookup och dig för DNS-frågor. |
| Kanoniska namn (CNAME) | En CNAME-post är ett sätt att ange DNS-alias för A/AAAA-poster. CNAME-poster är valfria men kan vara användbara för att minska komplexiteten för värdnamnsposterna som tillhandahålls av Azure NetApp Files. Mer information finns i DNS-alias och kanoniska namnposter. |
| URI (Uniform Resource Identifier) | En URI-post är ett sätt att mappa värdnamn/IP-adresser för tjänster till URI:er. URI:er visas i ett format som: service://fqdn.contoso.com. Azure NetApp Files använder endast frågor för URI-poster när kerberos KDC-sökningar utförs för NFS Kerberos-begäranden. URI-poster skapas inte i Active Directory DNS-distributioner som standard. Därför misslyckas vanligtvis URI-sökningsbegäranden och återgår till SRV-postsökningar. |
Tjänstposter (SRV) som används med Azure NetApp Files
Azure NetApp Files använder följande SRV-poster:
-
NFS Kerberos*
- _kerberos-master._tcp. CONTOSO.COM (port 88)*
- _kerberos-master._tcp. CONTOSO.COM (port 88)*
-
SMB/Active Directory-platsidentifiering**
- _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. {andra webbplatsnamn}._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. {andra webbplatsnamn}._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)
* Active Directory DNS skapar inte dessa SRV-poster som standard. Vi rekommenderar starkt att du skapar dem om du använder NFS Kerberos.
** Active Directory DNS skapar dessa SRV-poster som standard.
Mer information om hur Azure NetApp Files använder SRV-poster finns i:
Kommentar
För korrekt identifiering och redundans för Key Distribution Center i NFS Kerberos måste URI-poster och/eller kerberos-master SRV-poster skapas.
Dynamisk DNS
Azure NetApp Files-volymer tillhandahåller en enda IP-adress för en volym, som sedan läggs till i DNS automatiskt via dynamisk DNS (DDNS) (om dynamisk DNS stöds på DNS-servern). Värdnamn (i stället för IP-adresser) används för volymmonteringssökvägar i specifika konfigurationer. Användning av värdnamn i monteringssökvägar kräver DNS för rätt funktioner:
- SMB-volymer
- NFSv4.1 Kerberos
- Volymer med dubbla protokoll
NFSv4.1 Kerberos:
SMB
Dubbla protokoll
En IP-adress används för monteringssökvägen när en Azure NetApp-filvolym inte kräver DNS, till exempel NFSv3 eller NFSv4.1 utan Kerberos.
NFSv3
Att tänka på
I Azure NetApp Files skickar dynamiska DNS-uppdateringar två olika begäranden till den konfigurerade DNS-servern: en för en PTR och en för att skapa/uppdatera en A/AAAA-post.
Azure NetApp Files-volymer som skapats med värdnamn meddelar automatiskt DNS-servern att skapa en A/AAAA-post. Detta sker omedelbart när volymen har skapats.
Om det redan finns en DNS A/AAAA-post för kombinationen IP-adress/värdnamn skapas inga nya poster.
Om en DNS A/AAAA-post finns för samma värdnamn med en annan IP-adress skapas en andra A/AAAA-post med samma namn.
För Azure NetApp Files-volymer som skapats utan värdnamn (till exempel NFSv3-volymer) skapar dynamisk DNS inte DNS-posterna eftersom inget värdnamn har tilldelats i tjänsten. Posterna måste skapas manuellt.
Om det finns en omvänd uppslagszon för gränssnittets IP-undernät skapar DNS-servern även en PTR-post. Om den nödvändiga omvända uppslagszonen inte finns kan en PTR-post inte skapas automatiskt. Du måste skapa PTR-posten manuellt.
Om en DNS-post som skapats av dynamisk DNS tas bort på DNS-servern återskapas den inom 24 timmar av en ny dynamisk DNS-uppdatering från Azure NetApp Files.
Säker DDNS aktiveras när SMB- eller dubbla protokollvolymer skapas. NFS-volymer aktiverar inte säker DDNS, men aktiverar DDNS. Om säker DDNS är inaktiverad på DNS-servern eller om Kerberos-autentiseringen misslyckas fungerar inte DDNS-uppdateringar.
Dynamisk DNS-typ Port Standard-DNS UDP 53 Säker DNS TCP 53 Azure NetApp Files stöder endast säker DDNS med Microsoft Active Directory DNS-servrar.
Information om dynamisk DNS-post
När Azure NetApp Files skapar en DNS A/AAAA-post via dynamisk DNS används följande konfigurationer:
- En associerad PTR-postruta är markerad: Om det finns omvända uppslagszoner för undernätet skapar A/AAAA-poster automatiskt PTR-poster utan administratörsintervention.
- Rutan "Ta bort den här posten när den blir inaktuell" är markerad: När DNS-posten blir "inaktuell" tar DNS bort posten, förutsatt att rensning för DNS har aktiverats.
- DNS-postens "time to live(TTL)" är inställd på en dag (24 timmar): TTL-inställningen kan ändras av DNS-administratören efter behov. TTL på en DNS-post avgör hur lång tid en DNS-post finns i en klients DNS-cache.
Kommentar
Om du vill visa tidsstämplar och TTL (Time to Live) när en DNS-post skapades i Windows Active Directory DNS går du till menyn Visa i DNS-hanteraren och väljer sedan Avancerat. Därifrån väljer du posten A/AAAA-post och visar egenskaperna.
Så här fungerar dynamisk DNS-standard i Azure NetApp Files
Azure NetApp Files följer fyra grundläggande steg för att skapa dynamiska DNS-uppdateringar till de konfigurerade DNS-servrarna. DDNS-uppdateringar (Standard Dynamic DNS) passerar UDP-port 53.
- En SOA DNS-fråga för IP-adressen för Azure NetApp Files-volymgränssnittet utförs.
- En DDNS-uppdatering för PTR utförs. Om PTR inte finns skapas den.
- En SOA-fråga (DNS start of authority) görs för det fullständigt kvalificerade domännamnet (FQDN) för Azure NetApp Files-volymen.
- En DDNS-uppdatering för A/AAAA-posten utförs. Om posten inte finns skapas den.
Dynamisk DNS via paketinsamling
Paketinsamlingar kan vara användbara vid felsökning av tjänstproblem som kanske inte har tillgänglig loggning att analysera. Expandera den här vyn för en detaljerad genomgång av paketinsamlingar.
En SOA DNS-fråga för IP-adressen för Azure NetApp Files-volymgränssnittet utförs.
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:1111En DDNS-uppdatering för PTR utförs. Om PTR inte finns skapas den.
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.localEn SOA-fråga (DNS start of authority) görs för det fullständigt kvalificerade domännamnet (FQDN) för Azure NetApp Files-volymen.
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:1111En DDNS-uppdatering för A/AAAA-posten utförs. Om posten inte finns skapas den.
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
Så här fungerar säker DDNS i Azure NetApp Files
När säker DNS är aktiverat förhandlar Azure NetApp Files med DNS-servern för att autentisera via GSS med hjälp av hemlig nyckeltransaktionsautentisering för DNS, vilket säkerställer att de begärda uppdateringarna kommer från en legitim källa. Följande visar de steg som används under den här processen. Säkra DDNS-uppdateringar passerar TCP-port 53.
- En SOA DNS-fråga för IP-adressen för Azure NetApp Files-volymgränssnittet utförs.
- En Kerberos-tjänstbiljett byts ut mot DNS-tjänsten på DNS-servern.
- Biljetten används sedan i en DNS-fråga för en transaktionsnyckel (TKEY) från Azure NetApp Files till DNS-servern, som skickas med hjälp av GSS-TSIG (transaktionssignatur) för att autentisera.
- När den har autentiserats skickas en säker dynamisk DNS-uppdatering med hjälp av TKEY för att skapa PTR med hjälp av GSS-TSIG. Om posten inte redan finns skapas den.
- En DNS SOA-fråga skickas för det fullständigt kvalificerade domännamnet (FQDN) för Azure NetApp Files-volymen och svarar på.
- Ett nytt TKEY-ID utbyts mellan DNS-servern och Azure NetApp Files.
- En säker dynamisk DNS-uppdatering skickas med hjälp av TKEY för att skapa A/AAAA-posten för FQDN. Om posten redan finns med samma IP-adress görs inga ändringar.
Dynamisk DNS via paketinsamling
Paketinsamlingar kan vara användbara vid felsökning av tjänstproblem som kanske inte har tillgänglig loggning att analysera. Expandera den här vyn för en detaljerad genomgång av paketinsamlingar.
En SOA DNS-fråga för IP-adressen för Azure NetApp Files-volymgränssnittet utförs.
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:1111En Kerberos-tjänstbiljett byts ut mot DNS-tjänsten på DNS-servern.
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-REPBiljetten används sedan i en DNS-fråga för en transaktionsnyckel (TKEY) från Azure NetApp Files till DNS-servern, som skickas med hjälp av GSS-TSIG (transaktionssignatur) för att autentisera.
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 TSIGNär den har autentiserats skickas en säker dynamisk DNS-uppdatering med hjälp av TKEY för att skapa PTR med hjälp av GSS-TSIG. Om posten inte redan finns skapas den.
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)En DNS SOA-fråga skickas för det fullständigt kvalificerade domännamnet (FQDN) för Azure NetApp Files-volymen och svarar på.
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:1111Ett nytt TKEY-ID utbyts mellan DNS-servern och Azure NetApp Files.
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 TSIGEn säker dynamisk DNS-uppdatering skickas med hjälp av TKEY för att skapa A/AAAA-posten för FQDN. Om posten redan finns med samma IP-adress görs inga ändringar.
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)
DNS-cachelagring
För att minska belastningen på DNS-servrar använder DNS-klienter cachelagringsbegrepp för att lagra tidigare frågor i minnet så att upprepade begäranden för ett värdnamn, IP eller en tjänst sparas lokalt under den tidsperiod som definieras av DNS-postens TTL.
Azure NetApp Files använder DNS-cacheminnen som alla andra standard-DNS-klienter. När tjänsten begär en DNS-post har posten en TTL definierad. Som standard har Active Directory DNS-poster en TTL på 600 sekunder (10 minuter) om inget annat anges. Om en DNS-post uppdateras och finns i Azure NetApp Files-cachen och TTL:n är 10 minuter uppdateras inte den nya posten i Azure NetApp Files förrän cacheminnet rensas efter tidsgränsvärdet. Det finns för närvarande inget sätt att rensa cacheminnet manuellt. Om du vill ha en lägre TTL gör du ändringen från DNS-servern.
När du använder externa DNS-servrar (till exempel BINDning) kan standardvärdena för timeout skilja sig åt. Om den är odefinierad är TTL för en BIND DNS-post 604 800 sekunder (sju dagar) för lång för effektiv DNS-cachelagring. När du skapar DNS-poster manuellt är det därför viktigt att manuellt ange TTL för posten till ett rimligt värde. Microsofts standardvärde på 10 minuter rekommenderas för en blandning av prestanda och tillförlitlighet för DNS-sökningar.
Du kan köra frågor mot en DNS-posts TTL manuellt med hjälp av nslookup eller dig kommandon. Exempel finns i Använda nslookup och dig för DNS-frågor.
DNS-postrensning/rensning
De flesta DNS-servrar tillhandahåller metoder för att rensa och rensa utgångna poster. Genom att rensa kan inaktuella poster inte röra DNS-servrar och skapa scenarier där dubbletter av A/AAAA- och/eller PTR-poster finns, vilket kan skapa oförutsägbara resultat för Azure NetApp Files-volymer.
Om flera PTR-poster för samma IP-adress pekar på olika värdnamn kan Kerberos-begäranden misslyckas eftersom det felaktiga SPN hämtas under DNS-sökningar. DNS urskiljer inte vilken PTR-post som tillhör vilket värdnamn; I stället utför omvända sökningar en resursallokeringssökning genom varje A/AAAA-post för varje ny sökning.
Till exempel:
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
DNS-alias och CNAME-poster (Canonical Name)
Azure NetApp Files skapar ett DNS-värdnamn för en volym som har konfigurerats för ett protokoll som kräver DNS för rätt funktioner, till exempel SMB, dubbla protokoll eller NFSv4.1 med Kerberos. Namnet som skapas använder formatet för SMB-servern (datorkontot) som ett prefix när du skapar Active Directory-anslutningen för NetApp-kontot. extra alfanumeriska tecken läggs till så att flera volymposter i samma NetApp-konto har unika namn. I de flesta fall försöker flera volymer som kräver värdnamn och finns i samma NetApp-konto att använda samma värdnamn/IP-adresser. Om SMB-servernamnet till exempel är SMB-West.contoso.com följer värdnamnsposterna formatet för SMB-West-XXXX.contoso.com.
I vissa fall kanske namnet som används av Azure NetApp Files inte är användarvänligt nog för att vidarebefordra till slutanvändare, eller så kanske administratörer vill behålla mer välbekanta DNS-namn som används när data har migrerats från lokal lagring till Azure NetApp Files (dvs. om det ursprungliga DNS-namnet datalake.contoso.com kanske slutanvändarna vill fortsätta använda det namnet).
Azure NetApp Files tillåter inte inbyggt specifikation av DNS-värdnamn som används. Om du behöver ett alternativt DNS-namn med samma funktioner bör du använda ett DNS-alias/kanoniskt namn (CNAME).
Om du använder en CNAME-post (i stället för ytterligare en A/AAAA-post) som pekar på Azure NetApp Files-volymens A/AAAA-post används samma SPN som SMB-servern för att aktivera Kerberos-åtkomst för både A/AAAA-posten och CNAME. Överväg exemplet med en A/AAAA-post med SMB-West-XXXX.contoso.com. CNAME-posten för datalake.contoso.com är konfigurerad för att peka tillbaka till A/AAAA-posten för SMB-West-XXXX.contoso.com. SMB- eller NFS Kerberos-begäranden som görs för att datalake.contoso.com använda Kerberos SPN för SMB-West-XXXX för att ge åtkomst till volymen.
Använda nslookup och gräva för DNS-frågor
DNS-servrar kan efterfrågas manuellt med hjälp av DNS-verktyg som (Windows- och Linux-klienter) och dig (Linux-klienter).nslookup Att använda dessa verktyg är användbart i scenarier som att försöka verifiera funktioner i tjänster, testa värdnamn/IP-matchning, söka efter befintliga/inaktuella DNS-poster, kontrollera serverkonfigurationen, verifiera TTL. Du kan också använda felsökaren för Azure-anslutningar för ytterligare problemlösning.
Kommandona nslookup och dig kan köras från en fjärranslutning till den virtuella datorn (till exempel från Bastion) eller direkt till den virtuella datorn via körkommandoalternativet på själva den virtuella datorn.
nslookup med Windows
Du kan köra nslookup för att samla in grundläggande IP-adressinformation utan några alternativ:
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
Om du bara vill fråga efter TTL-information för posten använder du kommandoalternativet -query=hinfo .
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)
Alternativet -debug kan också användas för att samla in mer detaljerad information om DNS-posten.
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)
gräva med 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
Metodtips för DNS i Azure NetApp Files
Se till att du uppfyller följande DNS-konfigurationskrav:
- Ange mer än en DNS-server i DNS-konfigurationen för redundans.
- Använd DNS integrerat med och/eller installerat med Active Directory för bästa resultat.
- Om du använder fristående DNS-servrar:
- Kontrollera att DNS-servrarna har nätverksanslutning till det delegerade undernätet Azure NetApp Files som är värd för Azure NetApp Files-volymerna.
- Se till att nätverksportarna UDP 53 och TCP 53 inte blockeras av brandväggar eller nätverkssäkerhetsgrupper.
- Kontrollera att de SRV-poster som registrerats av AD DS Net-inloggningstjänsten har skapats på DNS-servrarna samt tjänstposterna som anges i Typer av DNS-poster i Azure NetApp Files.
- Se till att PTR-posterna för AD DS-domänkontrollanterna som används av Azure NetApp Files har skapats på DNS-servrarna i samma domän som din Azure NetApp Files-konfiguration.
- Azure NetApp Files stöder standard- och säkra dynamiska DNS-uppdateringar. Om du behöver säkra dynamiska DNS-uppdateringar kontrollerar du att säkra uppdateringar har konfigurerats på DNS-servrarna.
- Kontrollera att en zon för omvänd sökning har skapats för Azure NetApp Files-undernätet så att dynamisk DNS kan skapa PTR-poster utöver A/AAAA-post.
- Om ett DNS-alias krävs använder du en CNAME-post. Peka CNAME-posten till A/AAAA-posterna för Azure NetApp Files.
- Om du inte använder dynamiska DNS-uppdateringar måste du manuellt skapa en A-post och en PTR-post för AD DS-datorkontona som skapats i AD DS-organisationsenheten (anges i Azure NetApp Files AD-anslutningen) för att stödja Azure NetApp Files LDAP-signering, LDAP över TLS, SMB, dubbla protokoll eller Kerberos NFSv4.1-volymer.
- För komplexa eller stora AD DS-topologier kan DNS-principer eller DNS-undernätsprioritering krävas för att stödja LDAP-aktiverade NFS-volymer.
- Om DNS-rensning är aktiverat (där inaktuella DNS-poster automatiskt rensas baserat på tidsstämpel/ålder) och dynamisk DNS användes för att skapa DNS-posterna för Azure NetApp Files-volymen, kan scavenger-processen oavsiktligt rensa posterna för volymen. Den här beskärningen kan leda till ett tjänstfel för namnbaserade frågor. Tills det här problemet har lösts skapar du DNS A/AAAA- och PTR-poster manuellt för Azure NetApp Files-volymen om DNS-rensning är aktiverat.