你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

了解 Azure NetApp 文件中的域名系统

Azure NetApp 文件支持使用 Active Directory 集成 DNS 或独立 DNS 服务器,并且需要对域名系统(DNS)服务和最新的 DNS 记录进行可靠的访问。 Azure NetApp 文件与 DNS 服务器之间的网络连接不佳可能会导致客户端访问中断或客户端超时。 Active Directory 域服务 (AD DS) 或 Azure NetApp 文件的 DNS 记录不完整或不正确可能会导致客户端访问中断或客户端超时。

DNS 服务是 Azure NetApp 文件中数据访问的关键组件。 通过 SMB、NFSV4.1 Kerberos、LDAP 和 Active Directory 站点发现实施文件协议访问,在这些操作中全都大量使用了 DNS 。 在 DNS 中集中使用主机名可以简化对卷的访问,并防止 IP 地址更改时会出现的情况。 用户可以继续使用用户友好的主机名,而不需要管理员通知用户新的 IP 地址。

DNS 服务器在 Active Directory 连接下完成配置。 可以添加主服务器和辅助服务器,以及 Active Directory DNS 名称。

注意

最佳做法是配置多个 DNS 服务器来实现冗余。

屏幕截图:DNS 设置。

关于 DNS 服务器

Azure NetApp 文件需要适用于 SMB 和 NFSv4.1 Kerberos 功能的 Active Directory 连接。 Active Directory 需要 DNS 才能正常运行。 在大多数情况下,Active Directory 部署会随与域控制器集成的 DNS 服务器一起安装。 此配置是 Microsoft 最佳做法,既便于使用,又可确保为域服务创建所有必需的 DNS 记录。

AD DNS 配置示意图。

在某些情况下,可以使用外部 DNS 服务器(如 BIND),代替(或补充)Active Directory 托管的 DNS 服务。 这称为不相互连接的命名空间

外部绑定配置示意图。

Azure NetApp 文件支持同时使用集成和外部 DNS 服务器,但在不使用 Active Directory 集成的情况下使用外部 DNS 服务器时,请务必确保向 DNS 添加必要的服务 (SRV) 记录,以便 DNS 正常运行并获得服务的冗余。 Azure NetApp 文件与 DNS 服务器之间的网络连接不佳可能会导致客户端访问中断或客户端超时。 AD DS 或 Azure NetApp 文件的 DNS 记录不完整或不正确可能会导致客户端访问中断或客户端超时。

有关服务使用的 SRV 记录列表,请参阅 Azure NetApp 文件中的 DNS 记录。 另请参阅包含 Active Directory 的 DNS 的指南将 AD DS 集成到现有 DNS 基础结构

Azure DNS 与 Azure NetApp 文件集成

Azure DNS 是 Microsoft Azure 中的一种托管的 DNS 管理和名称解析服务。 可以使用它为 Azure 中部署的其他应用程序和服务(包括 Azure NetApp 文件)创建公共或专用 DNS 名称。 在 Azure 中部署 DNS 就可避免在 Azure NetApp 文件和/或 Active Directory 域之间直接发送 DNS 请求(通过端口 53)。 此外,Azure DNS 还可用于创建条件转发器(使用 Azure 专用 DNS 解析程序),这些转发器可用于通过 Azure 中托管的专用 DNS 服务器(可在 Active Directory 连接中指定)将 DNS 请求从 Azure NetApp 文件发送到特定的 DNS 服务器。

Azure DNS 配置示意图。

有关使用 Azure DNS 的信息:

在 Azure NetApp 文件中将负载均衡器 IP 地址与 DNS 配合使用

负载均衡器设备是一种使单个 IP 地址能够为后端多个 IP 地址提供服务的方式。 该方式通过模糊处理提供安全性,同时为企业环境带来了性能提升和冗余优势。

负载均衡器配置示意图。

DNS 负载均衡器可以为请求提供服务,并将其发送到池中指定的多个 DNS 服务器。 Microsoft Azure 为多个用例提供本机负载均衡服务

Azure NetApp 文件支持使用 DNS 负载均衡器,前提是 DNS 负载均衡器提供 IP 地址作为终结点,并且 IP 地址可以通过端口 53 与 Azure NetApp 文件网络进行通信。 例如,Azure 流量管理器在第 7 层提供 DNS 负载均衡,但仅提供要使用的前端主机名。 Azure NetApp 文件 Active Directory 连接仅允许为 DNS 服务器指定 IP 地址。

Azure NetApp 文件中的 DNS 记录类型

Azure NetApp 文件使用不同类型的 DNS 记录来访问文件服务。

DNS 记录类型 定义
A/AAAA DNS A 记录是指示主机名 IPv4 地址的地址记录。 AAAA 记录指示主机名的 IPv6 地址。 Azure NetApp 文件通过以下方式使用 A/AAAA 记录
  • 屏蔽用户友好主机名后面的 IP 地址
  • Kerberos 服务主体请求
  • 根域查询
指针记录 (PTR) PTR 记录通过反向查找区域将 IP 地址映射到主机名。 为 Azure NetApp 文件中的装载/共享指定 IP 地址时,主要使用 PTR 记录。 在装载/共享请求中使用 IP 地址可能会影响使用的身份验证方法。 有关详细信息,请参阅使用 Kerberos 进行访问的 IP 地址
服务记录 (SRV) SRV 记录用于指定用于特定服务(例如 LDAP、NFS、CIFS、Kerberos 等)的主机和端口。Azure NetApp 文件中的 SRV 记录大量用于文件服务安全(例如 Kerberos)、Active Directory 中的站点发现、LDAP 服务器查询等。 请务必验证是否存在这些记录,以确保 Azure NetApp 文件服务正常运行。
可以使用 nslookupdig 命令查询
SRV 记录。 有关示例,请参阅使用 nslookupdig 执行 DNS 查询
规范名称 (CNAME) CNAME 记录是为 A/AAAA 记录提供 DNS 别名的方式。 CNAME 记录是可选的,但有助于降低 Azure NetApp 文件提供的主机名记录的复杂性。 有关详细信息,请参阅 DNS 别名和规范名称记录
统一资源标识符 (URI) URI 记录是将服务的主机名/IP 地址映射到 URI 的方式。 URI 以如下格式显示:service://fqdn.contoso.com。

仅当对 NFS Kerberos 请求执行 Kerberos KDC 查找时,Azure NetApp 文件才会对 URI 记录使用查询。 默认情况下,系统不会在 Active Directory DNS 部署中创建 URI 记录。 因此,URI 查找请求通常会失败并回退到 SRV 记录查找。

用于 Azure NetApp 文件的服务记录 (SRV)

Azure NetApp 文件使用以下 SRV 记录:

  • NFS Kerberos*
    • _kerberos-master._tcp.CONTOSO.COM(端口 88)*
    • _kerberos-master._tcp.CONTOSO.COM(端口 88)*
  • SMB/Active Directory 站点发现**
    • _kerberos.CONTOSO.COM(端口 88)
    • _kerberos._tcp.CONTOSO.COM(端口 88)
    • _kerberos._tcp.dc_msdcs.CONTOSO.COM(端口 88)
    • _kpasswd._tcp.dc._msdcs.CONTOSO.COM(端口 464)
    • _kpasswd._tcp.CONTOSO.COM(端口 464)
    • _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.CONTOSO.COM(端口 88)
    • _kerberos._tcp.{其他站点名称}._sites.dc._msdcs.CONTOSO.COM(端口 88)
    • _kerberos.udp.CONTOSO.COM(端口 88)
    • _kerberos._udp.dc_msdcs.CONTOSO.COM(端口 88)
    • _kpasswd._udp.dc._msdcs.CONTOSO.COM(端口 464)
    • _kpasswd._udp.CONTOSO.COM(端口 464)
    • _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.CONTOSO.COM(端口 88)
    • _kerberos._udp.{其他站点名称}._sites.dc._msdcs.CONTOSO.COM(端口 88)
  • LDAP**
    • _ldap.CONTOSO.COM(端口 389)
    • _ldap._tcp.CONTOSO.COM(端口 389)
    • _ldap._udp.CONTOSO.COM(端口 389)

* 默认情况下,Active Directory DNS 不会创建这些 SRV 记录。 强烈建议在使用 NFS Kerberos 时创建这些记录。

** Active Directory DNS 默认会创建这些 SRV 记录。

有关 Azure NetApp 文件如何使用 SRV 记录的详细信息,请参阅:

注意

在 NFS Kerberos 中,为了实现正确的密钥分发中心发现和冗余,必须创建 URI 记录和/或 kerberos - master SRV 记录。

动态 DNS

Azure NetApp 文件卷为卷提供单个 IP 地址,然后通过动态 DNS (DDNS) 自动添加到 DNS(前提是 DNS 服务器支持动态域名系统)。 主机名(而不是 IP 地址)用于特定配置中的卷装载路径。 在装载路径中使用主机名需要 DNS 才能确保功能正常运行:

  • SMB 卷
  • NFSv4.1 Kerberos
  • 双协议卷

NFSv4.1 Kerberos:

屏幕截图:NFSv4.1 装载路径。

SMB

屏幕截图:SMB 装载路径。

双协议

屏幕截图:双协议装载路径。

当 Azure NetApp 文件卷不需要 DNS(例如不使用 Kerberos 的 NFSv3 或 NFSv4.1)时,装载路径将使用 IP 地址。

NFSv3

屏幕截图:NFS3 装载路径。

注意事项

在 Azure NetApp 文件中,动态 DNS 更新会将两个不同的请求发送到配置的 DNS 服务器:一个用于 PTR,另一个用于 A/AAAA 记录创建/更新。

  • 使用主机名创建的 Azure NetApp 文件卷会自动通知 DNS 服务器创建 A/AAAA 记录。 卷创建完成后,会立即发生这种情况。

  • 如果 IP 地址/主机名组合中已存在 DNS A/AAAA 记录,则系统不会创建新记录。

  • 如果对于同一主机名已存在一条 DNS A/AAAA 记录,且其对应一个不同的 IP 地址,则系统会创建另一条同名的 A/AAAA 记录。

  • 对于在没有主机名(如 NFSv3 卷)的情况下创建的 Azure NetApp 文件卷,动态 DNS 不会创建 DNS 记录,因为服务中没有分配主机名。 必须手动创建记录。

  • 如果接口 IP 子网存在反向查找区域,则 DNS 服务器还会创建 PTR 记录。 如果必要的反向查找区域不存在,则无法自动创建 PTR 记录。 必须手动创建 PTR 记录。

  • 如果在 DNS 服务器上删除了动态 DNS 创建的 DNS 条目,则会在 24 小时内通过 Azure NetApp 文件的新动态 DNS 更新重新创建该条目。

  • 创建 SMB 或双协议卷时,将启用安全 DDNS。 NFS 卷不会启用安全 DDNS,但确实会启用 DDNS。 如果在 DNS 服务器上禁用安全 DDNS 或 Kerberos 身份验证失败,则 DDNS 更新将不起作用。

    动态 DNS 类型 端口
    标准 DNS UDP 53
    安全 DNS TCP 53
  • Azure NetApp 文件仅在使用 Microsoft Active Directory DNS 服务器时支持安全 DDNS。

动态 DNS 条目详细信息

当 Azure NetApp 文件通过动态 DNS 创建 DNS A/AAAA 记录时,将使用以下配置:

  • 选中关联的 PTR 记录框:如果子网存在反向查找区域,则 A/AAAA 记录会自动创建 PTR 记录,无需管理员干预。
  • 选中“在过期时删除此记录”框:当 DNS 记录变为“过时”时,DNS 会删除记录,前提是已启用 DNS 清理。
  • DNS 记录的“生存时间 (TTL)”设置为一天(24 小时):DNS 管理员可根据需要修改 TTL 设置。 DNS 记录上的 TTL 决定客户端的 DNS 缓存中存在的 DNS 条目的时间长度。

注意

要查看在 Windows Active Directory DNS 中创建 DNS 记录的时间戳和生存时间 (TTL),请导航到 DNS 管理器的“视图”菜单,然后选择“高级”。 在此处,选择 A/AAAA 记录条目并查看属性。

屏幕截图:DNS 时间戳。

Azure NetApp 文件中的标准动态 DNS 的工作原理

Azure NetApp 文件遵循四个基本步骤,以为配置的 DNS 服务器创建动态 DNS 更新。 标准动态 DNS (DDNS) 更新遍历 UDP 端口 53。

  • 对 Azure NetApp 文件卷接口的 IP 地址执行 SOA DNS 查询。
  • 对 PTR 执行 DDNS 更新。 如果 PTR 不存在,则系统会创建 PTR。
  • 对 Azure NetApp 文件卷的完全限定域名 (FQDN) 执行 DNS 起始授权 (SOA) 查询。
  • 对 A/AAAA 记录执行 DDNS 更新。 如果该记录不存在,则系统会创建该记录。

通过数据包捕获的动态 DNS

数据包捕获可用于排查可能没有可用日志记录供分析的服务问题。请展开此视图,以详细了解数据包捕获。
  1. 对 Azure NetApp 文件卷接口的 IP 地址执行 SOA DNS 查询。

    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. 对 PTR 执行 DDNS 更新。 如果 PTR 不存在,则系统会创建 PTR。

    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. 对 Azure NetApp 文件卷的完全限定域名 (FQDN) 执行 DNS 起始授权 (SOA) 查询。

    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. 对 A/AAAA 记录执行 DDNS 更新。 如果该记录不存在,则系统会创建该记录。

    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
    

Azure NetApp 文件中的安全 DDNS 的工作原理

启用安全 DNS 后,Azure NetApp 文件会与 DNS 服务器协商,使用适用于 DNS 的密钥事务身份验证通过 GSS 进行身份验证,确保请求的更新来自合法源。 以下内容显示了在此过程中使用的步骤。安全 DDNS 更新遍历 TCP 端口 53。

  • 对 Azure NetApp 文件卷接口的 IP 地址执行 SOA DNS 查询。
  • Kerberos 服务票证将交换到 DNS 服务器上的 DNS 服务。
  • 然后,该票证用于 DNS 查询中的事务密钥 (TKEY) 从 Azure NetApp 文件传递到 DNS 服务器,该服务器使用 GSS-TSIG(事务签名)进行身份验证。
  • 成功进行身份验证后,系统会使用 TKEY 来发送安全动态 DNS 更新,以使用 GSS-TSIG 来建立 PTR。 如果记录尚不存在,则系统会创建该记录。
  • 为 Azure NetApp 文件卷的完全限定域名 (FQDN) 发送 DNS SOA 查询并响应。
  • DNS 服务器与 Azure NetApp 文件之间已交换新的 TKEY ID。
  • 系统已使用 TKEY 发送安全动态 DNS 更新,以为 FQDN 创建 A/AAAA 记录。 如果记录已存在具有相同 IP 地址,则系统不会做出更改。

通过数据包捕获的动态 DNS

数据包捕获可用于排查可能没有可用日志记录供分析的服务问题。请展开此视图,以详细了解数据包捕获。
  1. 对 Azure NetApp 文件卷接口的 IP 地址执行 SOA DNS 查询。

    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. Kerberos 服务票证将交换到 DNS 服务器上的 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-REP
    
    
  3. 然后,该票证用于 DNS 查询中的事务密钥 (TKEY) 从 Azure NetApp 文件传递到 DNS 服务器,该服务器使用 GSS-TSIG(事务签名)进行身份验证。

        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. 成功进行身份验证后,系统会使用 TKEY 来发送安全动态 DNS 更新,以使用 GSS-TSIG 来建立 PTR。 如果记录尚不存在,则系统会创建该记录。

    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. 为 Azure NetApp 文件卷的完全限定域名 (FQDN) 发送 DNS SOA 查询并响应。

    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. DNS 服务器与 Azure NetApp 文件之间已交换新的 TKEY ID。

    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. 系统已使用 TKEY 发送安全动态 DNS 更新,以为 FQDN 创建 A/AAAA 记录。 如果记录已存在具有相同 IP 地址,则系统不会做出更改。

        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 缓存

为减轻 DNS 服务器的负载,DNS 客户端采用缓存机制,将之前的查询结果存储在内存中。这样,对于主机名、IP 地址或服务的重复查询请求,会在本地保存 DNS 记录所规定的 TTL 时长。

Azure NetApp 文件使用 DNS 缓存,就像任何其他标准 DNS 客户端一样。 当服务请求 DNS 记录时,该记录定义了 TTL。 默认情况下,Active Directory DNS 条目的 TTL 为 600 秒(10 分钟),除非另有指定。 如果 DNS 记录已更新并驻留在 Azure NetApp 文件缓存中,并且 TTL 为 10 分钟,则在超时值后清除缓存之前,新记录不会在 Azure NetApp 文件中更新。 目前无法手动清除此缓存。 如果需要较低的 TTL,请从 DNS 服务器进行更改。

使用外部 DNS 服务器(如 BIND)时,默认超时值可能会有所不同。 如果未定义,则 BIND DNS 记录的 TTL 为 604,800 秒(7 天),该时间对于有效的 DNS 缓存而言太长了。 因此,手动创建 DNS 记录时,请务必将记录的 TTL 手动设置为合理的值。 建议使用 Microsoft 默认的 10 分钟,以此在 DNS 查询的性能和可靠性之间取得平衡。

你可以使用或 nslookupdig 命令手动查询 DNS 记录的 TTL。 有关示例,请参阅使用 nslookupdig 执行 DNS 查询

DNS 记录精简/回收

大多数 DNS 服务器提供修剪和清理过期记录的方法。 精简有助于防止过时的记录使 DNS 服务器混乱,以及造成重复的 A/AAAA 和/或 PTR 记录,这可能会为 Azure NetApp 文件卷带来不可预知的结果。

如果同一 IP 地址的多个 PTR 记录指向不同的主机名,则 Kerberos 请求可能会失败,因为 DNS 查找期间检索到不正确的 SPN。 DNS 不会识别哪些 PTR 记录属于哪个主机名;相反,反向查找会针对每个新查找循环搜索每个 A/AAAA 记录。

例如:

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 别名和规范名称 (CNAME) 记录

Azure NetApp 文件为已为协议配置的卷创建 DNS 主机名,该协议(例如 SMB,双重协议或使用 Kerberos 的 NFSv4.1)需要 DNS 获取适当的功能。 为 NetApp 帐户创建 Active Directory 连接时,创建的名称使用 SMB 服务器(计算机帐户)的格式作为前缀,并添加了额外的字母数字字符,以便同一 NetApp 帐户中的多个卷条目具有唯一的名称。 在大多数情况下,需要主机名并存在于同一 NetApp 帐户中的多个卷会尝试使用相同的主机名/IP 地址。 例如,如果 SMB 服务器名称为 SMB-West.contoso.com,则主机名条目遵循 SMB-West-XXXX.contoso.com 的格式。

在某些情况下,Azure NetApp 文件使用的名称可能不好记,无法传递给最终用户,或者管理员可能需要保留更熟悉的 DNS 名称(数据从本地存储迁移到 Azure NetApp 文件时所使用的名称,例如,如果原始 DNS 名称为 datalake.contoso.com,则最终用户可能需要继续使用该名称)。

Azure NetApp 文件本身不允许指定使用的 DNS 主机名规范。 如果需要具有相同功能的备用 DNS 名称,则应使用 DNS 别名/规范名称 (CNAME)

使用指向 Azure NetApp 文件卷的 A/AAAA 记录的 CNAME 记录(而不是额外的 A/AAAA 记录)利用与 SMB 服务器相同的 SPN 来为 A/AAAA 记录和 CNAME 启用 Kerberos 访问。 请参考 SMB-West-XXXX.contoso.com 的 A/AAAA 记录的示例。 Datalake.contoso.com 的 CNAME 记录配置为指向 SMB-West-XXXX.contoso.com 的 A/AAAA 记录。 向 datalake.contoso.com 发出的 SMB 或 NFS Kerberos 请求将 Kerberos SPN 用于 SMB-West-XXXX,以提供对卷的访问权限。

使用 nslookup 和 dig 进行 DNS 查询

可以使用 DNS 工具(如 nslookupWindows 和 Linux 客户端)和(digLinux 客户端)手动查询 DNS 服务器。 在以下方案中使用这些工具非常实用:尝试验证服务的功能、测试主机名/IP 解析、搜索现有/过时 DNS 记录、检查服务器配置、验证 TTL。 你还可以使用 Azure 连接疑难解答来解决其他问题。

可以通过与 VM(例如 Bastion)的远程连接或直接通过 VM 本身的运行命令选项来运行 nslookupdig 命令。

在 Windows 中使用 nslookup 命令

你可以在不使用任何选项的情况下运行 nslookup 以收集基本 IP 地址信息:

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

若要仅查询记录的 TTL 信息,请使用 -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)

-debug 选项还可用于收集有关 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)

在 Linux 中使用 dig 命令

# 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

Azure NetApp 文件的 DNS 最佳做法

确保满足以下 DNS 配置要求:

  • 在 DNS 配置中指定多个 DNS 服务器来实现冗余。
  • 为了获得最佳结果,请使用与 Active Directory 集成的 DNS 和/或随 Active Directory 一同安装的 DNS。
  • 如果使用独立 DNS 服务器:
    • 确保 DNS 服务器可与托管 Azure NetApp 文件卷的 Azure NetApp 文件委托子网建立网络连接。
    • 确保防火墙或网络安全组不会阻止网络端口 UDP 53 和 TCP 53。
  • 确保由 AD DS 网络登录服务注册的 SRV 记录已在 DNS 服务器上创建,同时也要确保在 Azure NetApp 文件的 DNS 记录类型中列出的服务记录已创建。
  • 在与 Azure NetApp 文件配置相同的域中,确保已在 DNS 服务器上创建了 Azure NetApp 文件使用的 AD DS 域控制器的 PTR 记录。
  • Azure NetApp 文件支持标准的安全动态 DNS 更新。 如果需要安全动态 DNS 更新,请确保在 DNS 服务器上配置安全更新。
  • 确保已为 Azure NetApp 文件子网创建反向查找区域,以允许动态 DNS 创建除 A/AAAA 记录之外的 PTR 记录。
  • 如果需要 DNS 别名,请使用 CNAME 记录。 将 CNAME 记录指向 Azure NetApp 文件的 A/AAAA 记录。
  • 如果未使用动态 DNS 更新,则必须为 AD DS 组织单位(Azure NetApp 文件 AD 连接中指定的)中创建的 AD DS 计算机帐户手动创建 A 记录和 PTR 记录,以支持 Azure NetApp 文件 LDAP 签名、基于 TLS 的 LDAP、SMB、双重协议或 Kerberos NFSv4.1 卷。
  • 对于复杂或大型 AD DS 拓扑,可能需要 DNS 策略或 DNS 子网优先级以支持已启用 LDAP 的 NFS 卷
  • 如果启用了 DNS 清理(即基于时间戳/年限自动删除过时的 DNS 条目),并且动态 DNS 用于为 Azure NetApp 文件卷创建 DNS 记录,则清理程序进程可能会意外删除卷的记录。 此删除操作可能会导致基于名称的查询发生服务中断。 在此问题得到解决之前,如果启用了 DNS 清理,请手动为 Azure NetApp 文件卷创建 DNS A/AAAA 和 PTR 条目。 Azure NetApp 文件不会在任何条件下删除 PTR 记录。

后续步骤