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.

I'm implementing DNS Policies, writing PowerShell scripts for certain tasks, and of course I don't want to schedule these tasks as domain admins; I want to use a least-privileged service account.

The thing is, I can't seem to figure out what's needed, and where. AD includes the DnsAdmins group, but it's not enough.

DNS Policy Components

There are essentially 3 new elements to DNS Policies:

• Zone Scopes
• Client Subnets
• Policies

Zone Scopes are part of the zone itself, so on an AD-integrated zone, they are replicated with the zone.

But Client Subnets and Policies are not stored in AD, so they are not replicated and there's no directory partition for example, where you could check or set permissions.

Example Problem

Trying to create a Client Subnet entry, which works fine with a domain admin account, gives me a cryptic error about checking the internal exception details.

Doing that gives me a WIN32 1011 error:

The configuration registry key could not be opened.

Googling that error is fairly useless, and it never says which registry key it is.

This is with an account that is a normal domain user, but is a member of DnsAdmins and has no other special privileges.

That account can read a DNS Client Subnet just fine. But adding one fails.

For contrast, a domain user that is not a member of DnsAdmins, cannot read the client subnet entry (permission denied).

Code

# Read a Client Subnet
Get-DnsServerClientSubnet -cn MyDC -Name 'My_CS_Entry'

# Add a Client Subnet
Add-DnsServerClientSubnet -cn MyDC -Name 'My_CS_Entry'

So absent any documentation, I'm at a loss as to how to properly delegate permissions for this.

PowerShell web access lets you choose the authentication type. By default, it uses a value of Default, which ends up being Negotiate. I have set up CredSSP to allow logging into the PSWA server itself with CredSSP, so that network authentication works from within the session (avoids a double hop issue, without delegating credentials all over the network).

Anyway, I want CredSSP to be the default option on the sign-in page.

Looking into the configuration options for the PSWA web app in IIS, there are several values that can be set to override the defaults.

One of them is called defaultAuthenticationType which is a string but is set to 0.

This seems like the right setting, but I can't get it to work.

If I inspect the sign in web page I can see that the select box has the following values:

0   Default
1   Basic
2   Negotiate
4   CredSSP
5   Digest
6   Kerberos

3 is missing.

JosefZ found that 3 is NegotiateWithImplicitCredential according to this page, but on Windows PowerShell 5.1.15063.966 for me that name/value is missing from the enum.

If I set defaultAuthenticationType to a number, then the web page defaults to a new option:

7   Admin Specified

I have tried 3 and 4, but neither one works. The login happens using Kerberos, and CredSSP is not used.

If I select CredSSP manually it works as expected.

If I set defaultAuthentcationType to a string like CredSSP, no Admin Specified option appears and it just defaults to Default again, and still Kerberos authentication is used.

Has anyone been able to successfully set this? Web results have been very lacking.

Background

We had an incident where a Windows failover cluster suffered an interruption. A post-mortem showed that the node was "removed" as described in this article.

We've only recently migrated this cluster fully into our VMware environment, and it appears that the event described above may have been the cause of the outage.

The associated VMware KB article about this talks about increasing the Small Rx Buffers and the Rx Ring #1 setting, but cautions that increasing these too much could drastically increase memory overhead on the host.

After an audit of the Network Interface\Packets Received Discarded performance counters for our ~150 Windows VMs, 22 vNICs across 16 guests had some discarded packets.

A small enough amount that I'm not worried about taxing the hosts with additional memory usage, but I want to understand how memory is used for these settings and where the memory comes from.

Questions

1. What is the relationship between number of buffers and ring size?
2. How does one calculate the amount of memory used for given values of these settings?
3. Because these settings are on the NIC itself within the guest OS, I assume they are driver settings. This makes me think that the RAM used might be paged or non-paged pool.
   1. Is this correct?
   2. If so, should I be worried about that?
4. Are there concerns I'm not taking into account here?

We're trying to determine whether there is a drawback to setting these to their maximums on affected VMs, other than VMware host memory usage. If we're increasing risk of pool memory being depleted in the guest for example, we're more inclined to start small.

Some (perhaps all) of these questions may not be specific to VMware or virtualization.

I am trying to deploy a VM from a template. This template has been used dozens of times before; nothing special. The problem is that seemingly out of nowhere when I deploy a VM, it's giving it the same MAC address as an existing powered on VM.

Both VMs are using automatic MAC assignment.

It seems that the usual cause for this is having more than 1 vCenter without giving each one a unique ID. Thing is, we only have 1 vCenter.

I have confirmed in the vCenter database, using the following query, that there are no other conflicts in the cluster:

SELECT TOP 1000 
      [MAC_ADDRESS],
      COUNT([MAC_ADDRESS])
  FROM [VIM_VCDB].[dbo].[VPX_NIC]
  GROUP BY MAC_ADDRESS
  HAVING COUNT([MAC_ADDRESS]) > 1

I keep deleting the newly minted VM and trying to re-deploy it, but it gives out the same MAC every time.

When I create a new VM from scratch, it uses a unique MAC.

I can't find any other instances of something like this online, and I can't figure out how this is possible nor what I can do to fix it. I don't want to start assigning MAC addresses manually.

Update

This has gone from a problem that was repeatable to.. not a problem. I don't know what happened or why, but this originally occurred for me on Friday evening, several times. I was able to repeat it this morning before posting this.

Testing now shows unique MACs being generated; no duplicates.

I have no idea why, I'd still like insight if anyone has ideas. I have a sneaking suspicion that this is going to come back. Ugggh.