domain-name-system – 如果查询解析策略包含客户端子网的网元操作符,则DNS策略无法正确解析区域范围内的CNAME

我很确定我发现了一个错误,但我正试图理解它,也许会得到一个完整性检查.

脚本

策略,如果请求正在查找特定记录且客户端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日星期三

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

解决方法

预期的行为是:
对于CNAME / DNAME /附加部分
•对于链式响应的每个部分,必须重新应用策略.这些策略的标准将与原始查询中的值(例如,TimeOfDay,客户端子网等)匹配,但QTYPE和FQDN除外.
•如果链中使用的任何策略导致DENY / IGNORE,则DNS服务器必须将部分响应发送到客户端(如果可用).拒绝/忽略仅适用于该FQDN或区域.

我认为结果是预期的.

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

相关文章

操作步骤 1、进入elasticsearch的plugin,进入ik。进入config。 2、在config下面建立以.dic为后缀的字典...
lengend data数据中若存在&#39;&#39;,则表示换行,用&#39;&#39;切割。
代码实现 option = { backgroundColor: &amp;#39;#080b30&amp;#39;, tooltip: { trigger: &...
问题原因 原因在于直接在js中取的变量并复制给var变量。 于是就变成这样。 解决办法 var data = &#...
前言 最近做了一个调查问卷导出的功能,需求是将维护的题目,答案,导出成word,参考了几种方案之后,选...
对于很多人来说,用字符编码都是熟能生巧,而不清楚为什么是那样的字符编码,所以我在这列了一个表,翻...