☰

设想

tag-icon • tag-icon domain-name-system active-directory powershell windows-server-2016 dns-policies
设想

我确信我已经发现了一个错误，但我正在尝试理解它，并可能进行健全性检查。

设想

一项政策如果请求正在寻找特定记录，而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

EQ客户端子网的QRP

  • 查询解析策略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它按预期解决。

NE客户端子网的QRP

  • 查询解析策略MyQRP具有以下配置：
    • 条件 =And
    • 内容 =TesterScope
    • 标准：
      • FQDN =EQ,testme.example.com.
      • 客户端子网 =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仍然是不一致的与自身EQ（与vs 的结果不同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 日（周三）

我已经就此问题向微软提交了案例。他们声称无法重现该问题。

有谁愿意尝试一下吗？

更新——7 月 26 日（周三）

经过反复演示，微软已经能够重现该问题。我正在等待内部团队的进一步回应。

答案1

预期行为是：对于 CNAME/DNAME/ADDITIONAL SECTIONS • 对于链式响应的每个部分，必须重新应用策略。这些策略的标准将与原始查询中的值（例如 TimeOfDay、客户端子网等）进行匹配，QTYPE 和 FQDN 除外。• 如果链中使用的任何策略导致 DENY/IGNORE，DNS 服务器必须将部分响应发送给客户端（如果可用）。Deny/Ignore 仅适用于该 FQDN 或区域。

我认为结果是预期的。

Kumar Ashutosh [我设计了 DNS 服务器策略]

答案2

以下是我与微软的案件进展情况。

最终，它被内部开发人员（开发人员就此问题发布了答案）所接受，因此官方回应是“这就是它的设计方式”。

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

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

相关内容