Przed oceną propozycji przeczytaj datę statusu
Ramy polityki relacji domenowych oferują sposób, w jaki domeny mogą opisywać i wzajemnie potwierdzać relacje. Mogłoby to zapewnić stronie ufającej bardziej wyraźne informacje niż podobne logo, wspólny projekt strony internetowej lub domniemane powiązanie korporacyjne. To, czy takie informacje powinny wpłynąć na decyzję o wysłaniu wiadomości e-mail, zależy od jej uprawnień, zasad walidacji i zachowań konsumentów, a nie tylko od ich publikacji.
Projekt strona stanu, skontrolowany w dniu 9 listopada 2026 r., wyraźnie datuje swój status na 1 lipca 2024 r. Opisuje proponowane ramy do rozpatrzenia publicznego i jako kolejny krok wymienia opisową wersję projektu internetowego. Daty te muszą pozostać oddzielne: czytelna strona dzisiaj nie oznacza, że jej status jest aktualny. Na potrzeby tej oceny nie zweryfikowano żadnego późniejszego ostatecznego statusu projektu, wyników standardów ani przyjęcia odbiorcy.
The stronę główną projektu opisuje rozwój ad hoc i potwierdza brakujące szczegóły wdrożenia. A Konto programisty z lutego 2024 r. autorstwa J. Trenta Adamsa podobnie nazywa tę pracę wczesną propozycją. Jej język dotyczący normalizacji należy czytać w tym kontekście. W tym artykule dokonano oceny tego udokumentowanego modelu; nie ogłasza wdrożonego standardu ani nie zaleca produkcyjnych rekordów DNS .
Oddziel mechanizm wykrywania od znaczenia polityki
Proponowane architektura zawiera małe potwierdzenia DNS TXT i, w razie potrzeby, bogatsze dokumenty dotyczące zasad. Asercje mogą wyrażać podstawowe relacje lub pomagać w odkrywaniu szczegółowych zasad. Dokumenty odróżniają metadane od treści polityki i pozwalają słownikom opisywać różne rodzaje relacji. Duża część pracy związanej z interpretacją należy do strony ufającej.
To oddzielenie jest ważne. Znalezienie dokumentu nie oznacza, że dwóch konsumentów identycznie interpretuje jego słownictwo. Konsument potrzebowałby uzgodnionego profilu ocenianej relacji, w tym obsługiwanych warunków i zachowań w przypadku nieznanych warunków. Dostępne strony ilustrują możliwości, a nie ustanawiają jedną kompletną, interoperacyjną gramatykę. Ich różne opisy minimalnej zawartości stwierdzeń nie powinny być po cichu przekształcane w wymyślony obowiązkowy format.
Jedno z wyjaśnień architektonicznych wymaga również kwalifikacji DNS . RFC 1035 sekcje 3.3 i 3.3.14 zdefiniuj dane TXT jako jeden lub więcej ciągów znaków, każdy o długości jednego oktetu. Granica treści wynosząca 255 oktetów dotyczy pojedynczego ciągu, a nie uniwersalnego maksimum 255 znaków dla całego rekordu zasobu TXT . Ta poprawka nie uwzględnia brakującego profilu publikacji lub analizowania DRPF.
Zbadaj wzajemne potwierdzenie jako konkretne roszczenie
Konto programisty opisuje potwierdzenie w obie strony: potwierdzenie nazwy innej domeny powinno mieć odpowiednie oświadczenie z tej domeny. Podważa to jednostronne roszczenie o stowarzyszenie. Nie ustala samodzielnie własności prawnej, integralności kont obu administratorów ani bezpieczeństwa instrukcji płatniczej otrzymanej e-mailem.
Osoba oceniająca powinna określić, jaki organ faktycznie kontroluje każdy wydawca i jakie dowody chronią przed wyszukiwaniem. Dwa wzajemnie spójne oświadczenia z zaatakowanych systemów pozostają innym problemem niż jedna domena zgłaszająca nieuzasadnione twierdzenie. Przegląd bezpieczeństwa wymaga zatem modelu zagrożeń, założeń autentyczności i określonej obsługi błędów. Są to wymagania dotyczące oceny, a nie możliwości zaprezentowane w propozycji lub wdrożeniu przetestowanym na potrzeby tego artykułu.
Zamapuj od początku do końca fikcyjną relację z marką
Rozważmy fikcyjne domeny brand.example i parent.example . Administrator marki opublikuje stwierdzenie podrzędne; administrator nadrzędny opublikuje odpowiednie potwierdzenie. Hipotetyczną aplikacją zabezpieczającą byłby konsument. Jego proponowanym zadaniem jest porównanie dwóch skierowanych instrukcji dla tej samej relacji, przy jednoczesnym oddzieleniu żądanego powiązania biznesowego od uwierzytelniania wiadomości.
Projekt przypadek użycia powiązanej domeny ilustruje dwa podejścia do odkrywania. Konsument może poznać polisę rodzica poprzez oświadczenie rodzica lub skorzystać z lokalizacji polisy podanej bardziej bezpośrednio przez dziecko. Strona ilustruje również ustrukturyzowany dokument JSON-LD. Są to przykłady koncepcyjne, a nie dowód na to, że wymienione firmy wdrażają DRPF lub że ich przykładowe etykiety tworzą stabilny format drutu.
Na potrzeby tej fikcyjnej mapy konsument zapisywał, jakie dokumenty i interpretacje potwierdzały relację w danym momencie. Gdyby rodzic wycofał bierzmowanie, w związku nie byłoby już takiego samego wzajemnego wsparcia. Dla tych fikcyjnych domen nie opublikowano ani nie pobrano żadnego rekordu, nie testowano żadnego analizatora składni, sprawdzania poprawności podpisu ani zachowania strony ufającej.
Wymagaj cyklu życia wykraczającego poza możliwość wycofania się
Architektura opisuje zerwanie relacji poprzez zmianę jej potwierdzenia. Jest to przydatny koncepcyjny mechanizm odstąpienia od umowy, ale nie wszędzie powoduje on natychmiastowe wycofanie. Twierdzenia zapisane w pamięci podręcznej, zachowane dokumenty dotyczące zasad i tymczasowo niedostępni wydawcy wymagają wyraźnej obsługi, zanim konsument będzie mógł podjąć wiarygodne decyzje.
Recenzent powinien zadać sobie pytanie, jak długo dowody pozostają przydatne, co się dzieje, gdy zmienia się tylko jedna strona i czym niedostępna polisa różni się od zamierzonego wycofania się. Odbudowa sytuacji po kompromisie wydawcy i sprzecznych łańcuchach zasad również wymaga określonych wyników. Pytania te powinny skutkować udokumentowanymi zasadami cyklu życia i autoryzowanymi testami, a nie optymistycznymi założeniami, że wzajemna publikacja rozwiązuje każdą kolejną zmianę stanu.
Oddziel uwierzytelnianie e-mailem od zatwierdzania biznesowego
Zadeklarowany stosunek administracyjny pomiędzy dwiema odrębnymi domenami nie ulega zmianie DMARC wyrównanie samodzielnie. RFC 9989 sekcja 4.4 definiuje dopasowanie między uwierzytelnionymi identyfikatorami a domeną autora. Twierdzenie dotyczące relacji nie zmienia niepowiązanego podpisu przekazującego w zgodny, a ta ocena nie ustanawia żadnej reguły odbiorcy, która traktuje DRPF jako wyjątek.
Podobnie nie wykazano żadnych korzyści z umieszczenia w skrzynce odbiorczej, odziedziczonej reputacji ani upoważnienia do płacenia dostawcy. Jeśli przyszły konsument korzysta z informacji o związku, udokumentuj konkretną decyzję, na którą ma to wpływ, i zachowaj niezależną kontrolę uwierzytelniania wiadomości i zatwierdzania przez firmę. Ewentualny przyszły sygnał nie powinien po cichu stać się wpisem na listę dozwolonych ani powodem do osłabienia istniejącej polityki.
Zapisz to, co pozostaje niepotwierdzone
Proponowana mapa relacji jest dostarczana jako artefakt analityczny, natomiast wymaganie dotyczące statusu pozostaje otwarte. Dokładne wymagania są następujące: Zamapuj jedną proponowaną relację, jej wydawcę, konsumenta, model sprawdzania poprawności i unieważniania; potwierdzić aktualny status projektu. Bramka do uruchomienia to: Sprawdź bieżący projekt i status przyjęcia. Opisz propozycję, nie przedstawiając jej jako przyjętego standardu IETF .
Połączone konto społecznościowe i wyszukiwanie Datatracker były niedostępne i nie zostały ponowione ani pominięte. Nieobecność w poszukiwaniu nie może dowodzić, że nie istnieje żadne późniejsze dzieło. Potwierdzenie aktualnego statusu, przegląd specjalistyczny, testy wdrożeniowe i interoperacyjności, przegląd prezentacji na żywo i zatwierdzenie przez właściciela są nadal potrzebne przed mocniejszymi wnioskami lub publikacją.