バグを発見したことは間違いありませんが、それを理解し、サニティチェックを取得しようとしています。
リクエストが特定のレコードを探している場合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
を使用したQRPMyQRP
:And
TesterScope
EQ,testme.example.com.
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
を使用したQRPMyQRP
:And
TesterScope
EQ,testme.example.com.
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
レコードである場合(内部解決は必要ありません)、すべてが計画どおりに機能します(これは可能ですが、私の意見では望ましくない回避策です)。(私は独自のテストを行いましたが、このコードを直接使用していません。壊れているかどうかを知らせてください)
$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)に対してのみチェックする必要があることに注意してください(ポリシー/サブネットは複製されません)。
私はこの問題についてマイクロソフトに訴訟を起こしています。彼らはそれを再現できないと主張している。
これを試してみてくれる人はいますか?
マイクロソフトは、デモを繰り返した後、問題を再現することができます。社内チームからのより深い回答を待っています。
それで、これが私のケースがマイクロソフトでどのように起こったかです。
最終的には、開発者(この質問に対する回答を投稿した)に内部的に浸透したため、公式の回答は「これが設計された方法です」です。
この動作は文書化されておらず、直感的に意味がないため、私は個人的にその答えにまったく満足していませんが、それはあります。
この問題をさらに進めるには、プレミアサポートケースを開く必要があると言われました(プレミアサポートはありません)。これには何ヶ月もかかり、私の会社はこの機能を必要としなくなったことを考えると、それは起こりません。
予想される動作は次のとおりです。CNAME/ DNAME/ADDITIONAL SECTIONSの場合•連鎖応答の各部分について、ポリシーを再度適用する必要があります。これらのポリシーの基準は、QTYPEとFQDNを除いて、元のクエリの値(TimeOfDay、クライアントサブネットなど)と照合されます。 •チェーンで使用されているポリシーのいずれかがDENY/IGNOREになる場合、DNSサーバーは、可能な場合はクライアントに部分的な応答を送信する必要があります。拒否/無視は、そのFQDNまたはゾーンにのみ適用されます。
結果は期待できると思います。
Kumar Ashutosh [DNSサーバーポリシーを設計しました]