web-dev-qa-db-ja.com

クエリ解決ポリシーにクライアントサブネットのNE演算子が含まれている場合、DNSポリシーはゾーンスコープ内のCNAMEを適切に解決しません

バグを発見したことは間違いありませんが、それを理解し、サニティチェックを取得しようとしています。

シナリオ

リクエストが特定のレコードを探している場合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.
      • 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：
    • 条件= And
    • コンテンツ= TesterScope
    • 基準：
      • FQDN = EQ,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演算子の両方を1つに含めることができます（EQ,ThisSubnet;NE,ThatSubnetなど）。この動作は、NE演算子が含まれている場合はいつでも発生します。
  • これらのCNAME解決がDNSサーバーで内部的に行われていることを認識しています。クライアントはnotCNAMEを受信して​​から、別のリクエストでそれを解決しています。
  • 前述のように、EQのターゲットにはゾーンスコープが使用される原因となるQRPがないため、CNAMEのみの動作は正しいと私は主張します。さらに、クライアントが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,$myCommonFqdn" -ClientSubnet "EQ,$mySubnetName" -Action REPLACE

これにより、環境内で再現可能なシナリオが作成されます（必要に応じて変数を変更してください）。そこから、必要に応じてnslookupまたはDigを使用して結果を確認できます。 AD環境にいる場合に適用される単一のDC）に対してのみチェックする必要があることに注意してください（ポリシー/サブネットは複製されません）。

更新-5月24日水曜日

私はこの問題についてマイクロソフトに訴訟を起こしています。彼らはそれを再現できないと主張している。

これを試してみてくれる人はいますか？

更新-7月26日水曜日

マイクロソフトは、デモを繰り返した後、問題を再現することができます。社内チームからのより深い回答を待っています。

domain-name-systemactive-directorypowershellwindows-server-2016dns-policies
5
briantist

それで、これが私のケースがマイクロソフトでどのように起こったかです。

最終的には、開発者（この質問に対する回答を投稿した）に内部的に浸透したため、公式の回答は「これが設計された方法です」です。

この動作は文書化されておらず、直感的に意味がないため、私は個人的にその答えにまったく満足していませんが、それはあります。

この問題をさらに進めるには、プレミアサポートケースを開く必要があると言われました（プレミアサポートはありません）。これには何ヶ月もかかり、私の会社はこの機能を必要としなくなったことを考えると、それは起こりません。

0
briantist

予想される動作は次のとおりです。CNAME/ DNAME/ADDITIONAL SECTIONSの場合•連鎖応答の各部分について、ポリシーを再度適用する必要があります。これらのポリシーの基準は、QTYPEとFQDNを除いて、元のクエリの値（TimeOfDay、クライアントサブネットなど）と照合されます。 •チェーンで使用されているポリシーのいずれかがDENY/IGNOREになる場合、DNSサーバーは、可能な場合はクライアントに部分的な応答を送信する必要があります。拒否/無視は、そのFQDNまたはゾーンにのみ適用されます。

結果は期待できると思います。

Kumar Ashutosh [DNSサーバーポリシーを設計しました]

1
Ashu