Et jokertegn MX kan få et tidligere ukonfigurert underdomene til å se ut til å motta e-post. Det betyr ikke at alle navn under sonen deler samme rute. DNS jokertegnsyntese avhenger av om navn eksisterer og av den nærmeste omsluttende noden, ikke en enkel tekstmatch på tvers av alle underdomener.
Skille jokertegn DNS fra postboks catch -all
Referanser: RFC 4592 §3.3, RFC 5321 §3.3.
Et DNS jokertegn som f.eks *.example.com kan levere data for visse ellers ikke-eksisterende navn. En postboks catch -all er en e-postserverregel om hvilke lokale deler den godtar. Den ene kan eksistere uten den andre. Et jokertegn MX svar beviser ikke at utvekslingen godtar anything@sub.example.com, og en catch -all -postboks kan ikke reparere en DNS rute som aldri når serveren.
RFC 4592 definerer jokertegnoppførsel i form av den nærmeste omslutningen og syntesekilden. Eksisterende navn har betydning selv om de ikke har noen registrering av den forespurte typen. Ikke anta at et jokertegn MX fyller den manglende MX typen ved hvert navn som allerede har en A eller TXT post.
Gå en minimal sone
Referanser: RFC 4592 §2.2.2, RFC 4592 §3.3.1, RFC 5321 §5.1.
Bruk en isolert example.com testsone som inneholder *. example.com . IN MX 10 mx.example.com ., en En rekord på mx.example.com, og en A-rekord kl known.example.com. Uten andre relevante navn, et MX -søk for missing.example.com kan syntetisere jokertegnet MX . En MX -spørring for den eksisterende known.example.com har ingen MX data ved det navnet og arver ikke bare jokertegnet. SMTP kan da følge sine reserveadresseregler.
Legge til leaf.branch.example.com . IN TXT "armatur". Dette skaper det inngripende branch.example.com node selv om den ikke har noen eksplisitt registrering. En MX spørring under den grenen har nå en nærmere omsluttende node. Uten jokertegn kl *.branch.example.com, apex-jokertegnet er ikke en catch -all reserve. Bevar dette moteksemplet fordi det forklarer hvorfor to tilsynelatende like adresser tar forskjellige ruter.
Dette er syntetiske forventede resultater. Last inn sonen til en isolert autoritativ server, spør hvert eksakt navn og lagre svar, autoritet og svarkode. Test navn eksistens og skriv fravær separat. Ingen live serverutførelse er hevdet av disse eksemplene.
Revidere ruten og dens akseptpolicy
Referanser: RFC 1034 §4.3.2.
List opp faktiske underdomener, delegerte barn og jokertegneiere. En delegasjon skaper en myndighetsgrense; det overordnede jokertegnet er ikke en erstatning for barnesonens svar. Sjekk utvalgte ikke-eksisterende navn så vel som kjente navn, og spor det returnerte MX vertsnavnet til adressene.
På mottakstjenesten bekrefter du hvilke mottakerdomener og lokale deler som godtas. Uventet ruting kan avsløre driftspost for feil leietaker eller generere tilbakespredning hvis avslaget blir forsinket. Test kun adresser og tjenester du kontrollerer, med ufarlig innhold og eksplisitt forventet håndtering.
Endre den smaleste relevante kontrollen
Referanser: RFC 7505 §3, RFC 8767 §4.
Hvis ett domene ikke skal motta e-post, vurdere en eksplisitt Null MX ved det navnet. Hvis jokertegnet er unødvendig, kan fjerning av det påvirke mange tidligere usett navn. Inventar disse avhengighetene før du endrer det. Bekreft både DNS og mottakerhåndtering etter endringen, inkludert bufrede tidligere svar, og registrer nøyaktig hvilke uventede ruter som ble eliminert.
Hold bevisomfanget eksplisitt
Jokertegnvandringen er en kildebasert forventet resultatillustrasjon, ikke en utført autoritativ DNS test. Navnets eksistens og nærmeste vedlegg må bestemmes før du velger et jokertegn; hvis kandidatkilden ikke eksisterer, ikke søk i bredere jokertegneiere som en reserve.