Openbare DNS die werkt betekent niet dat Active Directory vindbaar is

De VPN verbindt, de browser opent een openbare site en de laptop kan zich nog steeds niet bij het domein aanmelden. De gebruikelijke conclusie is dat DNS in orde is omdat namen worden opgelost. Dat is het niet, en de reden is dat een browsertest maar één opzoeking uit een keten test die een aan het domein gekoppelde client nodig heeft. Domeinontdekking vraagt eerst om servicerecords, dan om de adressen van de controllers die die records noemen en ten slotte om een route naar de poorten waarop die controllers luisteren. Een openbaar antwoord voldoet aan geen van die stappen.

De mythe: namen worden opgelost, dus DNS is klaar

Dat een openbare site wordt opgelost, zegt alleen dat een of andere resolver één A- of AAAA-query voor een naam in een openbare zone heeft beantwoord. Active Directory gebruikt hetzelfde protocol voor een andere vraag: waar zijn de diensten van het domein en welke controller moet deze client gebruiken. De vraag wordt uitgedrukt als SRV-records onder een zone die naar het domein is genoemd, en een recursieve openbare resolver heeft geen reden ze te bewaren.

Ontbreekt het record, dan geeft de resolver een negatief antwoord, wat een geldig DNS-antwoord is en geen storing. De client valt dan terug op gecachte controllerinformatie als hij die heeft, en dat is precies waarom een desktop urenlang goed kan lijken en na een herstart of wachtwoordwijziging kan falen.

Wat een domeinclient werkelijk vraagt, in volgorde

Voor een domein als corp.example is de algemene locatorquery _ldap._tcp.dc._msdcs.corp.example. De SRV-antwoorden noemen kandidaatcontrollers en hun poorten, en daarna heeft de client adresrecords nodig voor die hostnamen voordat hij een verbinding kan openen. Sitesbewuste ontdekking voegt queries toe onder het subdomein van de site, en de antwoorden bepalen welke controllers de voorkeur hebben, niet welke verplicht is.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Volg de keten in die volgorde, vanuit het netwerk waar het probleem optreedt. Een hostnaam die naar een onbereikbaar adres wordt opgelost, is een routeringsfout, geen DNS-fout. Een bereikbare controller waarvan de locatorrecords ontbreken, is een DNS-fout, geen routeringsfout. Beide leveren vergelijkbare klachten van gebruikers op en volstrekt verschillende reparaties.

Waarom een openbare resolver antwoordt en de aanmelding toch breekt

Als de adapter de client een openbare resolver geeft, werken openbare namen en de interne naamruimte niet. Een tweede openbare resolver toevoegen helpt niet, omdat geen van beide de zone bezit. Ook de gebruikelijke lijst ‘eerst intern, dan openbaar’ gedraagt zich niet als een regel per domein: een negatief antwoord van de eerste server is een legitiem antwoord, en de client probeert de tweede server niet opnieuw alleen omdat het antwoord leeg was.

Beide interne resolvers, als u er twee draait, moeten de AD-naamruimte bezitten en bereikbaar zijn vanuit het huidige netwerk van de client. Dat is het deel dat split-tunnelontwerpen breken: de VPN kan het subnet van de tunnel dragen terwijl de interne resolver op een prefix zit dat de tunnel niet routeert, zodat de query uitgaat naar een resolver die hem niet kan beantwoorden.

Windows past ook een naamresolutiebeleid toe dat specifieke naamruimten naar specifieke servers kan sturen, en de DNS-adressen die de adapter toont zijn niet het hele verhaal. De adapterlijst wijzigen zonder dat beleid te wijzigen kan de effectieve configuratie onaangeroerd laten, en daarom heeft een oplossing die toegepast lijkt geen effect.

Houd de DNS van de tunnel en zijn routes met elkaar in overeenstemming

Een VPN-profiel dat een resolver pusht maar niet het prefix dat hem bevat, maakt een resolver die de client niet kan bereiken; een profiel dat het prefix pusht zonder resolver laat de client de lokale vragen. Behandel het paar als één configuratie-item en controleer beide na elke profielwijziging, omdat een herschikte push of een nieuw split-tunnelbeleid ze kan scheiden.

Controleer ook wat de client met de gepushte instelling doet. Sommige clients passen de DNS-server alleen toe op de tunnelinterface en laten de resolver van de fysieke adapter staan, dus welke wint hangt af van de interfacemetriek en de opgevraagde naam. Als het interne antwoord alleen komt wanneer de fysieke adapter is uitgeschakeld, is dat het mechanisme dat moet worden gerepareerd, niet de domeinrecords.

Accepteer met een ontdekkingsoproep en één live handeling

Een bruikbare acceptatietest voert de locatorquery uit en verricht daarna één echte geauthenticeerde handeling, zoals het openen van een door de directory ondersteunde share of het aanvragen van een ticket. Doe dat vóór de VPN-overgang en opnieuw erna, op dezelfde machine, zonder herstart tussendoor. Gecachte inloggegevens en al geopende sessies laten een kapot pad graag gezond lijken, dus een geslaagde desktopaanmelding is de test niet.

De DNS-clientaanbevelingen van Microsoft trekken dezelfde grens tussen het oplossen van de interne naamruimte en het doorsturen van openbare queries stroomopwaarts, en dat is de ordening die behouden moet blijven wanneer een VPN wordt ingevoerd.

Als de storing alleen traag is en niet mislukt, houd de vertraging gescheiden van de diagnose. Een time-out tijdens de ontdekking kan van een onbereikbare controller, een geblokkeerde poort of een resolver komen die laat antwoordt, en geen daarvan wordt door het wachten alleen bewezen. Leg de werkelijke query, het antwoord en de verbindingspoging vast voordat u een resolverinstelling wijzigt.