我可以在 Azure 网络安全组中为 IP 地址添加入站/出站规则，但是如何为域名（URL）创建该规则？
答案1
原因如下：
根据设计： 许多安全系统根本不支持使用 FQDN 创建 ACL。并且您只允许使用 IP 地址（范围）信息创建 ACL。
警告：任何支持包含 FQDN 的 ACL 的系统，经过仔细检查后，很可能实际上无法提供您直观期望的安全性、灵活性和/或行为级别。
一般来说，在 ACL 中使用 FQDN 的问题根源于以下基本事实：
您的（安全）系统只能看到 IP 地址作为网络流量的源和目的地。
要使用 FQDN，您的安全系统需要执行反向 DNS 查找每当包含新的和未知的 IP 地址的流量到达时，确定该特定 IP 地址是否解析为访问控制列表中的 FQDN，或者在应用访问策略之前，需要将 FQDN 解析为 IP 地址。
实时反向 DNS 查询
实时反向查找的问题在于，除了慢的，IP 地址的所有者可以设置反向 DNS 记录上的任何主机名，包括来自他们不拥有的域名，特别是您自己的域名......所以这既慢又不可靠也不安全。
例如，渗透测试人员/攻击者的一个标准技巧是在something.contoso.com.评估 Contoso 的安全性时设置自己的 PTR 记录。然后，他们将被纳入任何信任的安全策略中 *.contoso.com...
解析 FQDN
或者，系统可以在后台/管理工具中（自动）将提供的 FQDN 转换为 IP 地址，并有效地将您的策略应用于 FQDN 解析到的 IP 地址。这将防止缓慢、不可靠和不安全的反向查找，但导致一系列不同的问题：
许多系统在应用规则集时不会显示 FQFN 解析到哪些 IP 地址。
显示 IP 地址的系统通常不再显示原始 FQDN。
或者，当他们确实显示 FQDN 时，他们通常会显示对 IP 地址进行反向 DNS 查找的结果，并且您会发现 PTR 通常与初始正向 DNS 记录不一致，这肯定会造成混淆。域所有者可以随时更改与 FQDN 关联的 IP 地址，以及新 IP 地址将如何以及何时替换策略中的旧 IP 地址？
许多系统仅解析一次 FQDN从那时起将“永远”使用已解析的 IP 地址。我不知道有任何系统能够遵守 DNS 记录的 TTL 等规定，或者有任何其他方法定期检查 FQDN 是否仍解析为相同的 IP 地址，如果更改，将更新有效 ACL 中使用的 IP。FQDN 甚至可以解析为多个 IP 地址。IPv4 和 IPv6 均可，并且每种都有多个。
许多系统需要针对 IPv4 和 IPv6 制定单独的规则和/或不以预期/一致的方式支持循环 DNS 记录。FQDN 可能会根据执行解析的客户端 IP 地址解析为不同的（范围）IP 地址（任播/地理 DNS），因此基于 FQDN 的策略不可能匹配所有实际 IP 地址...