En leverandørs sendeadresseendring kan avsløre en gammel godkjenningsliste, en ufullstendig konfigurasjon eller en rute ingen var klar over var aktiv. Svaret bør fastslå hvilke av disse som skjedde. Å legge til IP-en vist i den første avvisningen kan gjenopprette én prøve mens det underliggende vedlikeholdsproblemet blir intakt.
Bekreft endringen og dens omfang
Samle berørte og upåvirkede meldingsbevis, inkludert hendelsestider, mottakerobserverte IP-er og evaluerte konvoluttidentiteter. Sjekk leverandørens gjeldende autentiserte konsollinstruksjoner, offisielle dokumentasjon eller støttesvar for tjenesten din. EN omvendt DNS navn eller nett-eier-oppslag alene fastslår ikke at en adresse er autorisert for din leietakers post.
Bestem om den berørte trafikken bruker den konfigurerte primærtjenesten, en nylig aktivert region, et annet relé eller en tilpasset rute. Ikke utlede en leverandøromfattende hendelse fra ett programs oppførsel. Hold enhver ubekreftet forklaring merket som en hypotese til rutebeviset støtter det.
Identifiser hvordan policyen din følger leverandøren
En avhengighetsbasert policy kan gjenspeile endringer som er gjort i den refererte leverandørpolicyen. Et statisk kopiert område trenger en oppdatering. En administrert generator introduserer en ekstra kjede mellom leverandørkilden og din publiserte verdi. RFC 7208 avsnitt 5.2 forklarer inkluderer evaluering; det lover ikke en bestemt leverandør oppdateringstjeneste.
Sammenlign leverandørens støttede konfigurasjon, tiltenkt policy og det faktiske DNS svaret. Hvis du bruker flating, inspiser friskheten og både tilsatt og fjernet områder ved hjelp av arbeidsflyten for gammel kopi. Hvis du bruker en leverandørinkludering, bekreft at den er den rette for produkt- og leietakerkonfigurasjonen, og inspiser den nåværende evalueringen i stedet for å anta at ordet "inkluderer" garanterer korrekthet.
Gjengi én feil nøyaktig
Bruk den sviktende tilkoblingens IP- og konvoluttdomene i en standardbevisst evaluator. Bevar avhengighetssporingen og resultatkategorien. En ekte feil er forskjellig fra en feil forårsaket av overdreven evaluerte vilkår, manglende policy eller midlertidig DNS feil. RFC 7208 §2.6 og RFC 7208 §4.6.4 gi de relevante distinksjonene.
Tenk på denne illustrerende hendelsen. En tjeneste flytter noe trafikk fra 192.0.2.10 til 192.0.2.20 , mens kunden beholder en manuell oppføring for førstnevnte. Disse dokumentasjonsadressene er kun eksempler. Den riktige korreksjonen avhenger av leverandørens støttede autorisasjon, ikke av å behandle disse to observasjonene som dens komplette sendeflåte. Inkluder IPv6 i undersøkelsen når ruten bruker den.
Velg en støttet reparasjon
Hvis den dokumenterte policyavhengigheten mangler eller er feil, klargjør du den riktige støttede konfigurasjonen. Hvis en flatet kopi er foreldet, må du fikse oppdaterings- eller publiseringsstadiet i tillegg til gjeldende utdata. Hvis leverandørens egen publiserte policy ser ut til å være inkonsistent med senderruten, bevar en minimal reproduserbar sak for støtteteamet og unngå å finne på en permanent løsning.
Ethvert midlertidig unntak bør ha bekreftet omfang, godkjenning, en navngitt eier og en utløps- eller gjennomgangsbetingelse. Ikke autoriser en hel vertsplattform fordi den nye adressen tilhører den. Bevar den eksisterende posten og kontroller den fullstendige erstatningen for syntaks, oppslagsatferd og utilsiktede autorisasjonsendringer før publisering.
Bekreft gjenoppretting og forhindre gjentakelse
Test den berørte applikasjonen gjennom dens vanlige rute og inspiser et pålitelig mottakerresultat. RFC 8601 er referansen for tolkning av autentiseringspåstander på tvers av tillitsgrenser. Gjenta tester på tvers av relevante ruter i stedet for å ekstrapolere fra én vellykket melding.
Oppbevar leverandørbevis, eksakt DNS diff, mottatte meldingsresultater og gjenværende unntak i hendelsesregistret. Fjern midlertidige oppføringer når den støttede varige reparasjonen er bekreftet. Legg til overvåking for stadiet som mislyktes: kildeendringer, generatorens oppdatering, publiseringsfeil eller uventet ruting. Målet er ikke en lengre nødtillatelsesliste. Det er en vedlikeholdbar autorisasjonsbane som følger tjenesten du faktisk bruker.
Skriv avgjørelsen skriftlig
For en hypotetisk mislykket melding, behold én rad for leverandørinstruksjoner/versjon, tiltenkt konvoluttdomene, observert IP/familie, kildepolicy ved fangsttidspunkt, generert verdi, publisert svar og mottakerresultat. Hvis leverandørkilden inkluderer den nye adressen, men generatoren ikke gjør det, undersøk generering; hvis generasjonen er gjeldende, men DNS er gammel, undersøk publiserings- og løserstatus. Dette er betingede diagnostiske tilfeller, ikke funn om en navngitt leverandør.