Descripción de los sistemas de nombres de dominio en Azure NetApp Files
El servicio Sistemas de nombres de dominio (DNS) es un componente crítico del acceso a datos en Azure NetApp Files cuando se usan protocolos de archivo que dependen de Kerberos para la autenticación (incluido SMB y NFSv4.1). Un nombre de host simplifica el acceso a un volumen y protege frente a escenarios en los que cambia una dirección IP; en lugar de informar a los usuarios de una nueva dirección IP, pueden seguir usando el nombre de host.
De forma predeterminada, la autenticación Kerberos aprovecha la resolución de nombre a dirección IP para formular el nombre de la entidad de seguridad de servicio (SPN) que se usa para recuperar el vale de Kerberos. Por ejemplo, cuando se accede a un recurso compartido SMB con una ruta de acceso UNC, como \SMB.CONTOSO.COM, se emite una solicitud DNS para SMB.CONTOSO.COM y se recupera la dirección IP del volumen de Azure NetApp Files. Si no existe ninguna entrada DNS (o la entrada actual es diferente de lo que se solicita, por ejemplo, con alias o CNAME), no se puede recuperar un SPN adecuado y se produce un error en la solicitud de Kerberos. Como resultado, se podría denegar el acceso al volumen si el método de autenticación de reserva (como New Technology LAN Manager) está deshabilitado.
NFSv4.1 Kerberos funciona de forma similar para la recuperación de SPN, donde las búsquedas DNS son integrales para el proceso de autenticación y también se pueden usar para la detección de dominios de Kerberos.
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 servidores DNS puede provocar interrupciones en el acceso de clientes o agotamientos de los tiempos de espera del cliente. Los registros DNS incompletos o incorrectos para AD DS o Azure NetApp Files pueden provocar interrupciones en el acceso de clientes o agotamientos de los tiempos de espera del cliente.
Direcciones IP para el acceso con Kerberos
Si se usa una dirección IP en una solicitud de acceso a un volumen de Azure NetApp Files, una solicitud de Kerberos funcionará de forma diferente en función del protocolo en uso.
SMB
Cuando se usa SMB, una solicitud de UNC mediante \x.x.x.x.x de forma predeterminada intenta usar NTLM para la autenticación. En entornos en los que NTLM no se permite por motivos de seguridad, una solicitud SMB mediante una dirección IP no puede usar Kerberos ni NTLM para la autenticación de forma predeterminada. Como resultado, se deniega el acceso al volumen de Azure NetApp Files. En versiones posteriores de Windows (a partir de Windows 10 versión 1507 y Windows Server 2016), los clientes de Kerberos se pueden configurar para admitir nombres de host IPv4 e IPv6 en SPN para la comunicación SMB.
NFSv4.1
Cuando se usa NFSv4.1, una solicitud de montaje a una dirección IP mediante una de las opciones sec=[krb5/krb5i/krb5p] usa búsquedas DNS inversas a través de un registro de puntero (PTR) para resolver una dirección IP en un nombre de host, que luego se usa para formular el SPN para la recuperación de vales. Si usa NFSv4.1 con Kerberos, debe tener un registro D/DDDD y PTR para el volumen de Azure NetApp Files para cubrir el acceso de nombre de host y dirección IP a los montajes.
Entradas DNS en Azure NetApp Files
Los volúmenes de Azure NetApp Files admiten actualizaciones DNS dinámicas si el servidor DNS admite DNS dinámico. Con DNS dinámico, los volúmenes creados con nombres de host notifican automáticamente al servidor DNS que cree un registro D/DDDD. Si existe una zona de búsqueda inversa, DNS también crea un registro PTR. Si la zona de búsqueda inversa no existe, no se crea automáticamente un registro PTR, lo que significa que debe crearlo manualmente.
Se usan nombres de host (en lugar de direcciones IP) para las rutas de montaje de volúmenes en configuraciones específicas, lo que requiere DNS para una funcionalidad adecuada:
- Volúmenes SMB
- NFSv4.1 Kerberos
- Volúmenes de protocolo dual
Se usa una dirección IP cuando un volumen de Azure NetApp File no requiere DNS, como NFSv3 o NFSv4.1 sin Kerberos. En esos casos, puede crear manualmente una entrada DNS si lo desea.
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.
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 vuelva obsoleto" está activada. Cuando el registro DNS se vuelve "obsoleto", DNS elimina el registro, siempre y cuando se haya habilitado la limpieza para DNS.
- El "período de vida (TTL)" del registro DNS se establece en un día (24 horas). El administrador de 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 de 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.
Eliminación o limpieza de registros DNS
La mayoría de los servidores DNS proporcionan métodos para eliminar o 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 bastante 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.
Procedimientos recomendados de DNS en Azure NetApp Files
Asegúrese de cumplir los siguientes requisitos sobre las configuraciones de DNS:
- Si usa servidores DNS independientes:
- Asegúrese de que los servidores DNS tienen conectividad de red a 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 Net Logon de AD DS se han creado en los servidores DNS.
- 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.
- Si no se usan actualizaciones de DNS dinámico, debe crear manualmente un registro D 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 de AD de Azure NetApp Files) para admitir la firma LDAP de Azure NetApp Files, LDAP a través de TLS, SMB, protocolo doble o volúmenes NFSv4.1 de Kerberos.
- Para topologías de AD DS complejas o grandes, es posible que la priorización de subredes DNS o directivas de DNS deba 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.