如果查询解析策略包含客户端子网的 NE 运营商，则 DNS 策略无法正确解析区域范围中的 CNAME

Question

我相当确定我已经发现了一个错误，但我正在尝试理解它并进行完整性检查。

设想

一种策略，如果请求正在查找AND客户端 IP 不在特定子网中的特定CNAME记录，则该策略匹配并生成一条记录，该记录的目标不在策略涵盖范围内且不存在于范围内。

例子：

• 区域 = example.com
• example.com默认范围内的记录：
  • testme IN A 10.1.2.3
  • testOther IN A 10.11.11.11
• 区域范围 = TesterScope
• 录入TesterScope：
  • testme IN CNAME testOther.example.com.
• 客户端子网MySubnet包含10.8.8.0/24

QRP 与EQ客户端子网

• MyQRP使用以下配置查询解析策略：
  • 条件 = And
  • 内容 = TesterScope
  • 标准：
    • FQDN = EQ,testme.example.com.
    • 客户端子网 = EQ,MySubnet

这将产生预期的结果，即：

• 如果请求进入testme.example.com从IP内MySubnet（应匹配），它会返回正确（和解决）的CNAME记录，即使CNAME必须在默认范围（该QRP特别是当应该只匹配来解决FQDN是testme.example.com不是testOther.example.com）。因此，结果是10.11.11.11，这是正确的。
• 如果请求来自testme.example.com外部 IP MySubnet（不应该匹配），它会10.1.2.3按预期解析为。

QRP 与NE客户端子网

• MyQRP使用以下配置查询解析策略：
  • 条件 = And
  • 内容 = TesterScope
  • 标准：
    • FQDN = EQ,testme.example.com.
    • ClientSubnet = NE,MySubnet <- 在此处更改

这会产生意想不到的结果：

• 如果请求来自testme.example.com外部 IP MySubnet（应该匹配），它将正确返回CNAME记录，但无法解析它。进一步的测试表明，如果 的目标CNAME也存在于区域范围内，它将解析，但它不应该这样做，因为没有与该目标的请求匹配的 QRP 使查询使用范围。
• 如果请求来自testme.example.com内部 IP MySubnet（不应该匹配），它会10.1.2.3按预期解析为。

---

补充说明

• 该ClientSubnet标准可以包含EQ和NE运营商在一个（像EQ,ThisSubnet;NE,ThatSubnet）。该行为在NE包含操作符的任何时候都会发生。
• 我知道这些CNAME解析是在 DNS 服务器内部完成的；客户端没有收到CNAME，然后在不同的请求中解析它。
• 我认为EQ-only 行为是正确的，因为如前所述，目标CNAME没有应该导致使用区域范围的 QRP。另外，如果客户端直接请求 的目标CNAME，它不会使用规则，所以我觉得内部和外部CNAME解析的结果应该是一致的。
• 即使我上面的论点是不正确的，内部CNAME解析的结果仍然与自身不一致（与EQvs不同的结果NE）。
• 如果区域范围内的A记录是记录而不是记录CNAME（不需要内部解析），那么一切都会按计划进行（这是可能的，但在我看来是不受欢迎的解决方法）。

---

PowerShell 演示

（我已经完成了自己的测试，但没有直接使用此代码，如果它坏了，请告诉我）

$myZone = 'example.com'
$myScope = 'MyScope'
$mySubnetName = 'MySubnet'
$mySubnetCIDR = '10.8.8.0/24'
$commonName = 'testme'
$commonValue = '10.1.2.3'
$otherName = 'testOther'
$otherValue = '10.11.11.11'
$myPolicy = 'MyQRP'

$myCommonFqdn = "${commonName}.${myZone}."
$myOtherFqdn = "${otherName}.${myZone}."

$myDC = 'My2016DC'

Import-Module DnsServer

$PSDefaultParameterValues = @{
    '*-DnsServer*:ComputerName' = $myDC
}

Add-DnsServerClientSubnet -Name $mySubnetName -IPv4Subnet $mySubnetCIDR

Add-DnsServerZoneScope -ZoneName $myZone -Name $myScope

Add-DnsServerResourceRecord -ZoneName $myZone -Name $commonName -A -IPv4Address $commonValue
Add-DnsServerResourceRecord -ZoneName $myZone -Name $otherName -A -IPv4Address $otherValue

Add-DnsServerResourceRecord -ZoneName $myZone -ZoneScope $myScope -Name $commonName -CName -HostNameAlias $myOtherFqdn

# Add the policy with EQ that works correctly
Add-DnsServerQueryResolutionPolicy -ZoneName $myZone -ZoneScope $myScope -Name $myPolicy -Fqdn "EQ,$myCommonFqdn" -ClientSubnet "EQ,$mySubnetName"

# Uncomment these to change it around

# Use NE instead of EQ
# Set-DnsServerQueryResolutionPolicy -ZoneName $myZone -ZoneScope $myScope -Name $myPolicy -Fqdn "EQ,$myCommonFqdn" -ClientSubnet "NE,$mySubnetName" -Action REPLACE
# Set it back to using EQ
# Set-DnsServerQueryResolutionPolicy -ZoneName $myZone -ZoneScope $myScope -Name $myPolicy -Fqdn "EQ,$myCommonFqdn" -ClientSubnet "EQ,$mySubnetName" -Action REPLACE

这应该会在您的环境中创建一个可重现的场景（根据需要更改变量）。从那里您可以使用nslookup或dig根据需要检查结果。请注意，如果您处于 AD 环境中（策略/子网不会被复制），则您必须仅检查应用于此的单个 DC。

更新 - 5 月 24 日星期三

我有一个针对此问题的 Microsoft 案例。他们声称他们无法复制它。

有人愿意尝试一下吗？

更新 - 7 月 26 日，星期三

经过反复演示，Microsoft 能够重现该问题。我正在等待内部团队的更深入的回应。

Answer 1

以下是我与微软的案例。

最终，它在内部传达给了开发人员（开发人员发布了有关此问题的答案），因此官方回应是“这就是它的设计方式”。

我个人对这个答案一点也不满意，因为这种行为没有记录，也没有直观意义，但它确实存在。

我被告知要进一步解决这个问题，我们必须打开高级支持案例（我们没有高级支持）。鉴于这花了好几个月的时间，而且我的公司不再需要此功能，所以这种情况不会发生。