.invalid |
---|
Introdusert | 1999 |
---|
TLD-type | Reservert toppnivådomene |
---|
Status | Reservert for å forhindre faktisk bruk |
---|
Registreringsenhet | Internet Assigned Number Authority (IANA) |
---|
Sponsende organisasjon | Ingen |
---|
Tiltenkt bruk | Når det er nødvendig å vise en adresse som garantert og åpenbart er ugyldig |
---|
Faktisk bruk | Vanlig å bruke i bevisst feilaktige e-mail-adresser laget for bruk i posteringer til newsgroups for å unngå spam |
---|
Restriksjoner | Ingen registrering mulig ettersom domenet ikke er i rota |
---|
Struktur | Ettersom domenet ikke eksisterer i virkeligheten kan brukere benytte enhver struktur de måtte ønske |
---|
Dokumenter | RFC 2606 |
---|
Konfliktpolitikk | Ingen |
---|
Nettsted | ingen |
.invalid er et reservert toppnivådomene som ikke er beregnet for faktisk bruk i det globale DNS. Det ble definert i juni 1999 av RFC 2606, sammen med .test, .localhost og .example.
Formålet med opprettelsen av .invalid var å stille et TLD til rådighet som kunne benyttes i tilfeller hvor en bruker ønsker å oppgi en adresse som man vet ikke virker.
Bruk av .invalid som siste del av en bevisst feilaktig email-adresse er sterkt anbefalt, da det vil minimalisere belastningen på legitime systemer hvis adressen skulle bli sanket inn av spammere. Hvis den bevisst feilaktige adressen inneholder et gyldig og eksisterende domene (og mange åpenbare muligheter som example.com er faktisk gyldige) så vil massemailing til ikke-eksisterende subdomener og brukere måtte rutes og deretter forkastes av serverne som tilhører det domenet. Hvis domenet i den bevisst feilaktige adressen ikke er gyldig, så er det likevel nødvendig med en viss mengde DNS-aktivitet for å fastslå dette. En lookup på en .invalid-adresse derimot, kan forkastes ved første anledning.
Enkelte anser bruken av ugyldige adresser i et «Fra»-felt (for eksempel, i posteringer til nyhetsgrupper) for å være i strid med standardene, enten det er korrekt markert med bruk av .invalid-TLD'et eller ikke. Bakgrunnen er at en mulig tolkning av de relevante RFC dokumenter er at slike felter alltid må inneholde gyldige adresser som forfatteren av beskjeden kan nås på.
Kilder
Autoritetsdata