我相當確定我已經發現了一個錯誤，但我正在嘗試理解它，並且可能會進行完整性檢查。

設想

一種策略，如果請求正在查找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

這將產生預期的結果，即：

• 如果請求來自( should matchtestme.example.com )內的 IP ，它將正確返回 (並解析)記錄，即使必須在預設範圍內解析 (QRP 特別應該只在is not for時匹配)。因此，結果是**，這是正確的**。MySubnet``CNAME``CNAME``FQDN``testme.example.com``testOther.example.com10.11.11.11
• testme.example.com如果來自外部 IP的請求MySubnet（不應該匹配），它會**按預期****解析10.1.2.3**為。

NE用於客戶端子網的QRP

• MyQRP具有以下配置的

查詢解析策略：

• 條件 =And

• 內容 =TesterScope

• 標準：

  • FQDN =EQ,testme.example.com.
  • ClientSubnet = 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日星期三

對於這個問題，我有一個與 Microsoft 合作的案例。他們聲稱他們無法複製它。

有人願意嘗試一下嗎？

更新——7月26日星期三

經過反复展示，微軟能夠重現該問題。我正在等待內部團隊更深入的回應。

所以，這就是我在微軟的案例。

最終，它在內部進入了開發人員（他就這個問題發布了一個答案），所以官方的回應是“這就是它的設計方式”。

我個人對這個答案一點也不滿意，因為這種行為沒有記錄在案，也沒有直覺的意義，但它確實存在。

有人告訴我，要進一步解決這個問題，我們必須開一個 Premier 支持案例（我們沒有 Premier 支持）。鑑於這需要幾個月的時間，而且我的公司不再需要此功能，因此不會發生這種情況。

預期的行為是： 對於 CNAME/DNAME/ADDITIONAL SECTIONS • 對於鍊式響應的每個部分，必須重新應用策略。這些策略的標準將與原始查詢中的值（例如 TimeOfDay、客戶端子網等）匹配，QTYPE 和 FQDN 除外。• 如果鏈中使用的任何策略導致拒絕/忽略，DNS 伺服器必須將部分響應發送給客戶端（如果可用）。拒絕/忽略僅適用於該 FQDN 或區域。

我認為結果是預期的。

庫馬爾·阿舒托什

$$ I designed DNS Server Policies $$

引用自：https://serverfault.com/questions/849132