DNS alleen via je eigen VPN-resolver toestaan: een stapsgewijze doorloop

Volg één naamopzoeking vanaf het moment dat je die typt. De browser vraagt het besturingssysteem, het besturingssysteem vraagt de resolver die zijn beleid kiest, en de query verlaat het apparaat via een of andere interface met een of ander transport. Je VPN-ontwerp zegt dat het antwoord van een bepaalde resolver via een bepaald pad moet komen. De kloof tussen die twee uitspraken is wat je configureert en daarna afdwingt.

Stap 1: benoem de resolver en het pad

Schrijf drie dingen op voordat je een firewall aanraakt: het adres van de resolver, het protocol en de poort die je verwacht, en de interface waar de query door naar buiten moet. Zonder die lijst is een regel een gok over verkeer en niet de uitvoering van een beslissing. Een VPN kan toepassingsgegevens dragen terwijl DNS een aparte regeling volgt, en dat is op zichzelf geen fout. Het is wat er gebeurt als niemand de client iets anders heeft verteld.

Het pad expliciet benoemen is het verschil tussen een ontwerp en een ongeluk. Het geeft je ook iets om later te testen, omdat elke waarneming met een schriftelijke verwachting kan worden vergeleken. Bewaar die lijst in de wijzigingsticket en niet in iemands hoofd.

Stap 2: zet het beleid waar het werkelijk woont

De keuze van de resolver hoort bij de client: de netwerkconfiguratie van het besturingssysteem, de eigen instellingen van de VPN-client of een beheerd browserbeleid. Zet die eerst daar, met het mechanisme dat het platform ondersteunt, want een firewall kan een client niet dwingen een resolver te kiezen waarover hij nooit iets heeft gehoord. Op een client met een gesplitste tunnel zeg je uitdrukkelijk welke domeinen naar de interne resolver gaan. In een beheerde vloot is browserbeleid vaak de enige hendel voor DoH, omdat de browser zijn eigen versleutelde resolver onafhankelijk van de systeeminstelling kan kiezen.

Sla dit over en ga direct naar de firewall, en je krijgt een regel die de juiste resolver toestaat plus een client die hem nooit gebruikt. De regel ziet er correct uit en de logboeken van de resolver blijven leeg, een verwarrend paar om te debuggen. Configureer eerst de keuze en dwing die daarna af.

Stap 3: dwing het pad nauw af

Voeg nu de netwerktoestemming toe voor het toegestane pad: het adres van de resolver, het protocol en de poort, en de interface waar het door naar buiten moet. Houd de regel beperkt tot die resolver in plaats van alle uitgaande DNS toe te staan. De drie paden hieronder zijn de paden die een moderne client kan nemen, en alleen het eerste valt onder een regel voor poort 53.

DoH en DoT blokkeren is legitiem; aannemen dat een regel voor poort 53 ze al heeft geblokkeerd niet. Een browser met DoH lost namen op via een pad dat je regel nooit heeft beschreven, en een toepassing die zijn eigen resolver meebrengt doet hetzelfde. Schrijf elk pad op dat je wilt toestaan en elk pad dat je wilt weigeren. Een regel die geen pad noemt heeft daarover niets besloten.

Stap 4: volg private en publieke namen

Gesplitste DNS stuurt met opzet alleen private naamruimtes naar een interne resolver terwijl publieke namen elders heen gaan, dus meer dan één resolver in het ontwerp is geen lek. Het lek is een query die naar jouw resolver had moeten gaan en ergens anders opduikt, of een onbereikbaar bedoeld pad waardoor de client stil terugvalt. Die twee gevallen zijn wat je moet zoeken. Volg een interne en een publieke naam onder het bedoelde beleid en noteer welke resolver op elk daarvan antwoordde.

Een testsite die je resolver rapporteert is een aanwijzing, geen bewijs, omdat hij alleen de queries ziet die hem bereikten. Leg de query vast aan de kant van de client wanneer je moet weten welk pad hij werkelijk nam, en vergelijk dan beide waarnemingen. Als ze het oneens zijn, heb je een terugval gevonden die niemand heeft gedocumenteerd.

Als het adres van de resolver klopt maar onbereikbaar is, zit het probleem in routering of filtering en niet in beleid. Volg de query naar dat adres en bevestig dat het antwoord via de verwachte interface terugkomt voordat je een instelling van de resolver wijzigt.

Stap 5: houd een weg terug

Voordat je de DNS-toegang op de gateway aanscherpt, bevestig je een herstelmethode die niet van naamresolutie afhangt. Een kapotte resolver maakt elk reparatiegereedschap lastiger te bereiken, ook de middelen waarmee je de wijziging zou terugdraaien. Houd een lokale console of een pad buiten de band open tot het nieuwe beleid is bewezen. Verwijder het pas nadat het beleid een herverbinding heeft doorstaan.

Na een herverbinding of een update van het browserbeleid inspecteer je de effectieve toestand opnieuw, omdat beide de resolver kunnen wijzigen zonder je regel te wijzigen. De eis is een bekende ontvanger en een beschermd pad voor de queries, niet een geruststellend resolverlabel op één schermafbeelding. De RFC 8484-specificatie voor DNS over HTTPS is de referentie voor het versleutelde pad dat je poortregel niet ziet.