En soneoverføring kopierer sonedata mellom DNS servere eller til en autorisert administrasjonsklient. AXFR er fulloverføringsprotokollen beskrevet i RFC 5936 . En uventet tilgjengelig overføring kan avsløre en omfattende postbeholdning, men dens eksistens gjør ikke i seg selv at e-postautentisering passerer eller mislykkes. Vurder hva som ble avslørt, om overføringen var ment, og hvilke kontroller som styrer tilgangen.
Etablere myndighet og tillatelse
Referanser: RFC 5936 §5.
Identifiser den eksakte sonen og dens autoritative servere. Innhent autorisasjon før du tester overføringer mot en produksjonstjeneste. Bruk først leverandørens støttede konfigurasjons- og revisjonsverktøy der det er tilgjengelig. Ikke skann urelaterte domener eller forsøk å omgå en nektet overføring for å få et funn til å virke mer dramatisk.
En legitim sekundær server kan kreve overføringstilgang. Offentlig autoritativ DNS -tjeneste og tillatelse til å overføre hele sonen er separate vedtak. Gjennomgå de tillatte klientene, autentiseringsmekanismen, transportkontrollene og operasjonelle formål. En godkjenningsliste basert kun på adresse kan ikke byttes ut med kryptografisk klientautentisering.
Tolk de returnerte dataene riktig
Referanser: RFC 5936 §2.2, RFC 5936 §3.
AXFR returnerer soneinnhold i henhold til protokollen, inkludert start og slutt SOA-innramming. Et vellykket svar kan avsløre navn som allerede var individuelt søkbare, men som ikke lett kunne telles. Vurder om inventaret avslører sensitive interne navngivninger, forlatte tjenester eller driftsavhengigheter. Offentlig DNS bør ikke brukes som en hemmelig butikk i utgangspunktet.
Ikke sett likhetstegn mellom avslag og en helt sikker sone. Individuelle poster forblir søkbare, og varelager kan være tilgjengelige gjennom sertifikater, konfigurasjonslekkasjer eller andre kilder. Motsatt er en bevisst offentlig overføring ikke automatisk en sårbarhet; evaluere organisasjonens policy og faktiske eksponering.
Separat postpåvirkning fra lagereksponering
Referanser: RFC 6376 §3.1, RFC 5936 §1.
En overføring endres ikke SPF autorisasjoner, erstatte en DKIM nøkkel eller endre DMARC politikk. Å oppdage en velger navnet avslører ikke den private signeringsnøkkelen. Offentlige DKIM nøkler er designet for å kunne hentes av verifikatorer. Hvis en sone inneholder en legitimasjon eller konfidensiell verdi, er det en separat datahåndteringshendelse som krever sin egen respons.
Bruk inventaret til å sjekke eierskap og foreldede avhengigheter uten å hevde at oppregning beviser utnyttelse. Et hengende alias kan kreve undersøkelse, men faktisk kontrollerbarhet avhenger av destinasjonstjenesten og konfigurasjonen. Ikke registrer eller gjør krav på andres ressurs bare for å styrke en rapport.
Gjengi vurderingen trygt
Sjekkpunktet inkluderer en offline overføringsformet armatur med en start-SOA, en TXT markør og en matchende slutt-SOA. Den lokale sjekken bekrefter den enkle innrammingen og merker den med inventarbevis, ikke autentiseringsfeil. En annen armatur inneholder et NEKERT svar og er merket overføring nektet, ikke sonesikker.
Kjør det medfølgende skriptet for å reprodusere disse etikettene. Dette er ikke en fullstendig AXFR-parser eller en nettverksoverføring. For et autorisert isolert laboratorium, konfigurer en primær og sekundær ved å bruke den valgte serverens offisielle dokumentasjon, test en tillatt klient og en nektet klient, og bevar de faktiske svarene og den relevante tilgangskonfigurasjonen. Full primær/sekundær implementering og tilgangskontrolltester forblir ikke utført; den smalere beholdte skriptede loopback-utvekslingen nedenfor er separat.
Utbedring med tanke på kontinuitet
Referanser: RFC 5936 §5, RFC 5936 §6.
Hvis tilgangen overskrider retningslinjene, begrenser du overføringer gjennom støttede serverkontroller mens du beholder legitim sekundær drift. Gjennomgå både tilgangsbegrensninger og autentisering i stedet for å anta at den ene erstatter den andre. Etter endringen, verifiser nektet uautorisert tilgang og fortsatt autorisert overføring, sonefriskhet og autoritativ tilgjengelighet.
Dokumenter det avslørte postomfanget, tiltenkte klienter, eksakte utbedring og testbegrensninger. Hold e-postautentiseringsresultatet atskilt: Representative meldingstester og effektive postforespørsler er fortsatt nødvendig for å vurdere postoppførsel. En god rapport løser eksponeringen uten å gjøre en DNS -administrasjonsobservasjon til et ustøttet e-postsikkerhetskrav.
Beholdt historisk trådbevis
Følgende beskriver den beholdte 7. november 2026 loopback-fangsten, inspisert, men ikke kjørt på nytt som et nettverkseksperiment for denne gjennomgangen. Kontroller av nye offline-modeller registreres separat.
Det beholdte sjekkpunktet registrerer faktiske DNS-over-TCP-spørringer mot sin egen minimale loopback-server. En tillatt example.test AXFR returnerer samsvarende SOA-innramming og apex TXT policyen v=spf1 -all ; en spørring for sonen andre.test utenfor området returnerer REFUSED. En separat UDP TXT -spørring henter den samme SPF policyen. Dette navngir den spesifikke avhengigheten: en SPF evaluator trenger konvoluttdomenets valgte TXT policy, mens AXFR avslører den bredere beholdningen uten å endre den. Spørrings- og svarledningsbytes, endepunkter og UTC-tider beholdes. Serveren bruker en bevisst enkel sonegodkjenningsliste, ikke produksjonsautentisering eller en komplett AXFR-implementering.