Delen via

Inzicht in Domain Name Systems in Azure NetApp Files

  • Artikel

Azure NetApp Files ondersteunt het gebruik van geïntegreerde DNS- of zelfstandige DNS-servers van Active Directory en vereist betrouwbare toegang tot DNS-services (Domain Name System) en up-to-date DNS-records. Slechte netwerkconnectiviteit tussen Azure NetApp Files en DNS-servers kan leiden tot onderbrekingen van clienttoegang of time-outs van clients. Onvolledige of onjuiste DNS-records voor Active Directory-domein Services (AD DS) of Azure NetApp Files kunnen leiden tot onderbrekingen van clienttoegang of time-outs van clients.

De DNS-service is een essentieel onderdeel van gegevenstoegang in Azure NetApp Files. Bestandsprotocoltoegang via SMB, NFSV4.1 Kerberos, LDAP en Active Directory-sitedetectie maken allemaal aanzienlijk gebruik van DNS voor hun bewerkingen. Het gebruik van een hostnaam centraal in DNS vereenvoudigt de toegang tot een volume en beschermt tegen scenario's wanneer een IP-adres wordt gewijzigd. In plaats van een beheerder die gebruikers moet informeren over een nieuw IP-adres, kunnen gebruikers de gebruiksvriendelijke hostnaam blijven gebruiken.

DNS-servers worden geconfigureerd onder Active Directory-verbindingen. Er kan een primaire en secundaire server worden toegevoegd, evenals de DNS-naam van Active Directory.

Notitie

Configureer als best practice meer dan één DNS-server voor redundantie.

Schermopname van DNS-instellingen.

Over DNS-servers

Azure NetApp Files vereist een Active Directory-verbinding voor SMB- en NFSv4.1 Kerberos-functionaliteit. Active Directory vereist DNS voor de juiste functionaliteit. In de meeste gevallen worden Active Directory-implementaties geïnstalleerd met DNS-servers die zijn geïntegreerd met de domeincontrollers. Deze configuratie is een best practice van Microsoft voor zowel gebruiksgemak als om ervoor te zorgen dat alle vereiste DNS-records worden gemaakt voor domeinservices.

Diagram van AD DNS-configuratie.

In sommige gevallen kunnen externe DNS-servers (zoals BIND) worden gebruikt in plaats van (of naast) door Active Directory gehoste DNS-services. Dit wordt een niet-aaneengesloten naamruimte genoemd.

Diagram van externe bindingsconfiguratie.

Azure NetApp Files ondersteunt het gebruik van zowel geïntegreerde als externe DNS-servers, maar wanneer u externe DNS-servers gebruikt zonder Active Directory-integratie, is het belangrijk om ervoor te zorgen dat de benodigde servicerecords (SRV) worden toegevoegd aan DNS voor de juiste functionaliteit en redundantie van services. Slechte netwerkconnectiviteit tussen Azure NetApp Files en DNS-servers kan leiden tot onderbrekingen van clienttoegang of time-outs van clients. Onvolledige of onjuiste DNS-records voor AD DS of Azure NetApp Files kunnen leiden tot onderbrekingen van clienttoegang of time-outs van clients.

Zie DNS-records in Azure NetApp Files voor een lijst met SRV-records die door de service worden gebruikt. Bekijk ook de richtlijnen voor DNS met Active Directory en integratie van AD DS in een bestaande DNS-infrastructuur.

Azure DNS-integratie met Azure NetApp Files

Azure DNS is een gehoste SERVICE voor DNS-beheer en naamomzetting in Microsoft Azure. U kunt deze gebruiken om openbare of persoonlijke DNS-namen te maken voor andere toepassingen en services die u in Azure implementeert, inclusief Azure NetApp Files. Het implementeren van DNS in Azure voorkomt dat DNS-aanvragen (via poort 53) rechtstreeks tussen Azure NetApp Files en on-premises DNS en/of een Active Directory-domein moeten worden verzonden. Daarnaast kan Azure DNS worden gebruikt voor het maken van voorwaardelijke doorstuurservers (met behulp van de Azure Privé-DNS resolver) die kunnen worden gebruikt voor het verzenden van DNS-aanvragen van Azure NetApp Files naar specifieke DNS-servers via de privé-DNS-servers die worden gehost in Azure, die kunnen worden opgegeven voor gebruik in de Active Directory-verbinding.

Diagram van Azure DNS-configuratie.

Voor informatie over het gebruik van Azure DNS:

IP-adressen van load balancer gebruiken met DNS in Azure NetApp Files

Een load balancer-apparaat is een manier om één IP-adres te gebruiken voor het verwerken van meerdere IP-adressen op de back-end. Dit biedt beveiliging via verdoofing, evenals prestatie- en redundantievoordelen voor bedrijfsomgevingen.

Diagram van een load balancer-configuratie.

Een DNS-load balancer kan aanvragen verwerken en verzenden naar meerdere DNS-servers die zijn aangewezen in een pool. Microsoft Azure biedt systeemeigen taakverdelingsservices voor meerdere gebruiksvoorbeelden.

Azure NetApp Files ondersteunt het gebruik van DNS-load balancers, mits ze een IP-adres als eindpunt leveren en dat IP-adres kan communiceren via poort 53 naar de Azure NetApp Files-netwerken. Azure Traffic Manager biedt bijvoorbeeld DNS-taakverdeling op laag 7, maar biedt alleen een front-endhostnaam voor gebruik. Azure NetApp Files Active Directory-verbindingen staan alleen toe dat IP-adressen worden opgegeven voor DNS-servers.

Typen DNS-records in Azure NetApp Files

Azure NetApp Files maakt gebruik van verschillende typen DNS-records voor toegang tot bestandsservices.

DNS-recordtype Definitie
A/AAAA DNS A-records zijn adresrecords die het IPv4-adres voor een hostnaam aangeven. AAAA-records geven het IPv6-adres voor een hostnaam aan. Azure NetApp Files maakt op de volgende manieren gebruik van A/AAAA-records :
  • IP-adressen maskeren achter gebruiksvriendelijke hostnamen
  • Kerberos-service-principalaanvragen
  • Hoofddomeinquery's
Aanwijzerrecords (PTR) Een PTR-record wijst een IP-adres toe aan een hostnaam via een zone voor reverse lookup. PTR-records worden voornamelijk gebruikt wanneer een IP-adres wordt opgegeven voor een koppeling/share in Azure NetApp Files. Het gebruik van een IP-adres in koppel-/shareaanvragen kan van invloed zijn op de gebruikte verificatiemethode. Zie IP-adressen voor toegang met Kerberos voor meer informatie.
Servicerecords (SRV) SRV-records worden gebruikt om op te geven welke hosts en poorten worden gebruikt voor een specifieke service, zoals LDAP, NFS, CIFS, Kerberos, enzovoort. SRV-records in Azure NetApp Files worden sterk gebruikt voor bestandsservicebeveiliging (zoals Kerberos), sitedetectie in Active Directory, LDAP-serverquery's en meer. Het is belangrijk om te controleren of deze records bestaan voor de juiste functionaliteit van Azure NetApp Files-services.

SRV-records kunnen worden opgevraagd met behulp van nslookup of dig opdrachten. Zie Het gebruik en nslookupdig voor DNS-query's voor voorbeelden.
Canonieke namen (CNAME) Een CNAME-record is een manier om DNS-aliassen te bieden voor A/AAAA-records. CNAME-records zijn optioneel, maar kunnen nuttig zijn om de complexiteit van de hostnaamrecords van Azure NetApp Files te verminderen. Zie DNS-aliassen en Canonical Name-records voor meer informatie.
Uniform Resource Identifier (URI) Een URI-record is een manier om hostnamen/IP-adressen voor services toe te wijzen aan URI's. URI's worden als volgt weergegeven: service://fqdn.contoso.com.

Azure NetApp Files maakt alleen gebruik van query's voor URI-records bij het uitvoeren van Kerberos KDC-zoekacties voor NFS Kerberos-aanvragen. URI-records worden niet standaard gemaakt in DNS-implementaties van Active Directory. Als zodanig mislukken URI-opzoekaanvragen meestal en vallen ze terug op SRV-recordzoekacties.

Servicerecords (SRV) die worden gebruikt met Azure NetApp Files

Azure NetApp Files maakt gebruik van de volgende SRV-records:

  • NFS Kerberos*
    • _kerberos-master._tcp. CONTOSO.COM (poort 88)*
    • _kerberos-master._tcp. CONTOSO.COM (poort 88)*
  • SMB/Active Directory-sitedetectie**
    • _kerberos.CONTOSO.COM (poort 88)
    • _kerberos._tcp. CONTOSO.COM (poort 88)
    • _kerberos._tcp.dc_msdcs. CONTOSO.COM (poort 88)
    • _kpasswd._tcp.dc._msdcs. CONTOSO.COM (poort 464)
    • _kpasswd._tcp. CONTOSO.COM (poort 464)
    • _kerberos._tcp. Default-First-Site-Name._sites.dc._msdcs. CONTOSO.COM (poort 88)
    • _kerberos._tcp. {andere sitenamen}._sites.dc._msdcs. CONTOSO.COM (poort 88)
    • _kerberos.udp.CONTOSO.COM (poort 88)
    • _kerberos._udp.dc_msdcs. CONTOSO.COM (poort 88)
    • _kpasswd._udp.dc._msdcs. CONTOSO.COM (poort 464)
    • _kpasswd._udp. CONTOSO.COM (poort 464)
    • _kerberos._udp. Default-First-Site-Name._sites.dc._msdcs. CONTOSO.COM (poort 88)
    • _kerberos._udp. {andere sitenamen}._sites.dc._msdcs. CONTOSO.COM (poort 88)
  • LDAP**
    • _ldap.CONTOSO.COM (poort 389)
    • _ldap._tcp. CONTOSO.COM (poort 389)
    • _ldap._udp. CONTOSO.COM (poort 389)

* Active Directory DNS maakt deze SRV-records niet standaard. Het wordt ten zeerste aanbevolen om ze te maken als u NFS Kerberos gebruikt.

** Active Directory DNS maakt deze SRV-records standaard.

Zie voor meer informatie over hoe Azure NetApp Files gebruikmaakt van SRV-records:

Notitie

Voor de juiste detectie en redundantie van het Key Distribution Center in NFS Kerberos moeten URI-records en/of kerberos-master SRV-records worden gemaakt.

Dynamische DNS

Azure NetApp Files-volumes bieden één IP-adres voor een volume, dat vervolgens automatisch wordt toegevoegd aan DNS via dynamische DNS (DDNS) (als dynamische DNS wordt ondersteund op de DNS-server). Hostnamen (in plaats van IP-adressen) worden gebruikt voor paden voor volumekoppeling in specifieke configuraties. Voor het gebruik van hostnamen in koppelpaden is DNS vereist voor de juiste functionaliteit:

  • SMB-volumes
  • NFSv4.1 Kerberos
  • Volumes met dubbele protocollen

NFSv4.1 Kerberos:

Schermopname van het koppelpad NFSv4.1.

SMB

Schermopname van het koppelpad van SMB.

Dual-protocol

Schermopname van koppelingspad met twee protocollen.

Er wordt een IP-adres gebruikt voor het koppelpad wanneer voor een Azure NetApp File-volume geen DNS is vereist, zoals NFSv3 of NFSv4.1 zonder Kerberos.

NFSv3

Schermopname van het koppelpad van NFS3.

Overwegingen

In Azure NetApp Files verzenden dynamische DNS-updates twee verschillende aanvragen naar de geconfigureerde DNS-server: één voor een PTR en één voor het maken/bijwerken van een A/AAAA-record.

  • Azure NetApp Files-volumes die zijn gemaakt met hostnamen, stellen de DNS-server automatisch op de hoogte om een A/AAAA-record te maken. Dit gebeurt onmiddellijk nadat het volume is gemaakt.

  • Als er al een DNS A/AAAA-record aanwezig is voor de combinatie van IP-adres/hostnaam, worden er geen nieuwe records gemaakt.

  • Als er een DNS A/AAAA-record aanwezig is voor dezelfde hostnaam met een ander IP-adres, wordt er een tweede A/AAAA-record met dezelfde naam gemaakt.

  • Voor Azure NetApp Files-volumes die zijn gemaakt zonder hostnamen (zoals NFSv3-volumes), worden de DNS-records niet gemaakt omdat er geen hostnaam is toegewezen in de service. De records moeten handmatig worden gemaakt.

  • Als er een zone voor reverse lookup voor het IP-subnet van de interface bestaat, maakt de DNS-server ook een PTR-record. Als de benodigde zone voor reverse lookup niet bestaat, kan er geen PTR-record automatisch worden gemaakt. U moet de PTR-record handmatig maken.

  • Als een DNS-vermelding die is gemaakt door dynamische DNS wordt verwijderd op de DNS-server, wordt deze binnen 24 uur opnieuw gemaakt door een nieuwe dynamische DNS-update van Azure NetApp Files.

  • Beveiligde DDNS wordt ingeschakeld wanneer SMB- of dubbele protocolvolumes worden gemaakt. NFS-volumes schakelen geen beveiligde DDNS in, maar wel DDNS. Als beveiligde DDNS is uitgeschakeld op de DNS-server of de Kerberos-verificatie mislukt, werken DDNS-updates niet.

    Dynamisch DNS-type Poort
    Standaard-DNS UDP 53
    Dns beveiligen TCP 53

  • Azure NetApp Files ondersteunt alleen beveiligde DDNS met DNS-servers van Microsoft Active Directory.

Details van dynamische DNS-vermelding

Wanneer Azure NetApp Files een DNS A/AAAA-record maakt via dynamische DNS, worden de volgende configuraties gebruikt:

  • Er is een gekoppeld PTR-recordvak ingeschakeld: Als zones voor reverse lookup voor het subnet bestaan, maken A/AAAA-records automatisch PTR-records zonder tussenkomst van de beheerder.
  • Het selectievakje Deze record verwijderen wanneer deze verouderd wordt ingeschakeld: Wanneer de DNS-record 'verouderd' wordt, wordt de record verwijderd, mits opruiming voor DNS is ingeschakeld.
  • De TTL (Time to Live) van de DNS-record is ingesteld op één dag (24 uur): de TTL-instelling kan indien nodig worden gewijzigd door de DNS-beheerder. De TTL op een DNS-record bepaalt hoe lang een DNS-vermelding bestaat in de DNS-cache van een client.

Notitie

Als u tijdstempels en de TTL (Time to Live) wilt weergeven wanneer een DNS-record is gemaakt in Windows Active Directory DNS, gaat u naar het menu Beeld van DNS-beheer en selecteert u Geavanceerd. Selecteer hier de A/AAAA-recordvermelding en bekijk de eigenschappen.

Schermopname van DNS-tijdstempels.

Hoe standaard dynamische DNS werkt in Azure NetApp Files

Azure NetApp Files volgt vier basisstappen voor het maken van dynamische DNS-updates voor de geconfigureerde DNS-servers. DDNS-updates (Standard dynamic DNS) gaan via UDP-poort 53.

  • Er wordt een SOA DNS-query uitgevoerd voor het IP-adres van de Azure NetApp Files-volumeinterface.
  • Er wordt een DDNS-update voor de PTR uitgevoerd. Als de PTR niet bestaat, wordt deze gemaakt.
  • Er wordt een DNS-beginquery (SOA) uitgevoerd voor de FQDN (Fully Qualified Domain Name) van het Azure NetApp Files-volume.
  • Er wordt een DDNS-update voor de A/AAAA-record uitgevoerd. Als de record niet bestaat, wordt deze gemaakt.

Dynamische DNS via pakketopname

Pakketopnamen kunnen handig zijn bij het oplossen van serviceproblemen waarvoor mogelijk geen logboekregistratie beschikbaar is om te analyseren. Vouw deze weergave uit voor een gedetailleerd overzicht van pakketopnamen.

  1. Er wordt een SOA DNS-query uitgevoerd voor het IP-adres van de Azure NetApp Files-volumeinterface.

    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

  2. Er wordt een DDNS-update voor de PTR uitgevoerd. Als de PTR niet bestaat, wordt deze gemaakt.

    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

  3. Er wordt een DNS-beginquery (SOA) uitgevoerd voor de FQDN (Fully Qualified Domain Name) van het Azure NetApp Files-volume.

    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

  4. Er wordt een DDNS-update voor de A/AAAA-record uitgevoerd. Als de record niet bestaat, wordt deze gemaakt.

    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

Hoe beveiligde DDNS werkt in Azure NetApp Files

Wanneer beveiligde DNS is ingeschakeld, onderhandelt Azure NetApp Files met de DNS-server om te verifiëren via GSS met behulp van Verificatie van geheime sleuteltransacties voor DNS, ervoor te zorgen dat de aangevraagde updates afkomstig zijn van een legitieme bron. Hieronder ziet u de stappen die tijdens dit proces worden gebruikt. Beveiligde DDNS-updates gaan via TCP-poort 53.

  • Er wordt een SOA DNS-query uitgevoerd voor het IP-adres van de Azure NetApp Files-volumeinterface.
  • Er wordt een Kerberos-serviceticket uitgewisseld voor de DNS-service op de DNS-server.
  • Het ticket wordt vervolgens gebruikt in een DNS-query voor een transactiesleutel (TKEY) van Azure NetApp Files naar de DNS-server, die wordt doorgegeven met behulp van GSS-TSIG (transactiehandtekening) om te verifiëren.
  • Zodra de verificatie is geslaagd, wordt een beveiligde dynamische DNS-update verzonden met behulp van de TKEY om de PTR te maken met behulp van GSS-TSIG. Als de record nog niet bestaat, wordt deze gemaakt.
  • Er wordt een DNS SOA-query verzonden voor de FQDN (Fully Qualified Domain Name) van het Azure NetApp Files-volume en gereageerd op.
  • Er wordt een nieuwe TKEY-id uitgewisseld tussen de DNS-server en Azure NetApp Files.
  • Er wordt een beveiligde dynamische DNS-update verzonden met behulp van de TKEY om de A/AAAA-record voor de FQDN te maken. Als de record al bestaat met hetzelfde IP-adres, worden er geen wijzigingen aangebracht.

Dynamische DNS via pakketopname

Pakketopnamen kunnen handig zijn bij het oplossen van serviceproblemen waarvoor mogelijk geen logboekregistratie beschikbaar is om te analyseren. Vouw deze weergave uit voor een gedetailleerd overzicht van pakketopnamen.

  1. Er wordt een SOA DNS-query uitgevoerd voor het IP-adres van de Azure NetApp Files-volumeinterface.

    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

  2. Er wordt een Kerberos-serviceticket uitgewisseld voor de DNS-service op de DNS-server.

    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

  3. Het ticket wordt vervolgens gebruikt in een DNS-query voor een transactiesleutel (TKEY) van Azure NetApp Files naar de DNS-server, die wordt doorgegeven met behulp van GSS-TSIG (transactiehandtekening) om te verifiëren.

        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

  4. Zodra de verificatie is geslaagd, wordt een beveiligde dynamische DNS-update verzonden met behulp van de TKEY om de PTR te maken met behulp van GSS-TSIG. Als de record nog niet bestaat, wordt deze gemaakt.

    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)

  5. Er wordt een DNS SOA-query verzonden voor de FQDN (Fully Qualified Domain Name) van het Azure NetApp Files-volume en gereageerd op.

    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

  6. Er wordt een nieuwe TKEY-id uitgewisseld tussen de DNS-server en 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 TSIG

  7. Er wordt een beveiligde dynamische DNS-update verzonden met behulp van de TKEY om de A/AAAA-record voor de FQDN te maken. Als de record al bestaat met hetzelfde IP-adres, worden er geen wijzigingen aangebracht.

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

Om de belasting op DNS-servers te verminderen, maken DNS-clients gebruik van cacheconcepten voor het opslaan van eerdere query's in het geheugen, zodat herhalende aanvragen voor een hostnaam, IP of service lokaal worden bewaard gedurende de periode die is gedefinieerd door de TTL van de DNS-record.

Azure NetApp Files maakt gebruik van DNS-caches zoals elke andere standaard-DNS-client. Wanneer de service een DNS-record aanvraagt, heeft die record een TTL gedefinieerd. Dns-vermeldingen van Active Directory hebben standaard een TTL van 600 seconden (10 minuten) tenzij anders is opgegeven. Als een DNS-record wordt bijgewerkt en zich in de Cache van Azure NetApp Files bevindt en de TTL 10 minuten is, wordt de nieuwe record pas bijgewerkt in Azure NetApp Files nadat de cache is leeggemaakt na de time-outwaarde. Er is momenteel geen manier om deze cache handmatig te verwijderen. Als u een lagere TTL wilt gebruiken, moet u de wijziging van de DNS-server aanbrengen.

Wanneer u externe DNS-servers (zoals BIND) gebruikt, kunnen de standaardtime-outwaarden verschillen. Als dit niet is gedefinieerd, is de TTL van een BIND DNS-record 604.800 seconden (zeven dagen), te lang voor effectieve DNS-caching. Als zodanig is het bij het handmatig maken van DNS-records belangrijk om de TTL voor de record handmatig in te stellen op een redelijke waarde. Het gebruik van de Microsoft-standaardwaarde van 10 minuten wordt aanbevolen voor een combinatie van prestaties en betrouwbaarheid voor DNS-zoekacties.

U kunt handmatig een query uitvoeren op de TTL van een DNS-record met behulp van nslookup of dig opdrachten. Zie Het gebruik en nslookupdig voor DNS-query's voor voorbeelden.

DNS-record snoeien/opruimen

De meeste DNS-servers bieden methoden om verlopen records te verwijderen en op te zoeken. Door te snoeien voorkomt u dat verouderde records onbelangrijke DNS-servers onoverzichtelijk maken en scenario's worden gemaakt waarin dubbele A/AAAA- en/of PTR-records bestaan, wat onvoorspelbare resultaten kan opleveren voor Azure NetApp Files-volumes.

Als meerdere PTR-records voor hetzelfde IP-adrespunt naar verschillende hostnamen verwijzen, kunnen Kerberos-aanvragen mislukken omdat de onjuiste SPN wordt opgehaald tijdens DNS-zoekopdrachten. DNS merkt niet bij welke PTR-record bij welke hostnaam hoort; In plaats daarvan voeren reverse lookups een round robin-zoekopdracht uit op elke A/AAAA-record voor elke nieuwe lookup.

Bijvoorbeeld:

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-aliassen en CNAME-records (Canonical Name)

Azure NetApp Files maakt een DNS-hostnaam voor een volume dat is geconfigureerd voor een protocol waarvoor DNS is vereist voor de juiste functionaliteit, zoals SMB, dual protocol of NFSv4.1 met Kerberos. De naam die is gemaakt, gebruikt de indeling van de SMB-server (computeraccount) als voorvoegsel bij het maken van de Active Directory-verbinding voor het NetApp-account; extra alfanumerieke tekens worden toegevoegd, zodat meerdere volumevermeldingen in hetzelfde NetApp-account unieke namen hebben. In de meeste gevallen proberen meerdere volumes die hostnamen vereisen en die zich in hetzelfde NetApp-account bevinden, dezelfde hostnamen/IP-adressen te gebruiken. Als de SMB-servernaam bijvoorbeeld SMB-West.contoso.com is, volgen hostnaamvermeldingen de indeling van SMB-West-XXXX.contoso.com.

In sommige gevallen is de naam die wordt gebruikt door Azure NetApp Files mogelijk niet gebruiksvriendelijk genoeg om door te geven aan eindgebruikers, of willen beheerders mogelijk meer vertrouwde DNS-namen behouden die worden gebruikt wanneer gegevens zijn gemigreerd van on-premises opslag naar Azure NetApp Files (bijvoorbeeld als de oorspronkelijke DNS-naam is datalake.contoso.com, kunnen eindgebruikers die naam blijven gebruiken).

Azure NetApp Files staat niet standaard de specificatie van gebruikte DNS-hostnamen toe. Als u een alternatieve DNS-naam met dezelfde functionaliteit nodig hebt, moet u een DNS-alias/canonieke naam (CNAME) gebruiken.

Het gebruik van een CNAME-record (in plaats van een extra A/AAAA-record) die verwijst naar de A/AAAA-record van het Azure NetApp Files-volume maakt gebruik van dezelfde SPN als de SMB-server om Kerberos-toegang in te schakelen voor zowel de A/AAAA-record als CNAME. Bekijk het voorbeeld van een A/AAAA-record van SMB-West-XXXX.contoso.com. De CNAME-record van datalake.contoso.com is geconfigureerd om terug te verwijzen naar A/AAAA-record van SMB-West-XXXX.contoso.com. SMB- of NFS Kerberos-aanvragen voor datalake.contoso.com de Kerberos SPN voor SMB-West-XXXX gebruiken om toegang te bieden tot het volume.

nslookup gebruiken en zoeken voor DNS-query's

DNS-servers kunnen handmatig worden opgevraagd met behulp van DNS-hulpprogramma's zoals nslookup (Windows- en Linux-clients) en dig (Linux-clients). Het gebruik van deze hulpprogramma's is handig in scenario's, waaronder het controleren van de functionaliteit van services, het testen van hostnaam/IP-resolutie, het zoeken naar bestaande/verlopen DNS-records, het controleren van de serverconfiguratie, het verifiëren van TTL. U kunt ook de probleemoplosser voor Azure-verbindingen gebruiken voor aanvullende probleemoplossing.

De nslookup en dig opdrachten kunnen worden uitgevoerd vanaf een externe verbinding met de VIRTUELE machine (zoals vanuit Bastion) of rechtstreeks naar de VIRTUELE machine via de opdrachtoptie uitvoeren op de VIRTUELE machine zelf.

nslookup met Windows

U kunt uitvoeren nslookup om basis-IP-adresgegevens te verzamelen zonder opties:

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

Als u alleen TTL-gegevens voor de record wilt opvragen, gebruikt u de -query=hinfo opdrachtoptie.

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)

De -debug optie kan ook worden gebruikt om meer gedetailleerde informatie over de DNS-record te verzamelen.

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)

Graven met 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

DNS best practices in Azure NetApp Files

Zorg ervoor dat u voldoet aan de volgende DNS-configuratievereisten:

  • Geef meer dan één DNS-server op in de DNS-configuratie voor redundantie.
  • Gebruik DNS geïntegreerd met en/of geïnstalleerd met Active Directory voor de beste resultaten.
  • Als u zelfstandige DNS-servers gebruikt:
    • Zorg ervoor dat de DNS-servers netwerkconnectiviteit hebben met het gedelegeerde subnet van Azure NetApp Files dat als host fungeert voor de Azure NetApp Files-volumes.
    • Zorg ervoor dat de netwerkpoorten UDP 53 en TCP 53 niet worden geblokkeerd door firewalls of netwerkbeveiligingsgroepen.
  • Zorg ervoor dat de SRV-records die zijn geregistreerd door de AD DS Net-aanmeldingsservice zijn gemaakt op de DNS-servers, evenals de servicerecords die worden vermeld in typen DNS-records in Azure NetApp Files.
  • Zorg ervoor dat de PTR-records voor de AD DS-domeincontrollers die door Azure NetApp Files worden gebruikt, zijn gemaakt op de DNS-servers in hetzelfde domein als uw Azure NetApp Files-configuratie.
  • Azure NetApp Files ondersteunt standaard en beveiligde dynamische DNS-updates. Als u beveiligde dynamische DNS-updates nodig hebt, moet u ervoor zorgen dat beveiligde updates zijn geconfigureerd op de DNS-servers.
  • Zorg ervoor dat er een zone voor reverse lookup is gemaakt voor het Azure NetApp Files-subnet, zodat dynamische DNS PTR-records kan maken naast een A/AAAA-record.
  • Als een DNS-alias is vereist, gebruikt u een CNAME-record. Wijs de CNAME-record naar de A/AAAA-records voor Azure NetApp Files.
  • Als u geen dynamische DNS-updates gebruikt, moet u handmatig een A-record en een PTR-record maken voor de AD DS-computeraccounts die zijn gemaakt in de AD DS-organisatie-eenheid (opgegeven in de Azure NetApp Files AD-verbinding) ter ondersteuning van Azure NetApp Files LDAP-ondertekening, LDAP via TLS, SMB, dual-protocol of Kerberos NFSv4.1-volumes.
  • Voor complexe of grote AD DS-topologieën zijn DNS-beleidsregels of DNS-subnet prioritering mogelijk vereist ter ondersteuning van NFS-volumes waarvoor LDAP is ingeschakeld.
  • Als DNS-opruiming is ingeschakeld (waarbij verouderde DNS-vermeldingen automatisch worden verwijderd op basis van tijdstempel/leeftijd) en dynamische DNS is gebruikt om de DNS-records voor het Azure NetApp Files-volume te maken, kan het scavenger-proces de records voor het volume per ongeluk verwijderen. Deze verwijdering kan leiden tot een servicestoring voor op naam gebaseerde query's. Totdat dit probleem is opgelost, maakt u handmatig DNS A/AAAA- en PTR-vermeldingen voor het Azure NetApp Files-volume als DNS-opruiming is ingeschakeld.

Volgende stappen