Τι είναι το Πρωτόκολλο Πρόσβασης σε Δεδομένα Εγγραφής (RDAP);
Μέχρι τώρα, η ταυτοποίηση του κατόχου ενός domain ήταν δυνατή με τη βοήθεια των υπηρεσιών Whois, οι οποίες βασίζονται στο ομώνυμο πρωτόκολλο. Ωστόσο, το 2015, η IETF και η ICANN καθιέρωσαν το πρώτο RFC του πρωτοκόλλου RDAP (Registration Data Access Protocol) ως τον κύριο διάδοχο του Whois.
Τι είναι το Πρωτόκολλο Πρόσβασης σε Δεδομένα Εγγραφής (RDAP);
Η ιδέα του Πρωτοκόλλου Πρόσβασης σε Δεδομένα Εγγραφής (RDAP) προήλθε από μια ομάδα εργασίας της Ομάδας Εργασίας Μηχανικών Διαδικτύου (IETF). Μετά από μια φάση έργου που διήρκεσε σχεδόν τέσσερα χρόνια, η πρώτη έκδοση του προφίλ πρωτοκόλλου (1.0) κυκλοφόρησε στις 26 Ιουλίου 2016. Τα χαρακτηριστικά και οι εφαρμογές του περιγράφονται στα διάφορα Requests for Comments (RFC 7480-7484 και RFC 8056). Το RDAP προσφέρει τη δυνατότητα πρόσβασης σε περαιτέρω πληροφορίες σχετικά με βασικούς πόρους του Διαδικτύου, συμπεριλαμβανομένων
- Ονόματα τομέα
- Διευθύνσεις IP ή
- Αριθμοί αυτόνομων συστημάτων (ASN)
καθώς και άλλα σχετικά άρθρα. Για τον λόγο αυτό, η εναλλακτική λύση Whois αποτελεί τη βάση για την αποστολή ερωτημάτων στα διάφορα μητρώα ονομάτων χώρου. Αυτό περιλαμβάνει την παροχή στη βάση δεδομένων σας, για παράδειγμα, των στοιχείων επικοινωνίας των κατόχων ονομάτων χώρου, των στοιχείων επικοινωνίας τυχόν διαχειριστών (Admin C) ή ακόμη και της διεύθυνσης του διακομιστή ονομάτων που χρησιμοποιείται, συμπεριλαμβανομένης της διεύθυνσης του διαχειριστή.
Γιατί δημιουργήθηκε το RDAP;
Το 1982, η IETF δημοσίευσε το πρωτόκολλο Whois με στόχο τη δημιουργία μιας υπηρεσίας αναζήτησης για το δίκτυο που τότε ονομαζόταν ARPANET. Το γεγονός ότι εξακολουθεί να χρησιμοποιείται ένα τέταρτο του αιώνα αργότερα, πλέον για διαδικτυακές αναζητήσεις, αποτελεί πηγή ενόχλησης για πολλούς ειδικούς. Σήμερα, η κύρια κριτική που ασκείται στο Whois είναι ότι δεν ανταποκρίνεται πλέον στις τεχνικές απαιτήσεις του Διαδικτύου.
Ένα από τα κύρια προβλήματα είναι ότι το πρωτόκολλο Whois δεν υποστηρίζει κωδικοποιήσεις και, ως εκ τούτου, δεν παρέχει υποστήριξη για κείμενο σε μη λατινικούς χαρακτήρες. Ένα άλλο σημαντικό μειονέκτημα είναι ότι η πρόσβαση στα δεδομένα του domain δεν πραγματοποιείται μέσω ασφαλούς σύνδεσης και δεν υπόκειται σε ρυθμίσεις. Ακόμη και οι ανώνυμοι χρήστες έχουν πλήρη πρόσβαση και μπορούν να αποκτήσουν πρόσβαση σε διευθύνσεις ηλεκτρονικού ταχυδρομείου και ταχυδρομικές διευθύνσεις.
Έργα όπως η επέκταση Whois++ ή το πρωτόκολλο IRIS (Internet Registry Information Service) της Denic κατάφεραν να επιφέρουν ορισμένες βελτιώσεις, ωστόσο δεν κατάφεραν να εδραιωθούν ως μια αξιόπιστη εναλλακτική λύση έναντι του Whois. Μετά από πολύ καιρό και πολλές συζητήσεις εντός της κοινότητας της ICANN σχετικά με την ανάγκη για περαιτέρωανάπτυξη**, η Συμβουλευτική Επιτροπή Ασφάλειας και Σταθερότητας (SSAC) με την έκθεση ασφάλειας SAC 501 έδωσε την αποφασιστική ώθηση για τη δημιουργία της ομάδας εργασίας RDAP τον Σεπτέμβριο του 2011.
Τον Ιανουάριο του 2023, η ICANN προκήρυξε παγκόσμια ψηφοφορία για να αποφασιστεί αν θα αντικατασταθεί επίσημα το WHOIS με το RDAP. Επιτεύχθηκε ο απαιτούμενος αριθμός ψήφων και αποφασίστηκε η επίσημη εφαρμογή της μετάβασης στο RDAP. Από τον Ιανουάριο του 2025, τα μητρώα DNS και οι καταχωρητές δεν θα υποχρεούνται πλέον να υποστηρίζουν το WHOIS.
Πώς λειτουργεί το RDAP;
Για την υλοποίηση του RDAP, είναι σημαντικό να κατανοήσουμε πρώτα τον τρόπο λειτουργίας του πρωτοκόλλου, τόσο από την πλευρά του πελάτη όσο και από την πλευρά του διακομιστή. Για τον σκοπό αυτό, αξίζει να ρίξουμε μια ματιά στα RFC 7480 έως 7484, όπου περιγράφεται λεπτομερώς μια ελάχιστη υλοποίηση του πρωτοκόλλου. Επιπλέον, υπάρχουν και άλλα RFC στα οποία περιγράφονται επεκτάσεις του πρωτοκόλλου RDAP. Στην επόμενη ενότητα, εξηγούμε συνοπτικά πώς λειτουργεί το πρωτόκολλο μέσω HTTPS, όπως περιγράφεται στο RFC 7840.
Για να διευκολύνει την εφαρμογή του πρωτοκόλλου για τους προγραμματιστές, η ICANN έχει δημοσιεύσει έναν Οδηγό Εφαρμογής του RDAP.
Τα καθήκοντα του πελάτη:
Η εφαρμογή του RDAP από την πλευρά του πελάτη δεν είναι καθόλου περίπλοκη. Το RDAP βασίζεται στο HTTP και, ως εκ τούτου, χρησιμοποιεί τις ήδη υπάρχουσες μεθόδους HTTP για τη μεταφορά δεδομένων. Οι πελάτες μπορούν να υποβάλλουν αιτήματα στον διακομιστή χρησιμοποιώντας τις μεθόδους GET και HEAD. Τόσο τα αιτήματα GET όσο και τα HEAD πρέπει να περιλαμβάνουν μια κεφαλίδα «Accept» που καθορίζει τους τύπους αρχείων JSON που δέχεται ο πελάτης.
Τα καθήκοντα του διακομιστή:
Η υλοποίηση είναι λίγο πιο περίπλοκη από την πλευρά του διακομιστή, καθώς ο διακομιστής πρέπει να καλύψει αρκετές ειδικές περιπτώσεις. Εάν το αίτημα είναι επιτυχές, ο διακομιστής πρέπει να επιστρέψει τα ζητούμενα δεδομένα στη ζητούμενη μορφή με κωδικό κατάστασης HTTP 200 (OK). Σε αιτήματα GET, ο διακομιστής πρέπει να απαντήσει με τα ζητούμενα δεδομένα ιδιοκτήτη, ενώ σε αιτήματα HEAD πρέπει να υποδείξει εάν διαθέτει δεδομένα για αυτόν τον τομέα.
Εάν γνωρίζει πού βρίσκονται τα ζητούμενα δεδομένα, αλλά δεν τα διαθέτει η ίδια, θα πρέπει να απαντήσει με έναν από τους κωδικούς κατάστασης 301, 302, 303 ή 307. Στη συνέχεια, η διεύθυνση URL όπου βρίσκονται τα δεδομένα αποστέλλεται μέσω της κεφαλίδας HTTP «Location».
Εάν ο διακομιστής δεν μπορεί να επεξεργαστεί το αίτημα επειδή τα ζητούμενα δεδομένα δεν είναι διαθέσιμα, θα πρέπει να απαντήσει με τον κωδικό κατάστασης 404 (Not Found). Εάν τα ζητούμενα δεδομένα υπάρχουν, αλλά ο διακομιστής δεν επιθυμεί να απαντήσει για κάποιον άλλο λόγο, θα πρέπει να απαντήσει με έναν κατάλληλο κωδικό κατάστασης από τη σειρά 400. Τα αιτήματα που περιέχουν σφάλματα και, ως εκ τούτου, δεν μπορούν να αναγνωριστούν ως αιτήματα RDAP θα πρέπει να απαντώνται με τον κωδικό κατάστασης 400 (Bad Request). Σε αυτή την περίπτωση, μπορούν να σταλούν πρόσθετες πληροφορίες στο σώμα της οντότητας HTTP.
Για πιο λεπτομερείς πληροφορίες σχετικά με τη διαδικασία, καθώς και για θέματα ασφάλειας και δυνατότητες επέκτασης του πρωτοκόλλου, μπορείτε να ανατρέξετε στα αντίστοιχα RFC. Οι σχετικοί σύνδεσμοι παρατίθενται παρακάτω.
- RFC 7840: Χρήση του HTTP
- RFC 7841: Υπηρεσίες ασφαλείας
- RFC 7842: Μορφή ερωτήματος
- RFC 7843: Απαντήσεις JSON
- RFC 7844: Εύρεση των έγκυρων δεδομένων εγγραφής
Τι κάνει το Πρωτόκολλο Πρόσβασης σε Δεδομένα Εγγραφής να ξεχωρίζει;
Από πολλές απόψεις, το RDAP αποδείχθηκε μια βελτιωμένη έκδοση του Whois. Η ομάδα εργασίας του IETF επικεντρώθηκε στα αδύνατα σημεία του παλαιού πρωτοκόλλου, δηλαδή έδωσε ιδιαίτερη έμφαση σε θέματα όπως η ασφάλεια, η δομή και η διεθνοποίηση του νέου πρωτοκόλλου αναζήτησης. Ως αποτέλεσμα, προέκυψαν διάφορα νέα χαρακτηριστικά, μεταξύ των οποίων:
- Δομημένη σημασιολογία αιτημάτων και απαντήσεων (συμπεριλαμβανομένων τυποποιημένων μηνυμάτων σφάλματος)
- Ασφαλής πρόσβαση στα ζητούμενα στοιχεία επικοινωνίας (π.χ. μέσω HTTPS)
- Δυνατότητα επέκτασης (π.χ. προσθήκη στοιχείων εξόδου)
- Μηχανισμός**«Bootstrapping»**(υποστηριζόμενος από την αναζήτηση κατάλληλου διακομιστή DNS με δικαιώματα διαχείρισης)
- Τυποποιημένη προώθηση ερωτημάτων
- Βασισμένο στο Web (HTTP) και συμβατό με REST
- Απλή μετατροπή των δεδομένων εξόδου
- Δυνατότητα χορήγησης διαφοροποιημένης πρόσβασης στα στοιχεία επικοινωνίας
Από πολλές απόψεις, το Πρωτόκολλο Πρόσβασης σε Δεδομένα Εγγραφής (RDAP) έχει αποδειχθεί πολύ πιο ευέλικτο από τον προκάτοχό του. Ενώ το Whois, ως πρωτόκολλο βασισμένο σε κείμενο, βασίζεται στο TCP και στη συγκεκριμένη θύρα TCP (43), το RDAP χρησιμοποιεί το πρότυπο ιστού HTTP ή ακόμη και το HTTPS. Αυτό σημαίνει ότι όλα τα δεδομένα παρέχονται σε μια τυποποιημένη, μηχανικά αναγνώσιμη μορφή JSON. Αυτό σημαίνει ότι, αφενός, το RDAP παρέχει μεγαλύτερη ελευθερία όσον αφορά τις ερωτήσεις δεδομένων, ενώ αφετέρου διευκολύνει τον προγραμματισμό υπηρεσιών ερωτήσεων που μπορούν να επικοινωνούν με τις διάφορες αρχές καταχώρισης, παράγοντας τα ζητούμενα δεδομένα σε διαφορετικές γλώσσες.
| RDAP | Whois |
|---|---|
| με βάση το HTTP | με βάση κείμενο |
| Τυποποιημένη μορφή JSON | Χωρίς σχήματα κωδικοποίησης |
| Τα δεδομένα εξόδου είναι αναγνώσιμα από μηχανές και μπορούν να μεταφραστούν με απλό τρόπο | Τα δεδομένα εξόδου είναι σε μορφή απλού κειμένου και, ως εκ τούτου, δεν μπορούν να υποστούν περαιτέρω αυτόματη επεξεργασία |
| Οι απαντήσεις αποστέλλονται αυτόματα σε άλλα μητρώα | Οι απαντήσεις δεν περιέχουν πληροφορίες σχετικά με το επόμενο μητρώο |
| Δυνατότητα καθορισμού δικαιωμάτων πρόσβασης για διαφορετικές ομάδες | Δεν είναι δυνατοί διαφορετικοί τύποι πρόσβασης στα δεδομένα |
Επιλογή διαφορετικών τρόπων πρόσβασης – παραμένει θέμα προς συζήτηση
Χωρίς αμφιβολία, μία από τις σημαντικότερες νέες λειτουργίες που ενσωματώθηκαν στο Πρωτόκολλο Πρόσβασης σε Δεδομένα Εγγραφής είναι η δυνατότητα καθορισμού διαφορετικών δικαιωμάτων πρόσβασης για μεμονωμένες ομάδες χρηστών. Αυτό επιτρέπει στον καταχωρητή να ρυθμίζει λεπτομερώς ποιος έχει πρόσβαση σε ποιες πληροφορίες. Έτσι, οι ανώνυμοι χρήστες έχουν μόνο περιορισμένη πρόσβαση, ενώ οι εξουσιοδοτημένοι χρήστες μπορούν να δουν το σύνολο των δεδομένων. Πρόκειται για ένα θέμα όπου πολλοί θεωρούν ότι απαιτούνται κρίσιμες διευκρινίσεις.
Ένα από τα ερωτήματα που θέτει, μεταξύ άλλων, είναι τι πρέπει να γίνει με τους εισαγγελείς, οι οποίοι επιθυμούν να παραμείνουν ανώνυμοι, ενώ ταυτόχρονα απολαμβάνουν πλήρη δικαιώματα πρόσβασης. Επιπλέον, δεν υπάρχουν κατευθυντήριες γραμμές σχετικά με το αν, σε μια τέτοια περίπτωση, η πρόσβαση στα δεδομένα του domain μπορεί να παραχωρηθεί και σε άτομα που βρίσκονται εκτός των συνόρων μιας χώρας. Πάνω απ’ όλα, προτεραιότητα έχει η προστασία των δεδομένων των χρηστών και η εμπιστοσύνη στον διαχειριστή του ιστότοπου που καταχωρίζει το domain, η οποία συνοδεύει την προστασία αυτή. Και σε καμία περίπτωση αυτή η εμπιστοσύνη δεν πρέπει να διακυβεύεται από τη νέα τεχνολογία αιτήσεων RDAP. Στα τέλη του 2016, ορισμένα μητρώα άσκησαν έφεση κατά της περιόδου εφαρμογής που επέβαλε η ICANN, με αποτέλεσμα ο οργανισμός να αποφασίσει να συνάψει συμβάσεις για το RDAP με καταχωρητές και παρόχους domain.