Tenho quase certeza de que descobri um bug, mas estou tentando entender e talvez receber um teste de sanidade.
Cenário
Uma política em que se a solicitação estiver procurando por um registro específico AND o IP do cliente não estiver em uma sub-rede específica, a política corresponderá e resultará em um registro CNAME , cuja meta não é coberta pela política e não existe em um escopo .
Exemplo:
- Zona =
example.com
- Registros no escopo padrão
example.com :
-
testme IN A 10.1.2.3
-
testOther IN A 10.11.11.11
- Escopo da zona =
TesterScope
- Grave em
TesterScope :
-
testme IN CNAME testOther.example.com.
- A sub-rede do cliente
MySubnet contém 10.8.8.0/24
QRP com EQ para a sub-rede do cliente
- Política de resolução de consultas
MyQRP com a seguinte configuração:
- Condição =
And
- Conteúdo =
TesterScope
- Critérios:
- FQDN =
EQ,testme.example.com.
- ClientSubnet =
EQ,MySubnet
Isso produzirá os resultados esperados, isto é:
- Se uma solicitação chegar por
testme.example.com de um IP em MySubnet ( deve corresponder ), ela retornará (e resolverá) corretamente o registro CNAME , mesmo que o CNAME deve ser resolvido no escopo padrão (o QRP especificamente deve corresponder apenas quando FQDN é testme.example.com não para testOther.example.com ). Portanto, o resultado é 10.11.11.11 , o que é correto .
- Se uma solicitação chegar por
testme.example.com de um IP fora de MySubnet ( não deve corresponder a ), será resolvida como 10.1.2.3 conforme o esperado .
QRP com NE para a sub-rede do cliente
- Política de resolução de consultas
MyQRP com a seguinte configuração:
- Condição =
And
- Conteúdo =
TesterScope
- Critérios:
- FQDN =
EQ,testme.example.com.
- ClientSubnet =
NE,MySubnet < - alterar aqui
Isso produzirá resultados inesperados:
- Se uma solicitação chegar por
testme.example.com de um IP fora de MySubnet ( deve corresponder ), ela retornará corretamente o registro CNAME , mas não poderá resolvê-lo. Testes adicionais revelaram que se o destino do CNAME também existir dentro do escopo da zona, ele resolverá , mas ele não deveria estar fazendo isso porque não há QRP que corresponde aos pedidos desse destino para que as consultas usem o escopo.
- Se uma solicitação chegar por
testme.example.com de um IP dentro de MySubnet ( não deve corresponder a ), será resolvida como 10.1.2.3 conforme o esperado .
Notas adicionais
- Os critérios
ClientSubnet podem conter os operadores EQ e NE em um (como EQ,ThisSubnet;NE,ThatSubnet ). O comportamento acontece sempre que o operador NE é incluído.
- Estou ciente de que essas resoluções
CNAME estão sendo feitas internamente no servidor DNS; o cliente não está recebendo o CNAME e, em seguida, resolvendo-o em uma solicitação diferente.
- Eu afirmo que o comportamento
EQ -only está correto, porque, como mencionado anteriormente, o destino do CNAME não possui o QRP que deve fazer com que o escopo da zona seja usado. Além disso, se um cliente solicitar diretamente o destino de CNAME , ele não usará a regra, portanto, considero que os resultados devem ser consistentes entre a resolução CNAME interna e externa.
- Mesmo se minhas contenções acima estiverem incorretas, o resultado da resolução
CNAME interna ainda será inconsistente com ele mesmo (resultados diferentes com EQ vs NE ).
- Se o registro no escopo da zona for um
A em vez de um CNAME (não requer resolução interna), tudo funcionará como planejado (isso é uma solução possível, mas, na minha opinião, indesejável).
PowerShell para demonstrar
(Eu fiz meus próprios testes, mas não diretamente com este código, deixe-me saber se ele está quebrado)
$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
Isso deve criar um cenário reproduzível em seu ambiente (altere as variáveis conforme necessário). De lá, você pode usar nslookup ou dig conforme necessário para verificar os resultados. Observe que você deve verificar apenas o DC único ao qual isso é aplicado se você estiver em um ambiente do AD (as políticas / sub-redes não são replicadas).
Atualização - qua 24 de maio
Eu tenho um caso aberto com a Microsoft para esse problema. Eles afirmam que não podem reproduzi-lo.
Alguém aí disposto a experimentar?
Atualização - qua 26 jul
A Microsoft consegue reproduzir o problema depois de repetidas demonstrações. Estou aguardando uma resposta mais profunda da equipe interna.