Et domæne vist i Unicode kan forespørges gennem en ASCII-kompatibel repræsentation. Bevar både formularer og konverteringsreglerne, så et kontrolresultat kan gengives. Visuel fortrolighed er ikke bevis for, at to navne identificerer det samme domæne eller tilhører den samme organisation.
Adskil domænet fra postkassen
Referencer: RFC 5890 §2.3.2.1, RFC 5891 §5.
En internationaliseret domænetiket kan have en U-label, dens gyldige Unicode-form og en A-label, dens validerede ASCII-kompatible form begynder xn--. IDNA-behandling opererer på domæneetiketter. Det konverterer ikke en e-mail-lokal del til en ASCII-postkasse og etablerer ikke SMTPUTF8-understøttelse.
Godkendelsesposter tilføjer protokoletiketter rundt om domænet. Konverter den internationaliserede domænedel med den passende IDNA-implementering, og konstruer derefter ejeren, som f.eks _dmarc. plus A-mærket domæne. Kør ikke en IDNA-validator kun for værtsnavn over protokolunderstregningsetiketter og konkluder, at det underliggende domæne er ugyldigt.
Valider i stedet for blot at kode
Referencer: RFC 5890 §2.3.2.1, RFC 5891 §4, RFC 5895 §2.
Punycode er en del af A-label-repræsentationen, men ikke hver streng, der begynder xn-- er en gyldig A-label. Validering inkluderer de gældende IDNA-regler, tilladte tegn og kontekstuelle begrænsninger. RFC 5891 definerer protokolbehandling, mens valg af programkortlægning kan påvirke brugerinput før denne behandling.
Optag biblioteket og versionen, IDNA-profilen, Unicode-input og den resulterende ASCII-formular. Værktøjsstandarder kan variere, især for tegn, der er påvirket af kortlægning eller ældre IDNA-adfærd. Undgå lydløst at normalisere en tvetydig brugerindtastning og præsentere resultatet som det eneste mulige tiltænkte domæne.
Genskab en rundtursarmatur
Brug et installeret Python idna-bibliotek, der implementerer IDNA2008, kør idna.encode("bü cher.example ", uts46=False).decode("ascii"). Forventet output er xn--bcher-kva.example. Afkod det med det samme bibliotek og bekræft Unicode-tur-retur. Eksemplet er illustrativt og er ikke en påstand om en organisations live-domæne.
Konstruere _dmarc.xn--bcher-kva.example og s1._domainkey.xn--bcher-kva.example som DNS ejerstrenge. I et laboratorium eller kontrolleret checker kan du registrere, om værktøjet accepterer Unicode-input, konverterer det, afviser det eller sender et andet spørgsmål. Den bevarede historiske optagelse registrerer kun bibliotekskonvertering med idna version 3.18. Den nye offline konverteringskontrol i denne anmeldelse registrerer sin egen installerede version separat; det er heller ikke en DNS eller SMTPUTF8-test.
Tilføj en negativ fixtur med en ugyldig xn---label og behold den faktiske bibliotekundtagelse. Behandl afvisning som et nyttigt bevis i stedet for at slette tegn, indtil input tilfældigvis passerer. For andre brugervendte kortlægninger, dokumenter den alternative profil eksplicit i stedet for at antage, at et IDNA2008-resultat matcher enhver browser.
Sammenlign faktiske identiteter i postbeviser
Referencer: RFC 9989 §4.4, RFC 9989 §5.3.1.
Bevar originalen Fra overskrift og domænerepræsentationerne brugt af SPF, DKIM og DMARC analyse. For DMARC , RFC 9989 §5.3.1 kræver, at et udtrukket U-label Author Domain konverteres til A-label form for videre behandling. Brug protokollens justering regler frem for en visuel sammenligning af viste navne. Hvor meddelelsessyntaks eller internationaliseringsadfærd ikke understøttes af et værktøj, skal du rapportere begrænsningen i stedet for stille at vælge en bekvem identitet.
Brug kendt ejerskabskontekst til at undersøge lookalikes. Et domæne kan videregive sin egen godkendelse og stadig visuelt ligne en anden organisations navn. IDNA-konvertering forbedrer reproducerbarheden; det bekræfter ikke mærkeejerskab, fjern phishing risikere eller bevise, at en e-mail-meddelelse blev godkendt af den forventede part.