Le politiche DNS non risolvono correttamente i CNAME in ambiti di zona se la politica di risoluzione delle query include l'operatore NE per le sottoreti client

Sono abbastanza sicuro di aver scoperto un bug, ma sto cercando di farlo e forse get un controllo di sanità.

Scenario

Una politica in cui se la richiesta sta cercando un record specifico AND il client IP non è in una particolare substring, il criterio corrisponde e genera un record CNAME il cui target non è coperto dalla politica e non esiste in un ambito .

  • Spazi di stoccaggio Linee guida dirette
  • rm su una directory con milioni di file
  • Gestione Active Directory con bassi diritti utente
  • Come rilevare se c'è un file aggiunto in una cartella in Windows?
  • Come get il nome di partizione fisica da iSCSI dettagli su Windows?
  • Controllo della salute su .NET 4.5 installazione
  • Esempio:

    • Zona = example.com
    • Records nell'applicazione predefinita example.com :
      • testme IN A 10.1.2.3
      • testOther IN A 10.11.11.11
    • Campo di applicazione = TesterScope
    • Record in TesterScope :
      • testme IN CNAME testOther.example.com.
    • La substring client MySubnet contiene 10.8.8.0/24

    QRP con EQ per la substring client

    • Query Policy di risoluzione MyQRP con le seguenti configurazioni:
      • Condizione = And
      • Contenuto = TesterScope
      • criteri:
        • FQDN = EQ,testme.example.com.
        • ClientSubnet = EQ,MySubnet

    Ciò produrrà i risultati attesi, vale a dire:

    • Se viene presentata una richiesta per testme.example.com da un IP all'interno di MySubnet ( dovrebbe corrispondere ), verrà restituito correttamente (e risolve) il record CNAME , anche se il CNAME deve essere risolto nell'ambito predefinito (il QRP dovrebbe specificatamente solo corrisponde quando FQDN è testme.example.com per testOther.example.com ). Pertanto, il risultato è 10.11.11.11 , che è corretto .
    • Se viene fornita una richiesta per testme.example.com da un IP al di fuori di MySubnet ( non dovrebbe corrispondere ), risolve 10.1.2.3 come previsto .

    QRP con NE per la substring client

    • Query Policy di risoluzione MyQRP con le seguenti configurazioni:
      • Condizione = And
      • Contenuto = TesterScope
      • criteri:
        • FQDN = EQ,testme.example.com.
        • ClientSubnet = NE,MySubnet <- cambia qui

    Ciò produce risultati imprevisti:

    • Se viene presentata una richiesta per testme.example.com da un IP al di fuori di MySubnet ( dovrebbe corrispondere ), verrà restituito correttamente il record CNAME , ma non è in grado di risolverlo. Ulteriori verifiche hanno rivelato che se l'objective del CNAME esiste anche nell'ambito della zona, esso risolverà , ma non dovrebbe farlo perché non esiste QRP che corrisponda alle richieste di tale target per fare in modo che le query utilizzino l'ambito.
    • Se viene fornita una richiesta per testme.example.com da un IP all'interno di MySubnet ( non dovrebbe corrispondere ), risolve 10.1.2.3 come previsto .

    Note aggiuntive

    • I criteri ClientSubnet possono contenere sia operatori EQ che NE in uno (come EQ,ThisSubnet;NE,ThatSubnet ). Il comportmento si verifica each NE operatore NE sia incluso.
    • Sono consapevole che queste risoluzioni CNAME vengono eseguite internamente sul server DNS; il client non riceve il CNAME e lo risolve in una richiesta diversa.
    • Io sostengo che il comportmento EQ sia corretto, perché come precedentemente menzionato, l'objective del CNAME non ha QRP che dovrebbe causare l'utilizzo della zona. Inoltre, se un client wheresse richiedere direttamente l'objective del CNAME , non utilizzerà la regola, quindi ritengo che i risultati siano coerenti tra la risoluzione CNAME interna ed esterna.
    • Anche se le mie controversie sopra non sono corrette, il risultato della risoluzione CNAME interna è ancora incoerente con se stesso (risultati diversi con EQ vs NE ).
    • Se il record nell'ambito della zona è un record A invece di un CNAME (non richiede una risoluzione interna), tutto funziona come previsto (è ansible, ma a mio parere, una soluzione alternativa indesiderata).

    PowerShell per dimostrare

    (Ho fatto i miei test, ma non direttamente con questo codice, fathemes sapere se è rotta)

     $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 

    Questo dovrebbe creare uno scenario riproducibile nell'ambiente (modificare le variables se necessario). Da lì è ansible utilizzare nslookup o dig come necessario per controllare i risultati. Si noti che è necessario controllare solo la singola cifra DC per applicarla se si è in un ambiente AD (le politiche / sottoreti non vengono replicate).

    Aggiornamento – mer 24 mag

    Ho un caso aperto con Microsoft per questo problema. Essi affermano di non poterlo riprodurlo.

    Qualcuno là fuori pronto a dare una prova?

    Aggiornamento – mer 26 lug

    Microsoft è in grado di riprodurre il problema, dopo dimostrazioni ripetute. Sto aspettando una risposta più profonda dalla squadra interna.

    One Solution collect form web for “Le politiche DNS non risolvono correttamente i CNAME in ambiti di zona se la politica di risoluzione delle query include l'operatore NE per le sottoreti client”

    Il comportmento previsto è: Per le sezioni CNAME / DNAME / ADDITIONAL • Per each parte di una risposta incatenata, le politiche devono essere applicate di nuovo. I criteri di questa politica verranno confrontati con i valori nella query originale (ad esempio TimeOfDay, substring client ecc.) Eccetto QTYPE e FQDN. • Se una qualsiasi delle politiche utilizzate nella catena provoca un DENY / IGNORE, il server DNS deve submit la risposta parziale al client se disponibile. Il Deny / Ignore si applicherà solo per quel FQDN o per la zona.

    Penso che i risultati siano attesi.

    Kumar Ashutosh [ho progettato le norme del server DNS]

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.