脚本

策略,如果请求正在查找特定记录且客户端IP不在特定子网中,则策略匹配并生成CNAME记录,其目标不在策略范围内且在范围中不存在.

例：

> Zone = 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

带有EQ的QRP客户端子网

>查询解析策略MyQRP,配置如下：

>条件=和
>内容= TesterScope
>标准：

> FQDN = EQ,testme.example.com.
> ClientSubnet = EQ,MySubnet

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

>如果来自MySubnet内的IP的testme.example.com请求(应该匹配),它将正确返回(并解析)CNAME记录,即使必须在默认范围内解析CNAME(QRP特别应该仅当FQDN为testme.example.com时才匹配,不适用于testOther.example.com).因此,结果是10.11.11.11,这是正确的.
>如果来自MySubnet外部IP的testme.example.com请求(不应该匹配),它会按预期解析为10.1.2.3.

带有NE的QRP用于客户端子网

>查询解析策略MyQRP,testme.example.com.
> ClientSubnet = NE,MySubnet< - 在这里更改
这将产生意想不到的结果：

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

补充说明

> ClientSubnet标准可以包含EQ和NE操作符(如EQ,ThisSubnet; NE,ThatSubnet).只要包含NE运算符,就会发生这种情况.
>我知道这些CNAME解析是在DNS服务器内部完成的;客户端没有收到CNAME,然后在另一个请求中解析它.
>我认为仅EQ行为是正确的,因为如前所述,CNAME的目标没有QRP应该导致使用区域范围.此外,如果客户端直接请求CNAME的目标,它将不会使用该规则,因此我认为结果应该在内部和外部CNAME解析之间保持一致.
>即使我上面的争论不正确,内部CNAME解析的结果仍然与自身不一致(EQ与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,$mySubnetName" -Action REPLACE

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

更新 – 5月24日星期三

我有一个与微软就这个问题开放的案例.他们声称他们无法复制它.

有人愿意尝试一下吗？

更新 – 7月26日星期三

经过反复演示,微软能够重现这个问题.我正在等待内部团队的更深入回应.