Två DNS-servrar på en adapter delar inte namnrymder

Att lista två resolvers på en adapter ser ut som ett sätt att skicka en domän till en server och en annan domän till den andra, och ingenting i resolverlistan fungerar så. Windows löser upp efter namn, och beslutet om vilken server som ska tillfrågas kommer från principobjekt i stället för från en ordnad adresslista. Den mentala modellen som måste ersättas är kön: det finns ingen första server för domän A och ingen andra server för domän B. Det finns en regeluppsättning per namnrymd som namnger servrarna uttryckligen, och när dessa regler väl finns slutar adapterlistan att vara intressant.

Myten: två adresser delar två domäner

Tron överlever eftersom den råkar fungera när en server svarar på allt och den andra bara är en reserv. En klient frågar den första servern, den servern vidarebefordrar eller rekurserar, och svaret kommer; ingen märker vilken resolver som egentligen höll zonen. Illusionen brister i det ögonblick de två namnrymderna lever i separata privata zoner utan vidarebefordran mellan sig, eftersom den första servern då svarar auktoritativt att namnet inte finns. Ett negativt svar från den första servern utlöser inte reserven, eftersom klienten fick ett definitivt svar och inte ett fel.

En ordnad lista har inget begrepp om domän, så den kan inte uttrycka avsikten. Det listan egentligen styr är vilken server som frågas först och vilken som provas som nummer två, och båda svaren gäller lika för varje namn.

Vad Windows faktiskt använder för att välja

Tabellen för namnupplösningsprincip matchar ett namn mot konfigurerade namnrymder och väljer servrarna och alternativen för den träffen. Regler kan konfigureras lokalt, levereras av grupprincip eller tillhandahållas av en VPN-profil, och den effektiva principen är en kombination och inte en enda lista. Därför är den första diagnostiken alltid det effektiva tillståndet: en lokalt skapad regel som förlorar mot en hanterad princip ger ett labb som beter sig helt annorlunda än dess konfiguration antyder. Regler matchas också efter specificitet, så en bred namnrymdspost kan överskugga en smal på sätt som är osynliga i en lista över konfigurerade objekt. Att läsa den effektiva ordningen är det enda sättet att se vilken regel som vinner.

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

Det första kommandot listar vad som är konfigurerat på datorn; det andra visar vad klienten faktiskt kommer att tillämpa, inklusive poster som kom från annat håll. Om den effektiva utskriften innehåller hanterade namnrymder är ägaren till den principen rätt plats att begära ändringen på, inte den lokala regellistan. Båda kommandona läser bara tillstånd, så det kostar ingenting att köra dem innan någon har gått med på ändringen.

En regel per namnrymd, behåll objektet

När det effektiva tillståndet är förstått, skapa en regel per namnrymd och behåll objektet som varje kommando returnerar. Visningsnamn är etiketter för människor, och den unika identifieraren i det returnerade objektet är sedan det pålitliga borttagningsobjektet. Skriv båda identifierarna i samma ändringsanteckning som registrerar namnrymderna och resolvrarna, eftersom sessionen som skapade dem inte blir den session som städar.

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

Den inledande punkten markerar en suffixmatchning, så regeln omfattar app.svc.internal.example och allt annat under det. De två adresserna här tillhör det här labbets egen routingplan; en regel skapar inte en zon, installerar inte en väg och auktoriserar inte programmet som till slut ansluter, och den referensen för Add-DnsClientNrptRule dokumenterar exakt vilken parameter som gör vad.

Lägg märke till vad dessa kommandon inte gör: de är maskinövergripande, de är inte begränsade till en VPN-session, och de överlever att fönstret stängs. Ett labb som glömmer detta lämnar princip efter sig när tunneln är borta.

Bevisa att klienten valde servern

Att fråga en specifik server om den känner till ett namn bevisar att servern kan svara, vilket inte är samma påstående som att klienten valde den servern. Testet som betyder något löser ett riktigt namn via klientens vanliga väg och bekräftar sedan vilken resolver som hanterade det, helst medan tunneln som levererar vägen är uppe. Om tunneln är nere pekar en korrekt avgränsad regel fortfarande på en oåtkomlig server, och det är ett routingproblem och inte ett principärende. Testa båda tillstånden så att de kan skiljas åt senare.

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

Håll utkik efter cachade svar från perioden innan reglerna fanns, och efter program som helt kringgår systemets resolver med sin egen krypterade DNS. Sökuffix är ytterligare en separat funktion: en regel kan välja en resolver för ett fullständigt namn utan att lära Windows att expandera ett bart värdnamn till den namnrymden.

Ta bort exakt det du skapade

Städning är där ett labb blir en varnande historia. Att radera varje regel på datorn går snabbt och tar bort principer som någon annan är beroende av, så använd identifierarna som fångades när reglerna skapades, och läs det effektiva tillståndet igen efteråt för att bekräfta att datorn är tillbaka där den började. Om sessionen som skapade dem är borta är ändringsanteckningen den enda plats där identifierarna finns. Det är därför de skrivs ner innan det första kommandot körs, och inte efter.

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

För en utrullning och inte ett labb betyder livstidsfrågan lika mycket som regeln. En VPN-profil kan bära namnrymdsreglerna och välja om de består längre än anslutningen; en regel som består medan resolvern är oåtkomlig låter klienter föredra en död server, och en anslutningsavgränsad regel försvinner när tunneln gör det. Bestäm vilket av dessa beteenden tjänsten behöver, markera vem som äger regeln, och låt uppdelningen av behörighet dokumenteras bredvid profilen i stället för i någons minne av ett labb.