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

Сценарий

Политика, в которой , если запрос ищет конкретную запись И IP-адрес клиента не находится в определенной подсети, политика соответствует и приводит к запись CNAME , цель которой не охвачена политикой и не существует в области .

Пример:

• Zone = example.com
• Записи в example.com область по умолчанию:
  • testme IN A 10.1.2.3
  • testOther IN A 10.11.11.11
• Zone Scope = TesterScope
• Запись в TesterScope :
  • testme IN CNAME testOther.example.com.
• Клиентская подсеть MySubnet содержит 10.8.8.0/24

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

• ] Политика разрешения запросов MyQRP со следующей конфигурацией:
  • Условие = И
  • Содержимое = 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 ( не должен совпадать с ),
  • Условие = И
  • Содержимое = TesterScope
  • Критерии:
    • FQDN = EQ, testme.example.com.
    • ClientSubnet = NE, MySubnet <- изменить здесь

Это приведет к неожиданным результатам:

• Если приходит запрос in для 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, который должен вызывать использование области видимости зоны. Дополнительно, s broken)

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