我相当肯定我发现了一个错误，但是我正在试着理解它，也许会得到一个理智的检查。

脚本

一个策略， 如果请求正在查找特定的loggingAND并且客户端IP不在特定的子网中，则策略匹配并生成一个CNAMElogging，其目标不在策略中，并且不在策略中 。

例：

• Zone = example.com
• example.comlogging默认范围：
  • testme IN A 10.1.2.3
  • testOther IN A 10.11.11.11
• 区域范围= TesterScope
• logging在TesterScope ：
  • testme IN CNAME testOther.example.com.
• 客户端子网MySubnet包含10.8.8.0/24

带EQ的客户端子网QRP

• 使用以下configuration查询parsing策略MyQRP ：
  • 条件= And
  • 内容= TesterScope
  • 标准：
    • FQDN = EQ,testme.example.com.
    • ClientSubnet = EQ,MySubnet

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

• 如果来自testme.example.com中的IP的MySubnet （ 应该匹配 ），即使必须在默认范围内parsingCNAME ，它也会正确地返回（并parsing） CNAMElogging（QRP专门只应该当FQDN是testme.example.com不匹配testOther.example.com ）。 所以结果是10.11.11.11 ，这是正确的 。
• 如果来自testme.example.com之外的IP的MySubnet （ 不应该匹配 ）， 它将按照预期parsing为10.1.2.3 。

QRP与客户子网的NE

• 使用以下configuration查询parsing策略MyQRP ：
  • 条件= And
  • 内容= TesterScope
  • 标准：
    • FQDN = EQ,testme.example.com.
    • ClientSubnet = NE,MySubnet < – 在这里改变

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

• 关于IPv6上DNS的决定
• 不要自动将所有子域包含在DNSMasq地址中
• 服务器找不到XXX.in-addr.arpa：NXDOMAIN
• 私人DNS区域parsing私人子域名，并转发到公有名称服务器的现有公共子域名
• 从MXToolBox反向DNS不是一个有效的主机名错误

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

---

补充笔记

• ClientSubnet标准可以同时包含EQ和NE操作符（如EQ,ThisSubnet;NE,ThatSubnet ）。 networking运营商随时都会发生这种情况。
• 我知道这些CNAME解决scheme是在DNS服务器上内部完成的; 客户端没有收到CNAME ，然后在不同的请求中parsing它。
• 我认为只有EQ行为是正确的，因为如前所述， CNAME的目标没有应该导致区域范围被使用的QRP。 此外，如果客户端直接请求CNAME的目标，它不会使用规则，所以我觉得结果应该是内部和外部CNAMEparsing之间的一致。
• 即使我上面的争议是不正确的，内部CNAMEparsing的结果仍然与自身不一致（ EQ与NE结果不同）。
• 如果区域范围内的logging是Alogging而不是CNAME （不需要内部parsing），那么一切都按计划运行（这是可能的，但在我看来是不理想的解决方法）。

---

PowerShell来演示

（我做了我自己的testing，但不是直接使用这个代码，让我知道它是否坏了）

 $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 

这应该在您的环境中创build一个可重复的scheme（根据需要更改variables）。 从那里你可以使用nslookup或根据需要dig检查结果。 注意，如果您在AD环境中 （策略/子网不会被复制） ，则只能针对应用于此的单个DC进行检查 。

更新 – 5月24日星期三

对于这个问题，我有一个与微软合作的案例。 他们声称他们不能复制它。

有谁愿意试试这个吗？

更新 – 7月26日

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