Kod AuthInfo / EPP — co to jest i kiedy jest potrzebny?
W skrócie: kod AuthInfo to poufny kod autoryzacyjny używany przede wszystkim przy transferze domeny od jednego rejestratora do drugiego. Bywa nazywany kodem EPP, kluczem transferowym, Auth-Code albo transfer code. Technicznie EPP jest jednak protokołem komunikacji rejestratorów z rejestrami, a AuthInfo — informacją autoryzacyjną powiązaną z konkretną domeną. Kod nie jest potrzebny do zwykłej zmiany DNS, hostingu czy odnowienia domeny. Należy pobierać go dopiero przed zaplanowanym transferem, przekazywać wyłącznie przez zweryfikowany proces i unieważnić, jeżeli mógł trafić do niewłaściwej osoby.
Zmiana firmy obsługującej domenę wygląda w panelu jak prosta operacja: pobierz kod, wpisz go u nowego operatora i potwierdź transfer. Ten skrót pomija jednak blokady, e-maile autoryzacyjne, zasady właściwego rejestru oraz bezpieczeństwo samego kodu. Przy domenie firmowej błędne przekazanie AuthInfo może uruchomić próbę nieautoryzowanego transferu, a przy sprzedaży adresu — narazić sprzedającego na utratę kontroli przed zabezpieczeniem zapłaty.
Najważniejsze jest rozróżnienie celu operacji. Transfer rejestratora nie zawsze oznacza zmianę abonenta, a kod nie jest dowodem własności domeny. Dlatego przed jego pobraniem trzeba wiedzieć, co ma zostać zmienione, kto jest uprawniony do działania i jaka procedura obowiązuje dla danego rozszerzenia.
Co to jest kod AuthInfo?
Kod AuthInfo to unikalna informacja autoryzacyjna przypisana do domeny, wykorzystywana w procedurze przeniesienia jej obsługi do innego rejestratora. Dla domen globalnych gTLD ICANN używa nazw Auth-Code, Authorization Code, Auth-Info Code i transfer code. Kod tworzy albo wydaje aktualny rejestrator, a abonent przekazuje go nowemu rejestratorowi podczas inicjowania transferu.
Kod może mieć postać ciągu liter, cyfr i znaków specjalnych. Nie należy wyciągać wniosków o jego bezpieczeństwie wyłącznie z długości widocznej w panelu — sposób tworzenia, ważność i możliwość regeneracji zależą od rejestru oraz rejestratora. Dla gTLD zasady ICANN wymagają, aby kody generowane przez rejestratora były unikalne dla poszczególnych domen. Aktualną definicję i sposób uzyskania opisuje ICANN w informacji o Auth-Code .
AuthInfo nie jest:
- hasłem do całego konta u rejestratora,
- kodem do edycji rekordów DNS,
- potwierdzeniem prawa do sprzedaży domeny,
- umową przenoszącą prawa i obowiązki abonenta,
- kodem potrzebnym do odnowienia domeny,
- gwarancją, że transfer zostanie przyjęty.
Jest jednym z zabezpieczeń konkretnej operacji. Rejestr lub rejestrator może dodatkowo wymagać zdjęcia blokady, zalogowania na konto, potwierdzenia wiadomości, aktualnych danych abonenta albo zakończenia okresu, w którym transfer jest niedopuszczalny.
AuthInfo a EPP — czy to dokładnie to samo?
W języku ofert i paneli określenia „kod AuthInfo” i „kod EPP” są zwykle używane zamiennie. Użytkownik, który widzi pole „EPP code”, powinien najczęściej wpisać w nim kod transferowy otrzymany od dotychczasowego rejestratora. Z technicznego punktu widzenia pojęcia nie są jednak tożsame.
EPP, czyli Extensible Provisioning Protocol, to protokół warstwy aplikacji służący do obsługi obiektów w rejestrze. Umożliwia komunikację systemów rejestratora i rejestru podczas takich operacji jak rejestracja, aktualizacja czy transfer domeny. Standard opisuje
RFC 5730
, a mapowanie dla nazw domen —
RFC 5731
. W tym drugim dokumencie występuje element authInfo, który może zawierać informację autoryzacyjną powiązaną z domeną.
Najprościej można to ująć tak:
- EPP jest językiem komunikacji systemów,
- AuthInfo jest sekretem używanym do autoryzacji określonej operacji,
- „kod EPP” jest popularną nazwą handlową kodu AuthInfo.
Ta precyzja ma praktyczne znaczenie. Statusy EPP, takie jak clientTransferProhibited, nie są kodem transferowym. Informują o stanie domeny i mogą wskazywać, dlaczego transfer nie może się rozpocząć.
| Pojęcie | Do czego służy? | Czy należy je chronić? |
|---|---|---|
| AuthInfo / Auth-Code | Autoryzuje transfer konkretnej domeny zgodnie z zasadami rejestru | Tak, jak poufny sekret transferowy |
| EPP | Umożliwia komunikację techniczną między rejestratorem a rejestrem | Użytkownik zwykle nie obsługuje protokołu bezpośrednio |
| Status EPP | Opisuje stan domeny, np. blokadę transferu | Nie jest sekretem; status można sprawdzić w danych domeny |
| Hasło do konta | Daje dostęp do panelu rejestratora i często wielu domen | Tak; nie wolno przekazywać go przy transferze |
| Blokada transferu | Utrudnia przeniesienie domeny bez wcześniejszego odblokowania | To ustawienie, nie kod |
Kiedy kod AuthInfo jest potrzebny?
Kod jest potrzebny przede wszystkim wtedy, gdy abonent chce przenieść obsługę domeny od aktualnego rejestratora do innego. Dotyczy to wielu popularnych domen krajowych i globalnych, ale szczegółowa procedura zależy od rozszerzenia.
Samo pojawienie się nowego dostawcy w projekcie nie oznacza jeszcze transferu domeny. Firma hostingowa może przenieść stronę na inny serwer bez zmiany rejestratora. Agencja może otrzymać ograniczony dostęp do DNS bez przejmowania domeny. Nowy dostawca poczty może wymagać rekordów MX i TXT, lecz nie kodu AuthInfo.
| Planowana operacja | Czy AuthInfo jest zwykle potrzebny? | Co jest potrzebne zamiast lub dodatkowo? |
|---|---|---|
| Transfer domeny do innego rejestratora | Tak | Może być potrzebne odblokowanie i dodatkowe potwierdzenie |
| Zmiana serwerów nazw albo rekordów DNS | Nie | Dostęp do strefy DNS lub panelu rejestratora |
| Przeniesienie strony na inny hosting | Nie | Kopia plików i bazy oraz zmiana DNS |
| Zmiana dostawcy poczty | Nie | Zmiana rekordów MX, SPF, DKIM i ewentualnie DMARC |
| Odnowienie domeny u obecnego rejestratora | Nie | Opłacenie kolejnego okresu |
| Przekazanie domeny na inne konto u tego samego operatora | Zależy od rejestratora | Wewnętrzna procedura push lub zmiany abonenta |
| Sprzedaż domeny | Może być potrzebny na etapie transferu | Umowa, bezpieczna płatność i prawidłowa zmiana abonenta |
| Udowodnienie kontroli nad domeną | Nie | Bezpieczniejszy jest np. uzgodniony rekord TXT w DNS |
Jeśli wykonawca chce wyłącznie skonfigurować stronę, certyfikat, analitykę albo pocztę, prośba o kod transferowy powinna wzbudzić czujność. Do tych zadań zwykle wystarcza ograniczony dostęp techniczny.
Jak wygląda transfer domeny .pl z kodem AuthInfo?
W przypadku domeny .pl kod uzyskuje się od aktualnego rejestratora zgodnie z jego jawną procedurą. Może ona obejmować panel, podpisany wniosek lub dodatkową weryfikację abonenta. NASK wskazuje, że rejestrator na żądanie abonenta ma niezwłocznie wydać kod i nie może uzależnić jego wydania od dodatkowych warunków, w tym uiszczenia opłaty. Szczegóły opisują
prawa abonenta domeny .pl
.
Typowy proces wygląda następująco:
- Abonent wybiera nowego rejestratora i poznaje jego procedurę transferu.
- U aktualnego rejestratora pobiera albo zamawia kod AuthInfo.
- Przekazuje kod nowemu rejestratorowi w jego autentycznym panelu lub formularzu.
- Nowy rejestrator inicjuje przejęcie obsługi domeny.
- Na adres e-mail abonenta zapisany w rejestrze trafia wiadomość z linkiem.
- Abonent sprawdza dane i kończy transfer przez potwierdzenie.
- Po operacji weryfikuje nowego rejestratora, delegację DNS, DNSSEC, datę odnowienia oraz zabezpieczenia.
NASK informuje, że inicjowanie transferu domeny .pl jest możliwe najwcześniej po 5 dniach od jej rejestracji lub ostatniego transferu. Ważny jest też aktualny e-mail abonenta, ponieważ to na niego wysyłany jest link kończący procedurę. Bieżące kroki publikuje
Krajowy Rejestr Domen .pl w instrukcji transferu
.
Transfer domeny .pl zmienia rejestratora, a nie abonenta. Jeżeli domena jest sprzedawana, strony muszą osobno dopilnować prawidłowej zmiany abonenta zgodnie z procedurą operatora. Kod AuthInfo nie zastępuje umowy i nie dowodzi, że osoba, która go zna, jest uprawniona do sprzedaży adresu.
Transfer domen globalnych gTLD
Przy domenach takich jak .com, .net czy .org zastosowanie mają zasady ICANN oraz regulaminy rejestru i obu rejestratorów. Abonent zwykle:
- sprawdza, czy domena może zostać przeniesiona,
- usuwa blokadę transferu, jeśli jest aktywna,
- pobiera Auth-Code,
- rozpoczyna transfer u nowego rejestratora,
- wykonuje wymagane potwierdzenia,
- monitoruje komunikaty obu operatorów do zakończenia procesu.
Aktualna Transfer Policy ICANN przewiduje między innymi możliwość odmowy transferu w pierwszych 60 dniach po utworzeniu domeny lub po poprzednim transferze. Blokada może też wystąpić po zmianie registranta, przy trwającym sporze albo na podstawie decyzji właściwego organu. Sam prawidłowy kod nie omija tych ograniczeń.
Jeśli panel nie pozwala samodzielnie utworzyć kodu, rejestrator gTLD powinien przekazać go abonentowi w ciągu pięciu dni kalendarzowych od żądania. Podobny termin dotyczy zdjęcia statusu clientTransferProhibited, gdy nie ma funkcji samoobsługowej. Nie należy jednak przenosić tych zasad automatycznie na każde rozszerzenie krajowe. Dla .pl, .eu czy innych ccTLD właściwe są reguły ich rejestrów.
Dlaczego prawidłowy kod nie zawsze wystarcza?
Transfer może nie ruszyć albo zostać odrzucony mimo wpisania poprawnego AuthInfo. Najczęstsze przyczyny to:
- aktywna blokada transferu u rejestratora,
- Registry Lock na poziomie rejestru,
- zbyt krótki czas od rejestracji albo poprzedniego transferu,
- blokada po zmianie abonenta lub registranta,
- nieaktualny e-mail potrzebny do potwierdzenia,
- domena wygasła albo znajduje się w szczególnym etapie cyklu życia,
- trwający spór, postępowanie lub nakaz blokujący operację,
- kod został zmieniony, unieważniony albo błędnie skopiowany,
- zasady konkretnego rozszerzenia wymagają innego trybu,
- transfer rozpoczęto dla innej domeny, np. podobnego zapisu IDN.
Przed ponownym generowaniem kodu warto sprawdzić status domeny, komunikaty obu rejestratorów i skrzynkę abonenta. Przy domenie z DNSSEC trzeba też ustalić, czy nowy rejestrator prawidłowo obsłuży rekordy DS. Źle zaplanowany transfer może nie odebrać abonentowi domeny, ale może przerwać rozwiązywanie nazwy.
Jak bezpiecznie uzyskać i przechowywać kod AuthInfo?
AuthInfo powinien być traktowany jak sekret o krótkim cyklu życia, a nie stała informacja wpisana do firmowego arkusza. Najbezpieczniej pobrać go dopiero wtedy, gdy wybrano nowego rejestratora, sprawdzono możliwość transferu i wyznaczono osobę odpowiedzialną za operację.
Pobieraj kod z właściwego miejsca
Zaloguj się przez zapisany adres rejestratora lub ręcznie otwartą stronę. Nie przechodź do panelu z linku w wiadomości informującej o „pilnej migracji”. Jeśli kod wymaga wniosku, korzystaj z danych kontaktowych opublikowanych przez operatora, nie z numeru przesłanego przez nieznaną osobę.
Ogranicz czas i liczbę osób mających dostęp
Kod powinien znać abonent lub wskazany administrator prowadzący transfer. Nie rozsyłaj go całemu zespołowi „na wszelki wypadek”. W firmie warto wymagać akceptacji dwóch osób przed zdjęciem blokady i wydaniem AuthInfo dla domeny krytycznej.
Użyj menedżera haseł albo sejfu sekretów
Jeżeli kod musi zostać zapisany na czas operacji, umieść go w kontrolowanym menedżerze haseł lub firmowym sejfie sekretów. Dostęp powinien być imienny, czasowy i rejestrowany. Sam dziennik operacji może zawierać informację, kto i kiedy pobrał kod, ale nie jego jawną wartość.
Nie zapisuj AuthInfo:
- w ogólnodostępnym arkuszu z listą domen,
- w zadaniu systemu projektowego widocznym dla wielu osób,
- na zrzucie ekranu panelu,
- w notatniku bez szyfrowania,
- w publicznym repozytorium albo pliku konfiguracyjnym,
- w historii rozmowy z przypadkowym wykonawcą,
- w dokumentacji dołączanej do ofert i wycen.
Zabezpiecz konto rejestratora i pocztę
Poufny kod nie pomoże, jeśli atakujący może zalogować się do panelu i wygenerować nowy. Konto u rejestratora oraz skrzynka abonenta powinny mieć unikalne hasła i MFA. Dla ważnej domeny warto włączyć alerty o logowaniu, blokadę transferu, dodatkową akceptację zmian, a jeśli rejestr to umożliwia — Registry Lock.
Szerszy model ochrony opisujemy w poradniku jak zabezpieczyć domenę przed przejęciem .
Usuń sekret po zakończeniu albo anulowaniu operacji
Po udanym transferze sprawdź, czy po stronie nowego rejestratora obowiązuje nowy kod i ponownie włącz dostępne blokady. Jeżeli transfer odwołano, kod został wysłany błędnej osobie albo pojawił się na zrzucie ekranu, poproś o jego zmianę lub unieważnienie. Nie zakładaj, że brak natychmiastowej próby transferu oznacza brak ryzyka.
Komu można przekazać kod AuthInfo?
Kod przekazuje się nowemu, zweryfikowanemu rejestratorowi w ramach świadomie rozpoczętego transferu. Może to nastąpić przez jego panel albo kontrolowany proces marketplace’u lub operatora transakcji, jeżeli dokładnie wiadomo, kto przetwarza kod i w jakim celu.
Przy sprzedaży domeny kolejność jest szczególnie ważna. Sprzedający nie powinien wysyłać kodu potencjalnemu kupującemu podczas wyceny, negocjacji ani jako dowodu kontroli. Najpierw strony ustalają warunki i zabezpieczają środki, a dopiero potem uruchamiają uzgodnioną procedurę przekazania. Pomaga w tym escrow przy zakupie domeny .
Broker, agencja SEO, hostingodawca, programista albo administrator poczty nie potrzebują AuthInfo tylko dlatego, że pracują nad serwisem. Jeśli transfer nie jest częścią zlecenia, należy zapytać, po co żądają kodu i wybrać dostęp ograniczony do rzeczywistego zadania.
Najczęstsze błędy przy przekazywaniu kodu osobom trzecim
1. Wysłanie kodu przed zabezpieczeniem płatności
Osoba zainteresowana zakupem przekonuje, że potrzebuje AuthInfo do „sprawdzenia transferowalności”. Takiej weryfikacji nie wykonuje się przez wydanie sekretu. Status domeny, rejestratora i część blokad można sprawdzić bez niego, a kontrolę sprzedającego potwierdzić np. uzgodnionym rekordem TXT.
2. Uznanie kodu za dowód własności
Kod może znać pracownik, były administrator, agencja albo osoba, która przejęła konto. Nie potwierdza prawa do zawarcia umowy. Przy zakupie domeny trzeba osobno zweryfikować abonenta, reprezentację sprzedającego i prawidłową procedurę zmiany abonenta. Więcej kroków zawiera poradnik jak kupić domenę od obecnego właściciela .
3. Przekazanie kodu zamiast dostępu do DNS
Wykonawca ma podłączyć hosting lub pocztę, ale otrzymuje AuthInfo. To uprawnienie nieadekwatne do zadania. Lepszy jest dostęp tylko do strefy DNS, najlepiej z oddzielnym kontem i historią zmian.
4. Wklejenie kodu na stronie z wiadomości
Fałszywy rejestrator może wysłać komunikat o wygaśnięciu, blokadzie lub obowiązkowym potwierdzeniu danych. Link prowadzi do kopii panelu, która zbiera login, hasło i AuthInfo. Prawdziwy transfer należy rozpocząć samodzielnie u wybranego operatora.
5. Wysłanie pełnego zrzutu ekranu
Na obrazie obok kodu mogą znaleźć się dane abonenta, identyfikator konta, lista innych domen i informacje odzyskiwania. Jeśli obsługa rzeczywiście prosi o dokumentację błędu, kod oraz wszystkie zbędne dane trzeba zamaskować.
6. Pozostawienie domeny odblokowanej na długo
Zdjęcie blokady kilka tygodni przed transferem zwiększa okno ryzyka. Odblokowanie, pobranie kodu i inicjacja powinny tworzyć jeden zaplanowany proces. Po zakończeniu zabezpieczenia trzeba ponownie sprawdzić.
7. Brak drugiego kanału weryfikacji
Polecenie przekazania kodu może pochodzić z przejętej skrzynki prezesa, klienta lub administratora. Dla strategicznej domeny potwierdź żądanie przez wcześniej znany kanał i stosuj zasadę dwóch osób.
Co zrobić, gdy kod AuthInfo wyciekł?
Nie czekaj na powiadomienie o zakończonym transferze. Szybka reakcja może przerwać próbę, zanim domena zmieni rejestratora.
- Wejdź do panelu rejestratora przez znany, samodzielnie wpisany adres.
- Zmień, zregeneruj albo unieważnij AuthInfo, jeśli panel na to pozwala.
- Włącz blokadę transferu lub poproś rejestratora o zabezpieczenie domeny.
- Sprawdź oczekujące transfery, statusy domeny, dane abonenta i historię zmian.
- Skontaktuj się z rejestratorem przez uwierzytelniony kanał i opisz incydent.
- Zmień hasła do panelu i powiązanej poczty, włącz MFA oraz zakończ obce sesje.
- Sprawdź delegację, rekordy DNS i alerty bezpieczeństwa.
- Zachowaj wiadomości, logi i zrzuty jako dowody, ale nie rozpowszechniaj kodu dalej.
Jeżeli transfer został już wykonany bez zgody abonenta, trzeba natychmiast uruchomić procedurę awaryjną u rejestratora. Dokładne kroki i terminy zależą od rozszerzenia, dlatego ogólna korespondencja z kupującym lub wykonawcą nie zastąpi formalnego zgłoszenia.
Checklista przed użyciem kodu AuthInfo
Przed wpisaniem kodu u nowego operatora sprawdź:
- Czy transfer rejestratora jest naprawdę celem operacji?
- Czy wybrana strona należy do właściwego nowego rejestratora?
- Czy nazwa i rozszerzenie domeny są poprawne, także w zapisie IDN?
- Czy obecny e-mail abonenta jest aktualny i zabezpieczony?
- Czy domena nie jest objęta blokadą albo okresem uniemożliwiającym transfer?
- Czy nowy rejestrator obsłuży DNSSEC i pozostałe wymagane ustawienia?
- Czy wiadomo, kto akceptuje operację i kto ją nadzoruje?
- Czy przy sprzedaży środki zostały rzeczywiście zabezpieczone?
- Czy ustalono osobno zmianę abonenta, jeśli jest potrzebna?
- Czy po operacji ktoś sprawdzi domenę, DNS, odnowienie i ponowne blokady?
Wnioski
Kod AuthInfo jest cyfrowym sekretem służącym do transferu domeny między rejestratorami. Nazwa „kod EPP” jest powszechna i zrozumiała, ale technicznie EPP oznacza cały protokół, a nie sam kod. AuthInfo nie przenosi strony, poczty ani praw do domeny i nie zastępuje dodatkowych potwierdzeń.
Bezpieczna praktyka jest prosta: pobierz kod dopiero przed zaplanowanym transferem, przekaż go wyłącznie zweryfikowanemu nowemu rejestratorowi, a po zakończeniu albo anulowaniu operacji zmień sekret i przywróć blokady. Przy sprzedaży domeny najpierw zabezpiecz transakcję i prawidłową zmianę abonenta. Samo posiadanie kodu nigdy nie powinno być podstawą wypłaty pieniędzy ani uznania własności.
FAQ
Co to jest kod AuthInfo?
To poufny kod autoryzacyjny przypisany do domeny, używany przede wszystkim podczas transferu jej obsługi od jednego rejestratora do drugiego. Można spotkać też nazwy Auth-Code, transfer code, klucz transferowy i kod EPP.Czy kod EPP i AuthInfo oznaczają to samo?
W panelach rejestratorów najczęściej tak — „kod EPP” jest popularną nazwą kodu AuthInfo. Technicznie EPP to protokół komunikacji rejestratora z rejestrem, a AuthInfo jest informacją autoryzacyjną wykorzystywaną w jego operacjach.Gdzie można uzyskać kod AuthInfo?
U aktualnego rejestratora domeny: w panelu klienta albo przez opisaną przez niego procedurę weryfikacji. Kod otrzymuje uprawniony abonent, nie nowy hostingodawca ani przypadkowa osoba zainteresowana zakupem.Czy kod AuthInfo jest potrzebny do transferu domeny
.pl?
Tak. Nowy rejestrator używa go do zainicjowania przejęcia obsługi, a abonent kończy transfer przez link wysłany na jego adres e-mail zapisany w rejestrze. Transfer rejestratora nie zmienia abonenta domeny.pl.Czy AuthInfo jest potrzebny do zmiany hostingu lub DNS?
Nie. Migracja strony, zmiana serwerów nazw, rekordów DNS albo dostawcy poczty nie wymagają kodu transferowego, o ile domena pozostaje u obecnego rejestratora.Jak długo kod AuthInfo jest ważny?
Zależy to od rozszerzenia, rejestru i rejestratora. Kod może mieć określony termin, obowiązywać do zmiany albo zostać unieważniony po użyciu. Nie przechowuj go „na zapas”; sprawdź bieżące zasady swojego operatora.Czy sprzedający powinien wysłać AuthInfo przed otrzymaniem pieniędzy?
Nie. Najpierw należy zweryfikować strony, ustalić warunki i zabezpieczyć płatność, np. przez właściwie wybraną usługę escrow. Kod przekazuje się dopiero na uzgodnionym etapie kontrolowanego procesu.Co zrobić po ujawnieniu kodu niewłaściwej osobie?
Natychmiast zmień lub unieważnij kod, włącz blokadę transferu, sprawdź oczekujące operacje i skontaktuj się z rejestratorem. Zabezpiecz także konto oraz e-mail abonenta i przejrzyj historię zmian.Dlaczego transfer nie działa mimo poprawnego kodu?
Przyczyną może być blokada transferu, zbyt krótki czas od rejestracji lub poprzedniego transferu, Registry Lock, nieaktualny e-mail, szczególny status domeny, spór albo dodatkowe wymagania właściwego rejestru.