Descripción de los sistemas de nombres de dominio en Azure NetApp Files
Azure NetApp Files admite el uso de servidores DNS integrados o DNS independientes de Active Directory y requiere acceso confiable a los servicios del Sistema de nombres de dominio (DNS) y los registros DNS actualizados. Una conectividad de red deficiente entre Azure NetApp Files y los servidores DNS puede provocar interrupciones de acceso de cliente o tiempos de espera de cliente. Los registros DNS incompletos o incorrectos para el Dominio de Active Directory Services (AD DS) o Azure NetApp Files pueden provocar interrupciones de acceso de cliente o tiempos de espera de cliente.
El servicio DNS es un componente crítico del acceso a datos en Azure NetApp Files. El acceso al protocolo de archivos a través de SMB, NFSV4.1 Kerberos, LDAP y detección de sitios de Active Directory hacen un uso significativo de DNS para sus operaciones. El uso de un nombre de host ubicado centralmente en DNS simplifica el acceso a un volumen y protege frente a escenarios en los que cambia una dirección IP. En lugar de que un administrador necesite informar a los usuarios de una nueva dirección IP, los usuarios pueden seguir usando el nombre de host descriptivo.
Los servidores DNS se configuran en conexiones de Active Directory. Se puede agregar un servidor principal y secundario, así como el nombre DNS de Active Directory.
Nota:
Como procedimiento recomendado, configure más de un servidor DNS para la redundancia.
Acerca de los servidores DNS
Azure NetApp Files requiere una conexión de Active Directory para la funcionalidad SMB y NFSv4.1 Kerberos. Active Directory requiere DNS para una funcionalidad adecuada. En la mayoría de los casos, las implementaciones de Active Directory se instalan con servidores DNS integrados con los controladores de dominio. Esta configuración es una Procedimiento recomendado de Microsoft tanto para facilitar el uso como para garantizar que se creen todos los registros DNS necesarios para los servicios de dominio.
En algunos casos, los servidores DNS externos (como BIND) se pueden usar en lugar de los servicios DNS hospedados de Active Directory (o además). Esto se denomina espacio de nombres separado.
Azure NetApp Files admite el uso de servidores DNS integrados y externos, pero cuando se usan servidores DNS externos sin integración de Active Directory, es importante asegurarse de que los registros de servicio (SRV) necesarios se agreguen a DNS para una funcionalidad adecuada y redundancia de los servicios. Una conectividad de red deficiente entre Azure NetApp Files y los servidores DNS puede provocar interrupciones de acceso de cliente o tiempos de espera de cliente. Los registros DNS incompletos o incorrectos para AD DS o Azure NetApp Files pueden provocar interrupciones del acceso al cliente o tiempos de espera de cliente.
Consulte Registros DNS en Azure NetApp Files para obtener una lista de registros SRV que usa el servicio. Revise también las Directrices para DNS con Active Directory e Integración de AD DS en una infraestructura DNS existente.
Integración de Azure DNS con Azure NetApp Files
Azure DNS es un servicio hospedado de administración de DNS y resolución de nombres en Microsoft Azure. Puede usarlo para crear nombres DNS públicos o privados para otras aplicaciones y servicios que implemente en Azure, incluido Azure NetApp Files. La implementación de DNS en Azure impide la necesidad de enviar solicitudes DNS (a través del puerto 53) directamente entre Azure NetApp Files y DNS local o un dominio de Active Directory. Además, Azure DNS se puede usar para crear reenviadores condicionales (mediante la resolución DNS privado de Azure) que se puede usar para enviar solicitudes DNS desde Azure NetApp Files a servidores DNS específicos mediante los servidores DNS privados hospedados en Azure, que se pueden especificar para su uso en la conexión de Active Directory.
Para obtener información sobre el uso de Azure DNS:
- Funcionamiento de Azure DNS con otros servicios de Azure
- Inicio rápido: Creación de una zona y un registro de Azure DNS mediante Azure Portal
- Inicio rápido: Creación de una zona DNS privada de Azure con Azure Portal
- Inicio rápido: Creación de una instancia de Azure DNS Private Resolver desde Azure Portal
Uso de direcciones IP del equilibrador de carga con DNS en Azure NetApp Files
Un dispositivo de equilibrador de carga es una manera de usar una sola dirección IP para atender varias direcciones IP en el back-end. Esto proporciona seguridad a través de ofuscación, así como ventajas de rendimiento y redundancia para entornos empresariales.
Un equilibrador de carga DNS puede atender las solicitudes y enviarlos a varios servidores DNS designados en un grupo. Microsoft Azure proporciona servicios nativos de equilibrio de carga para varios casos de uso.
Azure NetApp Files admite el uso de equilibradores de carga DNS, siempre que proporcionen una dirección IP como punto de conexión y esa dirección IP pueda comunicarse a través del puerto 53 a las redes de Azure NetApp Files. Por ejemplo, Azure Traffic Manager proporciona equilibrio de carga de DNS en la capa 7, pero solo proporciona un nombre de host de front-end para su uso. Las conexiones de Active Directory de Azure NetApp Files solo permiten especificar direcciones IP para los servidores DNS.
Tipos de registros DNS en Azure NetApp Files
Azure NetApp Files usa diferentes tipos de registros DNS para el acceso a los servicios de archivos.
| Tipo de registros DNS | Definición |
|---|---|
| A/AAAA | DNS Registros A son registros de direcciones que indican la dirección IPv4 de un nombre de host. Los registros AAAA indican la dirección IPv6 de un nombre de host. Azure NetApp Files usa Registros A/AAAA de las siguientes maneras:
|
| Registros de puntero (PTR) | Un Registro PTR asigna una dirección IP a un nombre de host mediante una zona de búsqueda inversa. Los registros PTR se usan principalmente cuando se especifica una dirección IP para un montaje o recurso compartido en Azure NetApp Files. El uso de una dirección IP en las solicitudes de montaje o recurso compartido puede afectar al método de autenticación usado. Para obtener más información, consulte Direcciones IP para el acceso con Kerberos. |
| Registros de servicio (SRV) |
Los registros SRV se usan para especificar qué hosts y puertos se usan para un servicio específico, como LDAP, NFS, CIFS, Kerberos, etc. Los registros SRV de Azure NetApp Files se usan en gran medida para la seguridad del servicio de archivos (como Kerberos), la detección de sitios en Active Directory, las consultas del servidor LDAP y mucho más. Es importante comprobar la existencia de estos registros para obtener una funcionalidad adecuada de los servicios de Azure NetApp Files. los registros SRV se pueden consultar mediante comandos nslookup o dig . Para obtener ejemplos, consulte Uso nslookup y dig para consultas DNS. |
| Nombres canónicos (CNAME) | Un registro CNAME es una manera de proporcionar alias DNS para registros A/AAAA. Los registros CNAME son opcionales, pero pueden ser útiles para reducir la complejidad de los registros de nombre de host proporcionados por Azure NetApp Files. Para obtener más información, consulte Alias DNS y registros de nombres canónicos. |
| Identificador de recursos uniforme (URI) | Un Registro de URI es una manera de asignar nombres de host o direcciones IP para los servicios a los URI. Los URI se presentan en un formato como: service://fqdn.contoso.com. Azure NetApp Files usa consultas para registros URI solo cuando realiza búsquedas Kerberos KDC para solicitudes NFS Kerberos. Los registros de URI no se crean en implementaciones de DNS de Active Directory de manera predeterminada. Por lo tanto, las solicitudes de búsqueda de URI suelen producir errores y revertir a búsquedas de registros SRV. |
Registros de servicio (SRV) usados con Azure NetApp Files
Azure NetApp Files usa los siguientes registros SRV:
-
NFS Kerberos*
- _kerberos-master._tcp.CONTOSO.COM (port 88)*
- _kerberos-master._tcp.CONTOSO.COM (port 88)*
-
Detección de sitios de 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. {otros nombres de sitio}._sites.dc._msdcs. CONTOSO.COM (puerto 88)
-
LDAP**
- _ldap.CONTOSO.COM (port 389)
- _ldap._tcp.CONTOSO.COM (port 389)
- _ldap._udp.CONTOSO.COM (port 389)
* DNS de Active Directory no crea estos registros SRV de manera predeterminada. Se recomienda encarecidamente crearlos si se usa Kerberos NFS.
** DNS de Active Directory crea estos registros SRV de manera predeterminada.
Para más información sobre cómo Azure NetApp Files usa registros SRV, consulte:
Nota:
Para la detección y redundancia adecuadas del Centro de distribución de claves en Kerberos NFS, se deben crear registros de URI o registros SRV kerberos-master.
DNS dinámico
Los volúmenes de Azure NetApp Files proporcionan una única dirección IP para un volumen, que se agrega a DNS automáticamente a través de DNS dinámico (DDNS) (si se admite DNS dinámico en el servidor DNS). Los nombres de host (en lugar de direcciones IP) se usan para rutas de montaje de volumen en configuraciones específicas. El uso de nombres de host en rutas de montaje requiere DNS para una funcionalidad adecuada:
- Volúmenes SMB
- NFSv4.1 Kerberos
- Volúmenes de protocolo dual
NFSv4.1 Kerberos:
SMB
Protocolo doble
Una dirección IP se usa para la ruta de acceso de montaje cuando un volumen de archivos de Azure NetApp no requiere DNS, como NFSv3 o NFSv4.1 sin Kerberos.
NFSv3
Consideraciones
En Azure NetApp Files, las actualizaciones dinámicas de DNS envían dos solicitudes diferentes al servidor DNS configurado: una para un PTR y otra para la creación o actualización de registros A/AAAA.
Los volúmenes de Azure NetApp Files creados con nombres de host notifican automáticamente al servidor DNS que cree un registro A/AAAA. Esto sucede inmediatamente después de que se complete la creación del volumen.
Si un registro A/AAAA DNS ya está presente para la combinación de dirección IP o nombre de host, no se crea ningún registro nuevo.
Si un registro A/AAAA DNS está presente para el mismo nombre de host con una dirección IP diferente, se crea un segundo registro A/AAAA con el mismo nombre.
En el caso de los volúmenes de Azure NetApp Files creados sin nombres de host (como volúmenes NFSv3), DNS dinámico no crea los registros DNS, ya que no hay ningún nombre de host asignado en el servicio. Los registros se deben crear manualmente.
Si existe una zona de búsqueda inversa para la subred IP de la interfaz, el servidor DNS también crea un registro PTR. Si la zona de búsqueda inversa necesaria no existe, no se puede crear automáticamente un registro PTR. Debe crear manualmente el registro PTR.
Si se elimina una entrada DNS creada por DNS dinámico en el servidor DNS, se vuelve a crear en un plazo de 24 horas mediante una nueva actualización de DNS dinámico de Azure NetApp Files.
DDNS seguro se habilita cuando se crean volúmenes de protocolo SMB o dual. Los volúmenes NFS no habilitan DDNS seguros, pero sí habilitan DDNS. Si DDNS seguro está deshabilitado en el servidor DNS o se produce un error en la autenticación Kerberos, las actualizaciones de DDNS no funcionan.
Tipo DNS dinámico Port DNS Estándar UDP 53 DNS seguro TCP 53 Azure NetApp Files solo admite DDNS seguro con servidores DNS de Microsoft Active Directory.
Detalles de la entrada DNS dinámica
Cuando Azure NetApp Files crea un registro D/DDDD de DNS a través de DNS dinámico, se usan las siguientes configuraciones:
- Se activa una casilla de registro PTR asociada: si existen zonas de búsqueda inversa para la subred, los registros D/DDDD crean automáticamente registros PTR sin intervención del administrador.
- La casilla "Eliminar este registro cuando se vuelve obsoleta" está activada: Cuando el registro DNS se convierte en "obsoleto", DNS elimina el registro, siempre que se ha habilitado la limpieza para DNS.
- El "período de vida (TTL)" del registro DNS se establece en un día (24 horas): el administrador DNS puede modificar la configuración de TTL según sea necesario. El TTL de un registro DNS determina el período de tiempo que existe una entrada DNS en la caché DNS de un cliente.
Nota:
Para ver las marcas de tiempo y el período de vida (TTL) cuando se creó un registro DNS en DNS de Windows Active Directory, vaya al menú Ver del Administrador de DNS y a continuación, seleccione Avanzado. Desde allí, seleccione la entrada de registro A/AAAA y vea las propiedades.
Funcionamiento de DNS dinámico estándar en Azure NetApp Files
Azure NetApp Files sigue cuatro pasos básicos para crear actualizaciones dinámicas de DNS en los servidores DNS configurados. Las actualizaciones de DNS dinámico estándar (DDNS) atraviesan el puerto 53UDP.
- Se realiza una consulta de DNS de SOA para la dirección IP de la interfaz de volumen de Azure NetApp Files.
- Se realiza una actualización de DDNS para el PTR. Si el PTR no existe, se crea.
- Se realiza una consulta de inicio DNS de autoridad (SOA) para el nombre de dominio completo (FQDN) del volumen de Azure NetApp Files.
- Se realiza una actualización de DDNS para el registro A/AAAA. Si el registro no existe, se crea.
DNS dinámico a través de la captura de paquetes
Las capturas de paquetes pueden ser útiles para solucionar problemas de servicio que podrían no tener registro disponible para analizar. Expanda esta vista para obtener una vista detallada de las capturas de paquetes.
Se realiza una consulta de DNS de SOA para la dirección IP de la interfaz de volumen de 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:1111Se realiza una actualización de DDNS para el PTR. Si el PTR no existe, se crea.
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.localSe realiza una consulta de inicio DNS de autoridad (SOA) para el nombre de dominio completo (FQDN) del volumen de Azure NetApp Files.
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:1111Se realiza una actualización de DDNS para el registro A/AAAA. Si el registro no existe, se crea.
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
Funcionamiento de DDNS seguro en Azure NetApp Files
Cuando se habilita DNS seguro, Azure NetApp Files negocia con el servidor DNS para autenticarse a través de GSS mediante la Autenticación de transacciones de clave secreta para DNS, lo que garantiza que las actualizaciones solicitadas proceden de un origen legítimo. A continuación se muestran los pasos que se usan durante este proceso. Las actualizaciones seguras de DDNS atraviesan el puerto 53 TCP.
- Se realiza una consulta de DNS de SOA para la dirección IP de la interfaz de volumen de Azure NetApp Files.
- Se intercambia un vale de servicio Kerberos para el servicio DNS en el servidor DNS.
- A continuación, el vale se usa en una consulta de DNS para una clave de transacción (TKEY) de Azure NetApp Files al servidor DNS, que se pasa mediante GSS-TSIG (firma de transacción) para autenticarse.
- Una vez autenticado correctamente, se envía una actualización de DNS dinámica segura mediante el TKEY para crear el PTR mediante GSS-TSIG. Si el registro aún no existe, se crea.
- Se envía una consulta SOA de DNS para el nombre de dominio completo (FQDN) del volumen de Azure NetApp Files y se responde a.
- Se intercambia un nuevo identificador de TKEY entre el servidor DNS y Azure NetApp Files.
- Se envía una actualización de DNS dinámica segura mediante el TKEY para crear el registro A/AAAA para el FQDN. Si el registro ya existe con la misma dirección IP, no se realizan cambios.
DNS dinámico a través de la captura de paquetes
Las capturas de paquetes pueden ser útiles para solucionar problemas de servicio que podrían no tener registro disponible para analizar. Expanda esta vista para obtener una vista detallada de las capturas de paquetes.
Se realiza una consulta de DNS de SOA para la dirección IP de la interfaz de volumen de 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:1111Se intercambia un vale de servicio Kerberos para el servicio DNS en el servidor 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-REPA continuación, el vale se usa en una consulta de DNS para una clave de transacción (TKEY) de Azure NetApp Files al servidor DNS, que se pasa mediante GSS-TSIG (firma de transacción) para autenticarse.
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 TSIGUna vez autenticado correctamente, se envía una actualización de DNS dinámica segura mediante el TKEY para crear el PTR mediante GSS-TSIG. Si el registro aún no existe, se crea.
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)Se envía una consulta SOA de DNS para el nombre de dominio completo (FQDN) del volumen de Azure NetApp Files y se responde a.
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:1111Se intercambia un nuevo identificador de TKEY entre el servidor DNS y 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 TSIGSe envía una actualización de DNS dinámica segura mediante el TKEY para crear el registro A/AAAA para el FQDN. Si el registro ya existe con la misma dirección IP, no se realizan cambios.
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)
Almacenamiento en caché de DNS
Para reducir la carga en servidores DNS, los clientes DNS usan conceptos de almacenamiento en caché para almacenar consultas anteriores en memoria para que las solicitudes repetidas de un nombre de host, IP o servicio se mantengan localmente durante el período de tiempo definido por el TTL del registro DNS.
Azure NetApp Files usa cachés DNS como cualquier otro cliente DNS estándar. Cuando el servicio solicita un registro DNS, ese registro tiene definido un TTL. De manera predeterminada, las entradas DNS de Active Directory tienen un TTL de 600 segundos (10 minutos) a menos que se especifique lo contrario. Si se actualiza un registro DNS y reside en la memoria caché de Azure NetApp Files y el TTL es de 10 minutos, el nuevo registro no se actualiza en Azure NetApp Files hasta que la memoria caché se purga después del valor de tiempo de espera. Actualmente no hay ninguna manera de purgar manualmente esta memoria caché. Si se desea un TTL inferior, realice el cambio desde el servidor DNS.
Al usar servidores DNS externos (como BIND), los valores de tiempo de espera predeterminados pueden diferir. Si no está definido, el TTL de un registro DNS BIND es de 604 800 segundos (siete días), demasiado largo para el almacenamiento en caché de DNS efectivo. Por lo tanto, al crear registros DNS manualmente, es importante establecer manualmente el TTL para el registro en un valor razonable. Se recomienda usar el valor predeterminado de Microsoft de 10 minutos para una combinación de rendimiento y confiabilidad para las búsquedas de DNS.
Puede consultar manualmente el TTL de un registro DNS mediante comandos nslookup o dig. Para obtener ejemplos, consulte Uso nslookup y dig para consultas DNS.
Eliminación o limpieza de registros DNS
La mayoría de los servidores DNS proporcionan métodos para eliminar y limpiar los registros expirados. La eliminación ayuda a evitar que los registros obsoletos enmarañen los servidores DNS y creen escenarios en los que existan registros D/DDDD o PTR duplicados, lo que puede crear resultados imprevisibles en los volúmenes de Azure NetApp Files.
Si hay varios registros PTR para el mismo punto de dirección IP en nombres de host diferentes, es posible que se produzca un error en las solicitudes de Kerberos porque se recupera el SPN incorrecto durante las búsquedas DNS. DNS no distingue qué registro PTR pertenece al nombre de host; en su lugar, las búsquedas inversas realizan una búsqueda round robin a través de cada registro D/DDDD en cada nueva búsqueda.
Por ejemplo:
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
Alias DNS y registros de nombre canónico (CNAME)
Azure NetApp Files crea un nombre de host DNS para un volumen que se ha configurado para un protocolo que requiere DNS para que funcione correctamente, como SMB, protocolo dual o NFSv4.1 con Kerberos. El nombre creado usa el formato del servidor SMB (cuenta de equipo) como prefijo al crear la conexión de Active Directory para la cuenta de NetApp; para que varias entradas de volumen de la misma cuenta de NetApp tengan nombres únicos, se agregan caracteres alfanuméricos adicionales. En la mayoría de los casos, si hay varios volúmenes que requieren nombres de host y existen en la misma cuenta de NetApp, estos intentan usar los mismos nombres de host o direcciones IP. Por ejemplo, si el nombre del servidor SMB es SMB-West.contoso.com, las entradas de nombre de host siguen el formato de SMB-West-XXXX.contoso.com.
En algunos casos, es posible que el nombre usado por Azure NetApp Files no sea lo suficientemente fácil de pasar a los usuarios finales, o es posible que los administradores quieran mantener nombres DNS más conocidos que se usan cuando los datos se han migrado desde el almacenamiento local a Azure NetApp Files (es decir, si el nombre DNS original era datalake.contoso.com, es posible que los usuarios finales quieran seguir usando ese nombre).
Azure NetApp Files no permite de forma nativa la especificación de nombres de host DNS usados. Si necesita un nombre DNS alternativo con la misma funcionalidad, debe usar un alias DNS o un alias/nombre canónico (CNAME) de DNS.
Con un registro CNAME (en lugar de un registro D/DDDD adicional) que apunta al registro D/DDDD del volumen de Azure NetApp Files, se aprovecha el mismo SPN que el del servidor SMB para habilitar el acceso Kerberos tanto para el registro D/DDDD como para el CNAME. Considere el ejemplo de un registro D/DDDD de SMB-West-XXXX.contoso.com. El registro CNAME de datalake.contoso.com está configurado para que apunte al registro D/DDDD de SMB-West-XXXX.contoso.com. Las solicitudes de Kerberos SMB o NFS realizadas para datalake.contoso.com usan el SPN de Kerberos para SMB-West-XXXX para proporcionar acceso al volumen.
Uso de nslookup y excavación para consulta de DNS
Los servidores DNS se pueden consultar manualmente mediante herramientas DNS como nslookup (clientes Windows y Linux) y dig (clientes Linux). El uso de estas herramientas es útil en escenarios que incluyen intentar comprobar la funcionalidad de los servicios, probar el nombre de host o la resolución IP, buscar registros DNS existentes o obsoletos, comprobar la configuración del servidor, comprobar TTL. También puede usar el Solucionador de problemas de conexión de Azure para solucionar problemas adicionales.
Los comandos nslookup y dig se pueden ejecutar desde una conexión remota a la máquina virtual (por ejemplo, desde Bastion) o directamente a la máquina virtual a través de la opción ejecutar comando en la propia máquina virtual.
nslookup con Windows
Puede ejecutar nslookup para recopilar información básica de direcciones IP sin opciones:
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
Para consultar solo la información de TTL del registro, use la opción de comando -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)
La opción -debug también se puede usar para recopilar información más detallada sobre el registro 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)
excavación con 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
Procedimientos recomendados de DNS en Azure NetApp Files
Asegúrese de cumplir los siguientes requisitos de configuración de DNS:
- Especifique más de un servidor DNS en la configuración DNS para la redundancia.
- Para obtener los mejores resultados, use DNS integrado con o instalado con Active Directory.
- Si usa servidores DNS independientes:
- Asegúrese de que los servidores DNS tienen conectividad de red con la subred delegada de Azure NetApp Files que hospeda los volúmenes de Azure NetApp Files.
- Asegúrese de que los puertos de red UDP 53 y TCP 53 no están bloqueados por firewalls o grupos de seguridad de red.
- Asegúrese de que los registros SRV registrados por el servicio de inicio de sesión net de AD DS se han creado en los servidores DNS, así como los registros de servicio enumerados en Tipos de registros DNS en Azure NetApp Files.
- Asegúrese de que los registros PTR de los controladores de dominio de AD DS usados por Azure NetApp Files se hayan creado en los servidores DNS en el mismo dominio que el de la configuración de Azure NetApp Files.
- Azure NetApp Files admite actualizaciones de DNS dinámico seguras y estándar. Si necesita actualizaciones de DNS dinámico seguras, asegúrese de que las actualizaciones seguras están configuradas en los servidores DNS.
- Asegúrese de que se ha creado una zona de búsqueda inversa para la subred de Azure NetApp Files para permitir que DNS dinámico cree registros PTR además del registro A/AAAA.
- Si se requiere un alias DNS, use un registro CNAME. Apunte el registro CNAME a los registros A/AAAA de Azure NetApp Files.
- Si no usa actualizaciones dinámicas de DNS, debe crear manualmente un registro A y un registro PTR para las cuentas de equipo de AD DS creadas en la unidad organizativa de AD DS (especificada en la conexión AD de Azure NetApp Files) para admitir la firma LDAP de Azure NetApp Files, LDAP a través de TLS, SMB, protocolo dual o volúmenes NFSv4.1 de Kerberos.
- En el caso de topologías complejas o grandes de AD DS, es posible que se requiera Directivas DNS o priorización de subred DNS para admitir volúmenes NFS habilitados para LDAP.
- Si la limpieza de DNS está habilitada (donde las entradas DNS obsoletas se eliminan automáticamente en función de la marca de tiempo o la antigüedad) y el DNS dinámico se usó para crear los registros DNS para el volumen de Azure NetApp Files, el proceso de limpieza podría eliminar accidentalmente los registros del volumen. Esta eliminación puede provocar una interrupción del servicio para las consultas basadas en nombres. Hasta que se resuelva este problema, cree manualmente entradas A/AAAA y PTR de DNS para el volumen de Azure NetApp Files si está habilitada la limpieza de DNS.