Recursie niet beschikbaar: een DNS-beleid, geen kapotte tunnel

De interne naam wordt opgelost, en dezelfde server antwoordt op een externe naam met een weigering over recursie. Die combinatie is geen tegenspraak. Je eigen zones publiceren en het hele internet oplossen zijn twee aparte diensten die een server kan aanbieden, en hij kan het eerste doen zonder het tweede. Behandel de weigering als een beleidsverklaring en controleer daarna of het beleid bij het ontwerp past.

Een weigering en een timeout zijn verschillende antwoorden

Noteer de naam, het querytype, de antwoordende server, de status en de teruggegeven records. Een recursiewaarschuwing maakt een autoritatief antwoord dat ermee kwam niet automatisch ongeldig. Schrijf de status op voordat je hem interpreteert. Een status die een uur later uit het geheugen wordt gereconstrueerd, is een ander feit.

De DNS-header draagt een verzoek om recursie en een aanduiding of de server die biedt, en de protocolspecificatie houdt die vlaggen gescheiden van de antwoordgegevens. Daarom kan een antwoord nuttig zijn en toch een klacht dragen. Een timeout, een negatief antwoord en een weigering zijn drie verschillende uitkomsten. Elk wijst naar een andere laag, en alleen de weigering is de server die je over beleid vertelt.

Lees eerst de statuscode en besluit dan of de waarschuwing voor deze query van belang is. Een autoritatief antwoord dat de zone noemt, is bruikbaar, zelfs wanneer het recursieve bit wordt geweigerd. Een weigering zonder antwoord is een beleidsresultaat, geen kapotte pakketroute.

Wat de resolver als jouw bron vastlegde

De client kan uit een adrespool buiten de toegestane recursieve bereiken van de server komen, of een vertaling kan hem op een gateway laten lijken. Het eigen adapteradres van de client is geen bewijs voor wat de resolver ontving. Vraag de beheerder van de server naar de waargenomen bron in plaats van die van jouw kant van het pad af te leiden. De twee adressen kunnen bij elke hop die vertaalt verschillen.

Vraag dezelfde naam op vanaf de client en vanaf een host die de server al vertrouwt. Het verschil tussen de twee antwoorden is de bronvoorwaarde, en dat is nuttiger dan elk van de antwoorden alleen.

dig +short host.corp.example
dig +short example.com

Als de uitrol recursie wil voor VPN-clients, autoriseert de beheerder het juiste bronbereik via de eigen controles van de server. Recursie openzetten voor elk netwerk zodat één test slaagt, is een veel grotere wijziging dan degene die wordt getest. Schrijf het geautoriseerde bereik naast de regel, want de volgende beoordelaar vraagt welke bronnen het beleid moest bedienen. Een bronbereik zonder eigenaar is hoe een tijdelijke test permanent wordt.

Gesplitste DNS is een ontwerp, geen fout

Sommige uitrollen sturen alleen werkdomeinen naar de private resolver en al het andere naar een andere goedgekeurde resolver. Dat is een ontwerp voor queryroutering, en het is geen bewijs dat de private server een losser beleid nodig heeft. Onder dat ontwerp is een externe naam die via de private resolver faalt het bedoelde resultaat en geen fout. De weigering is het ontwerp dat werkt, geen symptoom dat onderdrukt moet worden.

Een publieke resolver kan browsen herstellen terwijl hij interne namen breekt of private queries ergens heen stuurt waar ze niet horen. Schrijf het bedoelde gedrag op voordat je een resolveradres wijzigt.

Verifieer het beleid met twee queries

Vraag na de bedoelde correctie een toegestane private naam en een externe naam op vanaf de werkelijke client. Wat terugkomt, zou moeten zijn wat het beleid belooft, niet alleen een stillere diagnose. Noteer de antwoordende server bij elk antwoord en vergelijk het paar daarna met het beleid. De vergelijking is de test, en één geslaagde opzoeking is dat niet.

resolvectl query host.corp.example
resolvectl query example.com

Als de private naam werkt en de publieke naam wordt geweigerd, doet het beleid wat het zegt. Als de private naam ook faalt, is het probleem de zone, de route of de bronautorisatie, en is recursie een afleiding. Beide uitkomsten zijn nuttig, en elk sluit de helft van de resterende hypotheses uit.

Lees de weigering als bewijs

Een weigering is een antwoord. Het betekent dat de server de query ontving en weigerde het gevraagde werk te doen, wat verschilt van een pakket dat nooit aankwam. Dat verschil is de hele diagnose. Log het als een antwoord, niet als een verbindingsfout.

Dat verschil vertelt je waar je moet kijken: de logs van de server, het toegangsbeleid en de bron die hij vastlegde. Een firewallwijziging kan een beleidsweigering niet oplossen, en een beleidswijziging kan een ontbrekende route niet oplossen. Houd de twee hypotheses gescheiden tot een van beide bewijs heeft.

Schrijf de uitkomst en de eigenaar van het beleid in de ticket, zodat de volgende persoon bij de beslissing begint en niet bij de waarschuwing. Noem het geautoriseerde bronbereik en de twee namen die je hebt getest. Een ticket met die drie feiten kan opnieuw worden uitgevoerd; een dat zegt "recursie is kapot", niet.