I'm fairly sure I've uncovered a bug, but I'm trying to make sense of it and maybe get a sanity check.

Scenario

A policy where if the request is looking for a specific record AND the client IP is not in a particular subnet, the policy matches and results in a CNAME record, the target of which is not covered by the policy and does not exist in a scope.

Example:

• Zone = example.com
• Records in example.com default scope:
  • testme IN A 10.1.2.3
  • testOther IN A 10.11.11.11
• Zone Scope = TesterScope
• Record in TesterScope:
  • testme IN CNAME testOther.example.com.
• Client Subnet MySubnet contains 10.8.8.0/24

QRP with EQ for Client Subnet

• Query Resolution Policy MyQRP with following config:
  • Condition = And
  • Content = TesterScope
  • Criteria:
    • FQDN = EQ,testme.example.com.
    • ClientSubnet = EQ,MySubnet

This will produce the expected results, that is:

• If a request comes in for testme.example.com from an IP within MySubnet (should match), it will correctly return (and resolve) the CNAME record, even though the CNAME must be resolved in the default scope (the QRP specifically should only match when FQDN is testme.example.com not for testOther.example.com). Therefore, the result is 10.11.11.11, which is correct.
• If a request comes in for testme.example.com from an IP outside MySubnet (should not match), it resolves to 10.1.2.3 as expected.

QRP with NE for Client Subnet

• Query Resolution Policy MyQRP with following config:
  • Condition = And
  • Content = TesterScope
  • Criteria:
    • FQDN = EQ,testme.example.com.
    • ClientSubnet = NE,MySubnet <- change here

This will produces unexpected results:

• If a request comes in for testme.example.com from an IP outside MySubnet (should match), it will correctly return the CNAME record, but it is unable to resolve it. Further testing revealed that if the target of the CNAME also exists within the zone scope, it will resolve, but it shouldn't be doing this because there is no QRP that matches requests for that target to make the queries use the scope.
• If a request comes in for testme.example.com from an IP inside MySubnet (should not match), it resolves to 10.1.2.3 as expected.

Additional Notes

• The ClientSubnet criteria can contain both EQ and NE operators in one (like EQ,ThisSubnet;NE,ThatSubnet). The behavior happens anytime the NE operator is included.
• I am aware that these CNAME resolutions are being done internally on the DNS server; the client is not receiving the CNAME and then resolving it in a different request.
• I contend that the EQ-only behavior is correct, because as previously mentioned the target of the CNAME has no QRP that should cause the zone scope to be used. Additionally, if a client were to directly request the target of the CNAME, it will not use the rule, so I feel that the results should be consistent between internal and external CNAME resolution.
• Even if my contentions above are incorrect, the result of the internal CNAME resolution is still inconsistent with itself (different results with EQ vs NE).
• If the record within the zone scope is an A record instead of a CNAME (doesn't require internal resolution) then everything works as planned (this is a possible but in my opinion undesirable workaround).

PowerShell to Demonstrate

(I've done my own tests, but not directly with this code, let me know if it'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

That should create a reproducible scenario in your environment (change the variables as needed). From there you can use nslookup or dig as needed to check the results. Note you must only check against the single DC that this is applied to if you're in an AD environment (the policies/subnets don't get replicated).

Update -- Wed 24 May

I have a case open with Microsoft for this issue. They claim they can not reproduce it.

Anyone out there willing to give this a try?

Update -- Wed 26 Jul

Microsoft is able to reproduce the issue, after repeated demonstrations. I am awaiting a deeper response from the internal team.