Definieer het probleem voordat u DNS wijzigt
A leeg opzoeken diagnose betekent meer dan “ DNS heeft niet het verwachte adres opgegeven.” RFC 7208 beschrijft relevante zoekopdrachten die een positief antwoord retourneren met nul antwoorden, of een naamfoutantwoord. Dit worden gewoonlijk ongeldige zoekopdrachten genoemd. Een time-out of serverstoring valt niet onder dezelfde antwoordcategorie. Als u alle mislukte zoekopdrachten als ongeldig beschouwt, kan een tijdelijk oplosserincident veranderen in een onjuiste aanbeveling om een geldig afzenderbeleid te herschrijven.
De standaard zegt dat implementaties ongeldige zoekopdrachten MOETEN beperken tot twee. Het staat een configureerbare limiet toe en beveelt in dat geval twee aan als standaardlimiet. Het overschrijden van de toepasselijke limiet levert op permerror. Houd dit normatieve onderscheid in stand: twee is geen onvoorwaardelijke universele MUST bij elke implementatie, maar een recensent mag er ook niet van uitgaan dat een onbekende ontvanger zijn limiet heeft verhoogd. RFC 7208 , sectie 4.6.4
Onderhoud twee afzonderlijke tellers
Het geheel SPF budgetlimieten evalueerden DNS-veroorzakende termen, waaronder include, a, mx, ptr, exist en redirect. De ongeldigheidsbeperking heeft betrekking op het kwalificeren van lege of niet-bestaande antwoorden die tijdens de evaluatie worden aangetroffen. Ze overlappen elkaar wat betreft operationele gevolgen, maar meten verschillende dingen. Een beleid kan op problematische leegtereacties stuiten voordat het totale termijnbudget is uitgeput. Een lang succesvol afhankelijkheidstraject kan het termijnbudget uitputten zonder ongeldige reacties te veroorzaken.
Het aantal pakketopnamen, het aantal treffers van de solver-cache en het aantal SPF -termen zijn niet uitwisselbaar. Caching kan de netwerkactiviteit veranderen zonder dat het logische beleid vrij kan worden geëvalueerd. Op dezelfde manier kan een syntactische term extra oplossingswerk vergen of zijn eigen aanvullende beperkingen hebben. Bewaar de geëvalueerde term, de uitgebreide querynaam, het recordtype, de antwoordclassificatie en de lopende totalen in afzonderlijke velden. RFC 7208 , sectie 4.6.4
Verzamel voldoende responsdetails om de gebeurtenis te classificeren
Voor een voorgesteld geautoriseerd onderzoek bewaart u de opgevraagde naam en het type, DNS reactiecode, het aantal antwoorden, de relevante geretourneerde records, de context van de oplosser en het tijdstempel. Bewaar het onbewerkte antwoord of een getrouw gestructureerd transcript, en niet alleen een groen of rood dashboardlabel. Een positief antwoord zonder antwoorden mag niet stilzwijgend worden herschikt als NXDOMAIN . Beide kunnen van belang zijn om de boekhouding ongeldig te maken, maar hun DNS betekenissen en herstelpaden kunnen verschillen.
Registreer of de zoekopdracht daadwerkelijk is bereikt door de SPF beoordelaar. Een statische detectietool kan afhankelijkheden onderzoeken die het specifieke bericht nooit evalueert. Een dergelijk onderzoek kan risico's aan het licht brengen, maar het is geen bewijs dat het bericht deze zoekopdrachten heeft gebruikt. Identificeer het verbindingsadres, de invoer van de afzender en de beleidstak, zodat een andere reviewer kan begrijpen waarom een mechanisme is geëvalueerd of overgeslagen.
Bewaar fouten afzonderlijk. Een time-out, een ingekort verzamellogboek of een ontoegankelijke oplosser is een onzekerheid die een eigen classificatie nodig heeft. Vervang ontbrekende observaties niet door een verondersteld leeg antwoord. Het onderzoek moet reproduceerbaar zijn zonder dat de recensent de antwoordtypen uit proza hoeft af te leiden.
Mechanismen interpreteren voordat u een reparatie voorstelt
Een bestaand mechanisme test of het uitgebreide domein adresgegevens heeft op de manier die door de standaard is gedefinieerd. Een a-mechanisme vergelijkt de relevante adressen met de verbindende client. Hun niet-overeenkomende uitkomsten bewijzen op zichzelf niet dat de uitgever een fout heeft gemaakt. Sommige beleidsregels maken opzettelijk gebruik van bestaanscontroles. De diagnostische vraag is of het daadwerkelijke pad binnen de geldende grenzen blijft en of de afhankelijkheid nog steeds het beoogde autorisatiedoel dient.
Een niet-bestaand include-doel verdient een andere verklaring. Inclusief evalueert recursief een beleid; een kind geen resultaat wijst op permerror , in plaats van te worden behandeld als een gewone niet-match die er veilig doorheen gaat. Een rapport kan dus ontbrekende DNS gegevens tegenkomen en een directere include-fout vertonen dan een cumulatieve void-limit-verklaring. Verklaar de vroegst ondersteunde fout, en niet elk denkbaar gevolg van dezelfde ontbrekende naam. RFC 7208 , sectie 5.2, 5.3 en 5.7
Operationeel werkblad en acceptatiecriteria
Bereid een werkblad voor met kolommen voor stap, met daarin het beleid, het mechanisme, het uitgebreide doel, het querytype, de responscode, het aantal antwoorden, het totaal van de logische termen, het ongeldige totaal en de vervolgbeslissing. Voeg, indien beschikbaar, de gedocumenteerde ongeldigheidslimietconfiguratie van de beoordelaar toe. Als die configuratie onbekend is, vermeld dan de aanname en voorkom dat deze zonder bewijs aan een echte ontvangende dienst wordt toegeschreven.
Wijs voor elk vermoedelijk leeg antwoord een eigenaar toe die kan bevestigen of het doel actueel is. Een typografische fout, de afhankelijkheid van een gepensioneerde provider, een opzettelijke bestaanstest en tijdelijk niet beschikbaar bewijsmateriaal vereisen verschillende reacties. Documenteer de voorgestelde correctie en de afzenderroutes die deze kan beïnvloeden. Vervang nooit een geraden leverancier, alleen maar omdat de naam er bekend uitziet.
Acceptatie vereist een samenhangend pad en een exact falende vertakking, en niet simpelweg minder termen in een conceptrecord. De beoordelaar moet kunnen identificeren welk antwoord als ongeldig is geclassificeerd, wanneer de geconfigureerde drempelwaarde is overschreden en waarom die gebeurtenis het resultaat heeft bepaald. Na elke afzonderlijk goedgekeurde wijziging zou er opnieuw actueel bewijs nodig zijn, omdat de afhankelijkheden en caches van de provider kunnen verschillen van de planningsmomentopname.
Fictieve diagnose: lege antwoorden versus een onbeschikbare oplosser
Stel je een volledig fictief beleid voor dat drie bestaanscontroles achter elkaar doorloopt, die elk een positief antwoord opleveren, zonder antwoorden. Veronderstel een fictieve beoordelaar die is geconfigureerd met een ongeldigheidslimiet van twee en geen eerdere overeenkomst of fout. Bij het derde kwalificerende antwoord identificeert de voorgestelde tracering de overschreden limiet en permerror . Dit is een verklarend scenario, geen uitgevoerde overeenkomst of een claim over welke aanbieder dan ook.
Verander de derde observatie in een time-out. De diagnose kan niet langer zeggen dat dit antwoord het derde ongeldige antwoord was. De onderzoeker moet de tijdelijke DNS fout en de afhandeling door de evaluator behouden, in plaats van de gebeurtenis in de vorige uitleg te forceren. Verander de tweede observatie in een positief adresantwoord dat overeenkomt met het bestaande mechanisme, en de latere tak wordt mogelijk helemaal nooit bereikt.
Deze variaties laten zien waarom een platte lijst met onopgeloste hostnamen onvoldoende is. De relevante feiten zijn de responssemantiek, de volgorde en het eindpunt. Ze laten ook zien waarom dezelfde beleidstekst verschillende paden kan opleveren voor verschillende invoer of DNS statussen, zonder te impliceren dat één waarnemer het resultaat ervan heeft verzonnen.
Bewaar origineel bewijsmateriaal en laat de poorten open
Voor dit manuscript werd geen publiek of privédomein bevraagd. Het werkblad is een voorgestelde methode en de uitgewerkte diagnose is fictief. De catalogus vereist een geannoteerd pad dat elke getelde term en de exacte falende vertakking toont; deze eis blijft open totdat er daadwerkelijk geautoriseerd bewijsmateriaal bestaat en wordt beoordeeld.
Een publicatie moet de context van de oplosser, de verzameltijd en de aannames van de evaluator benoemen. Het mag geen universeel ontvangergedrag claimen op basis van de configureerbare drempelwaarde van één implementatie. Toepasselijkheid van de bron, menselijke beoordeling, origineel bewijsmateriaal, productieroutes, visuele toegankelijkheid en vrijgave door de eigenaar blijven open. Elke echte DNS reparatie behoort tot een afzonderlijk geautoriseerd wijzigingsproces met een actuele afzenderinventarisatie en een rollback-plan.