Я почти уверен, что обнаружил ошибку, но я пытаюсь разобраться в ней и, возможно, проверить работоспособность.

Сценарий

Политика, в которой если запрос ищет конкретную запись 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

QRP с EQ для клиентской подсети

• Политика разрешения запросов MyQRP со следующей конфигурацией:
  • Условие = And
  • Содержание = TesterScope
  • Критерии:
    • FQDN = EQ,testme.example.com.
    • ClientSubnet = EQ,MySubnet

Это даст ожидаемые результаты, а именно:

• Если поступает запрос на testme.example.com с IP внутри MySubnet (должен соответствовать), он вернет (и разрешит) CNAME запись, хотя CNAME должен быть разрешен в области действия по умолчанию (в частности, QRP должен соответствовать только тогда, когда FQDN является testme.example.com не для testOther.example.com). Следовательно, результат 10.11.11.11, что правильно.
• Если поступает запрос на testme.example.com с IP снаружи MySubnet (не должно совпадать), он решает 10.1.2.3 как и ожидалось.

QRP с NE для клиентской подсети

• Политика разрешения запросов 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-только поведение является правильным, потому что, как упоминалось ранее, цель 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,$myCommonFqdn" -ClientSubnet "EQ,$mySubnetName" -Action REPLACE

Это должно создать воспроизводимый сценарий в вашей среде (при необходимости измените переменные). Оттуда вы можете использовать nslookup или dig по мере необходимости для проверки результатов. Обратите внимание, что вы должны проверять только один DC, к которому это применяется, если вы находитесь в среде AD. (политики / подсети не реплицируются).

Обновление - среда, 24 мая

Я веду дело с Microsoft по этой проблеме. Они заявляют, что не могут его воспроизвести.

Кто-нибудь готов попробовать это?

Обновление - ср 26 июл.

Microsoft может воспроизвести проблему после неоднократных демонстраций. Я жду более глубокого ответа от внутренней команды.