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. 我很确定我发现了一个错误,但我正试图理解它,也许会得到一个完整性检查.

脚本

策略,如果请求正在查找特定记录且客户端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 $mysubnetCIDRAdd-DnsServerZonescope -Zonename $myZone -name $myScopeAdd-DnsServerResourceRecord -Zonename $myZone -name $commonname -A -IPv4Address $commonValueAdd-DnsServerResourceRecord -Zonename $myZone -name $othername -A -IPv4Address $otherValueAdd-DnsServerResourceRecord -Zonename $myZone -Zonescope $myScope -name $commonname -Cname -HostnameAlias $myOtherFqdn# Add the policy with EQ that works correctlyAdd-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服务器策略]

总结

以上是内存溢出为你收集整理的domain-name-system – 如果查询解析策略包含客户端子网的网元 *** 作符,则DNS策略无法正确解析区域范围内的CNAME全部内容，希望文章能够帮你解决domain-name-system – 如果查询解析策略包含客户端子网的网元 *** 作符,则DNS策略无法正确解析区域范围内的CNAME所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。