Förstå domännamnssystem i Azure NetApp Files

  • Artikel

DNS-tjänsten (Domain Name Systems) är en viktig komponent för dataåtkomst i Azure NetApp Files när du använder filprotokoll som förlitar sig på Kerberos för autentisering (inklusive SMB och NFSv4.1). Både ett värdnamn förenklar åtkomsten till en volym och skyddar mot scenarier när en IP-adress ändras. I stället för att informera användarna om en ny IP-adress kan de fortsätta använda värdnamnet.

Som standard använder Kerberos-autentisering namn-till-IP-adressmatchning för att formulera tjänstens huvudnamn (SPN) som används för att hämta Kerberos-biljetten. När en SMB-resurs till exempel nås med en UNC (Universal Naming Convention Path) som \SMB.CONTOSO.COM utfärdas en DNS-begäran för SMB.CONTOSO.COM och IP-adressen för Azure NetApp Files-volymen hämtas. Om det inte finns någon DNS-post (eller om den aktuella posten skiljer sig från vad som begärs, till exempel med alias/CNAMEs), kan ett korrekt SPN inte hämtas och Kerberos-begäran misslyckas. Därför kan åtkomst till volymen inte tillåtas om återställningsautentiseringsmetoden (till exempel New Technology LAN Manager) är inaktiverad.

NFSv4.1 Kerberos fungerar på ett liknande sätt för SPN-hämtning, där DNS-sökningar är integrerade i autentiseringsprocessen och kan även användas för Kerberos-sfäridentifiering.

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 AD DS eller Azure NetApp Files kan orsaka avbrott i klientåtkomsten eller tidsgränser för klienten.

IP-adresser för åtkomst med Kerberos

Om en IP-adress används i en åtkomstbegäran till en Azure NetApp Files-volym fungerar en Kerberos-begäran på olika sätt beroende på vilket protokoll som används.

SMB

När du använder SMB försöker en begäran om en UNC med hjälp av \x.x.x.x som standard använda NTLM för autentisering. I miljöer där NTLM inte tillåts av säkerhetsskäl kan en SMB-begäran som använder en IP-adress inte använda Kerberos eller NTLM för autentisering som standard. Därför nekas åtkomst till Azure NetApp Files-volymen. I senare Windows-versioner (från och med Windows 10 version 1507 och Windows Server 2016) kan Kerberos-klienter konfigureras för att stödja IPv4- och IPv6-värdnamn i SPN för SMB-kommunikation.

NFSv4.1

När du använder NFSv4.1 använder en monteringsbegäran till en IP-adress med något av sec=[krb5/krb5i/krb5p] alternativen omvänd DNS-sökningar via en pekarpost (PTR) för att matcha en IP-adress till ett värdnamn, som sedan används för att formulera SPN för biljetthämtning. Om du använder NFSv4.1 med Kerberos bör du ha en A/AAAA- och PTR för Azure NetApp Files-volymen för att täcka både värdnamn och IP-adressåtkomst till monteringar.

DNS-poster i Azure NetApp Files

Azure NetApp Files-volymer stöder dynamiska DNS-uppdateringar om DNS-servern stöder dynamisk DNS. Med dynamisk DNS meddelar volymer som skapats med värdnamn automatiskt DNS-servern att skapa en A/AAAA-post. Om det finns en omvänd uppslagszon skapar DNS även en PTR-post. Om den omvända uppslagszonen inte finns skapas inte en PTR-post automatiskt, vilket innebär att du måste skapa den manuellt.

Värdnamn (i stället för IP-adresser) används för volymmonteringssökvägar i specifika konfigurationer, som alla kräver DNS för rätt funktioner:

  • SMB-volymer
  • NFSv4.1 Kerberos
  • Volymer med dubbla protokoll

En IP-adress används när en Azure NetApp-filvolym inte kräver DNS, till exempel NFSv3 eller NFSv4.1 utan Kerberos. I sådana fall kan du manuellt skapa en DNS-post om du vill.

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.

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 för 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.

DNS-postrensning/rensning

De flesta DNS-servrar tillhandahåller metoder för att rensa/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.

Metodtips för DNS i Azure NetApp Files

Se till att du uppfyller följande krav om DNS-konfigurationerna:

  • Om du använder fristående DNS-servrar:
    • Kontrollera att DNS-servrarna har nätverksanslutning till det delegerade Undernätet i 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 NSG:er.
  • Kontrollera att de SRV-poster som registrerats av AD DS Net-inloggningstjänsten har skapats på DNS-servrarna.
  • 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.
  • 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.

Nästa steg