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

сценарий

Политика, где, если запрос ищет конкретную запись 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 может воспроизвести проблему после повторных демонстраций. Я ожидаю более глубокого ответа от внутренней команды.