Rejestrator i autorytatywny operator DNS rozwiązują różne problemy. Rejestrator zarządza relacją rejestracyjną domeny i zazwyczaj elementami sterującymi używanymi do zmiany jej delegacji. Operator autorytatywny udostępnia rekordy, do których wysyłają zapytania systemy pocztowe. Wiedza o tym, która firma widnieje w danych rejestracyjnych, nie identyfikuje każdej osoby, która może edytować strefę.
Zadaj właściwe pytanie dotyczące własności
Referencje: RFC 1034 §4.2, RFC 4034 §5.
Aby odnowić lub przenieść rejestrację, wskaż rejestratora i autoryzowanego właściciela konta organizacji. W przypadku zmiany TXT zidentyfikuj aktywną strefę autorytatywną i jej konto edycyjne. Dla DNSSEC awaria, obie strony mogą być potrzebne, ponieważ zarządzanie DS przez rodziców i podpisywanie podrzędne mogą znajdować się w różnych systemach.
Organizacja może korzystać z połączonej rejestracji i DNS , a sprzedawca niestandardowy serwery nazw lub oddzielną zarządzaną usługę DNS . Nawet jeśli RDAP wymienia jednego rejestratora, a nazwy DNS sugerują innego dostawcę, żadna obserwacja sama w sobie nie ustanawia odpowiedzialności umownej ani uprawnień dostępu.
Przeczytaj RDAP jako dowód o określonym zakresie
Referencje: RFC 9083 §4.2, RFC 9083 §4.3, RFC 9083 §4.5, RFC 9083 §5.1, RFC 9083 §5.3, RFC 9083 §9.
RDAP zapewnia uporządkowane informacje rejestracyjne. RFC 9083 definiuje elementy odpowiedzi, takie jak nazwy domen, podmioty, role, zdarzenia, serwery nazw, łącza, powiadomienia i uwagi. Redakcja dotycząca prywatności lub ograniczone ujawnienie może oznaczać, że brak kontaktu publicznego nie mówi nic o tym, czy istnieje prywatny odpowiedzialny właściciel.
Zapisz punkt końcowy wyszukiwania, końcowy adres URL, czas UTC, status odpowiedzi i odpowiednie pola. Zachowaj powiadomienia i uwagi kwalifikujące odpowiedź. Zdarzenia należy interpretować na podstawie ich eventAction, a nie traktować każdy znacznik czasu jako rejestrację lub wygaśnięcie. Podana rola podmiotu stanowi dowód zwróconej roli rejestracyjnej, a nie dowód, że kontroluje on dzierżawcę poczty e-mail lub edytor DNS .
Porównaj ścieżki rejestracyjne i operacyjne
Referencje: RFC 1034 §4.2, RFC 9083 §5.3.
Uzyskaj odpowiedź domeny RDAP ze znacznikiem czasu za pośrednictwem udokumentowanej usługi rejestru lub zweryfikowanego narzędzia wyszukiwania. Oddzielnie śledź delegację DNS i wysyłaj zapytania do bieżących władz o NS, SOA i wymagany rekord poczty. Zestaw obserwacje obok siebie: zgłoszone przez rejestratora, serwery nazw zgłoszone przez RDAP, serwery nazw faktycznie odesłane przez DNS i właściciel konta organizacji potwierdzony wewnętrznie.
Syntetyczny przykład dotyczy rejestratora R w RDAP, serwerów nazw pod operatorem D w odniesieniu do DNS i skrzynek pocztowych u dostawcy M. Prawidłowe działanie polega na opublikowaniu uwierzytelniającego DNS za pośrednictwem zweryfikowanego konta D, uzyskaniu wartości specyficznych dla poczty od M i użyciu R do rejestracji lub zmian delegowania nadrzędnego, jeśli ma to zastosowanie. Przykład nie wykazuje, że usługi jakiejkolwiek prawdziwej firmy są zgodne z tym układem.
Opisz to, co pozostaje nieznane
Kompletny arkusz dowodów zawiera zredagowane pola, brakujące przypisania kontaktu, możliwe relacje ze sprzedawcami oraz różnicę między obserwacją a zweryfikowanym dostępem do konta. Poniżej zamieszczono publiczną odpowiedź RDAP z domeny przykładowej; uzyskanie odpowiedzi i dowodów dotyczących konta wewnętrznego dla faktycznej domeny wdrożenia pozostaje odrębnym zadaniem.
Trzymaj rutynowe zmiany DNS oddzielnie od przeniesienia rejestratora, zmian własności i zmian konta wrażliwych na bezpieczeństwo. Prośba o diagnozę rekord nie wymaga przenoszenia domeny. Przekaż wiadomość właściwemu właścicielowi wewnętrznemu, podając dokładny rekord i wymagane działania, a następnie zweryfikuj uzyskane wiarygodne dane i zachowanie poczty. Zachowaj mapę ról, aby następny incydent nie zaczął się od tego samego przypuszczenia, że jesteś właścicielem.
Zachowane publiczne obserwacje RDAP
Zachowany zapis z dnia 7 listopada 2026 r., sprawdzony, ale nie powtórzony na potrzeby tej recenzji, wskazuje, że prawdziwe żądanie HTTPS skierowane do Verisign .com Punkt końcowy domeny RDAP dla example.com zwrócił HTTP 200 na znaczniku czasu zachowanym w rejestrze dowodów. Pełny kod JSON obejmuje domenę, jednostkę, zdarzenie, serwer nazw, bezpieczneDNS i pola powiadomień. To jest zarezerwowana domena przykładowa, a nie domena należąca do użytkownika. Adnotacje wyraźnie oddzielają role rejestracyjne od dostępu do edytora DNS, zachowują powiadomienia serwera i zaznaczają potrzebę porównania zwróconych serwerów nazw z rzeczywistymi odwołaniami DNS . Z tej odpowiedzi nie wynikają żadne wnioski dotyczące własności użytkownika, dostępu do logowania do rejestratora ani tożsamości dostawcy poczty.
Zachowaj wyraźny zakres dowodów
Zarchiwizowane przechwytywanie HTTP identyfikuje historyczny punkt końcowy, status i czas UTC, a niezmodyfikowana odpowiedź zostaje zachowana. Jego metadane rejestracyjne nie weryfikują aktualnego działania DNS , uprawnień umownych ani dostępu do konta. Uzyskaj aktualne, autoryzowane dowody przed rzeczywistą zmianą.