Ένα αρχείο καταγραφής DNS resolver και ένα αρχείο καταγραφής σύνδεσης VPN είναι και τα δύο αρχεία δικτύου, και τα δύο χρήσιμα και όχι ανταλλάξιμα. Ο resolver λαμβάνει ονόματα για τα οποία του ζητήθηκε να απαντήσει. Το τελικό σημείο του VPN χειρίζεται συνδέσεις σήραγγας και καταγράφει ό,τι επέλεξε να καταγράψει η υλοποίησή του γι' αυτές. Μπορούν να βρίσκονται στο ίδιο κτίριο, να τα διαχειρίζεται η ίδια ομάδα και να καλύπτονται από την ίδια ειδοποίηση απορρήτου, και παρ' όλα αυτά περιγράφουν διαφορετικά συμβάντα με διαφορετικά αναγνωριστικά και διαφορετική διατήρηση. Το να διαβάζει κανείς το ένα σαν να ήταν το άλλο είναι ο τρόπος με τον οποίο οι έρευνες ξεφεύγουν.

Δύο αρχεία, δύο συμβάντα

Μια εγγραφή στον resolver απαντά σε ένα ερώτημα για ονοματοδοσία: αυτός ο πελάτης ζήτησε αυτό το όνομα σε αυτή τη στιγμή, και η απάντηση ήταν αυτή. Μια εγγραφή στο VPN απαντά σε ένα ερώτημα για συνδεσιμότητα: αυτός ο ομότιμος δημιούργησε ή έχασε μια σήραγγα, του ανατέθηκε αυτή η διεύθυνση και μετέφερε περίπου τόσα δεδομένα πριν εξαφανιστεί. Κανένα από τα δύο δεν είναι καταγραφή του τι έκανε ο χρήστης μέσα σε μια συνεδρία HTTPS, και κανένα δεν υποκαθιστά το άλλο.

Η διάκριση έχει πρακτική συνέπεια για τις υποσχέσεις. Μια δήλωση ότι ένας πάροχος VPN δεν καταγράφει δραστηριότητα σήραγγας δεν λέει τίποτα για τον resolver που παρέχει, και η πολιτική διατήρησης ενός resolver δεν λέει τίποτα για το ποιος συνδέθηκε στη σήραγγα. Κάθε ισχυρισμός ανήκει στον δικό του φορέα εκμετάλλευσης και στο δικό του σύστημα.

Ακολουθήστε το ερώτημα πριν διαβάσετε οποιοδήποτε από τα δύο αρχεία

Ένα ερώτημα φτάνει σε έναν resolver μόνο αν η διαδρομή πράγματι τον ρωτά. Μια εφαρμογή μπορεί να χρησιμοποιήσει τον resolver του λειτουργικού συστήματος, να εκτελέσει τον δικό της κρυπτογραφημένο πελάτη DNS ή να διαβάσει μια προσωρινά αποθηκευμένη απάντηση και να μη στείλει ποτέ τίποτα. Επομένως ένα αρχείο resolver που δεν δείχνει τίποτα δεν είναι απόδειξη ότι ένα όνομα δεν χρησιμοποιήθηκε ποτέ· είναι απόδειξη ότι αυτός ο resolver δεν ρωτήθηκε.

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

Η τελευταία εντολή διαβάζει το δικό του ημερολόγιο του τοπικού resolver, το οποίο δεν είναι το ίδιο με το αρχείο του ανάντη διακομιστή. Αν τα ερωτήματά σας βγαίνουν μέσω DNS over HTTPS προς έναν πάροχο, το τοπικό stub μπορεί να μη δείχνει τίποτα ενώ ο πάροχος έχει την πλήρη καταγραφή, και ο πάροχος είναι διαφορετικός φορέας με διαφορετική πολιτική.

Τι μπορεί και τι δεν μπορεί να δείξει κάθε εγγραφή

RecordTypically showsDoes not show
Resolver logQueried name, client address, time, responseWhich page was fetched, or what the tunnel did
VPN connection logPeer identity, assigned address, connect and disconnect times, volumeWhich name the application asked for
Application or proxy logRequests, status codes, sometimes full URLsResolved addresses for every dependency

Η σύνδεσή τους είναι εκεί που βρίσκεται η πραγματική δουλειά, και η σύνδεσή τους δεν είναι πάντα εφικτή. Ένας resolver που καταγράφει διευθύνσεις πελατών μπορεί να συγκριθεί με ένα VPN που εκχωρεί διευθύνσεις από γνωστή δεξαμενή, και αυτή η σύγκριση παράγει έναν εύλογο σύνδεσμο μεταξύ ενός ονόματος που ζητήθηκε και μιας σήραγγας, ο οποίος παραμένει σύνδεσμος μεταξύ δύο εγγραφών και όχι εγγραφή ενός προσώπου.

Το κρυπτογραφημένο DNS αλλάζει τη μεταφορά, όχι την ορατότητα στο τελικό σημείο. Ο resolver εξακολουθεί να λαμβάνει την ερώτηση που απαντά, όπως RFC 8484 καθιστά σαφές, και η διατήρηση σε αυτόν τον resolver είναι απόφαση πολιτικής και όχι ιδιότητα του πρωτοκόλλου.

Πού το split DNS και οι προσωρινές μνήμες μπερδεύουν την ιστορία

Πολλοί resolvers είναι φυσιολογικό. Ένας σχεδιασμός split DNS στέλνει εσωτερικά ονόματα σε εσωτερικό διακομιστή και όλα τα άλλα σε δημόσιο, οπότε μια μόνο έρευνα μπορεί να περιλαμβάνει δύο αρχεία που δεν προορίζονταν ποτέ να συνδυαστούν και δύο ρυθμίσεις διατήρησης που δεν προορίζονταν ποτέ να συγκριθούν. Το να βλέπεις ερωτήματα και στα δύο είναι απόδειξη ότι ο σχεδιασμός λειτουργεί, όχι απόδειξη διαρροής.

Οι προσωρινές μνήμες κόβουν προς την άλλη κατεύθυνση. Ένα δημοφιλές όνομα μπορεί να απαντάται από την προσωρινή μνήμη για ώρες, οπότε η εγγραφή του resolver δείχνει το πρώτο ερώτημα και μετά τίποτα, ενώ η εφαρμογή του χρήστη συνεχίζει ευτυχώς να επιλύει το ίδιο όνομα. Η απουσία εγγραφών μετά από μια ορισμένη στιγμή δεν σημαίνει ότι κανείς δεν χρησιμοποίησε το όνομα μετά από εκείνη τη στιγμή.

Η κίνηση υποβάθρου είναι η τρίτη παραμόρφωση. Ένα τηλέφωνο που επιλύει ένα όνομα τηλεμετρίας κατά την εκκίνηση, ένα πρόγραμμα περιήγησης που επιλύει έναν τομέα πρότασης αναζήτησης και ένα πρόγραμμα ενημέρωσης που συνδέεται κάθε ώρα εμφανίζονται όλα σε ένα αρχείο resolver δίπλα στο όνομα που πραγματικά σας ενδιαφέρει. Ο όγκος σε εκείνο το αρχείο δεν είναι προσοχή, και το να μετράς ερωτήματα δεν είναι το να μετράς επισκέψεις. Ένα αρχείο resolver είναι αρχείο ερωτήσεων, και οι ερωτήσεις παράγονται φτηνά.

Κάντε τις ερωτήσεις διατήρησης χωριστά

Για κάθε σύστημα, κάντε τρεις ερωτήσεις: ποιος συλλέγει, τι συλλέγεται και για πόσο καιρό διατηρείται. Έπειτα ρωτήστε ποιος μπορεί να το διαβάσει και με ποια διαδικασία. Η συζήτηση του RFC 8484 για το DNS over HTTPS είναι μια καλή υπενθύμιση ότι η κρυπτογραφημένη μεταφορά δεν αφαιρεί το τελικό σημείο, και η ίδια η τεκμηρίωση του φορέα είναι η μόνη αξιόπιστη δήλωση για το τι διατηρεί αυτό το τελικό σημείο.

Όταν διατυπώνεται ένας ισχυρισμός για το απόρρητο σχετικά με το «VPN», χωρίστε το σε συνιστώσες πριν το δεχτείτε: τον φορέα της σήραγγας, τον resolver που παρέχει η σήραγγα, οποιονδήποτε ανάντη resolver φτάνουν αυτά τα ερωτήματα και τις εφαρμογές στη συσκευή. Κάθε μία έχει τη δική της απάντηση, και ένας ισχυρισμός που ισχύει για μία επαναλαμβάνεται συνήθως σαν να κάλυπτε και τις τέσσερις.

Για την αντιμετώπιση προβλημάτων, χρησιμοποιήστε την ίδια διαίρεση. Ρωτήστε ποια εφαρμογή έκανε το ερώτημα και ποιος resolver απάντησε, και στη συνέχεια κοιτάξτε το αρχείο που πραγματικά κατέχει αυτό το συμβάν. Το να μαντεύεις από το άλλο αρχείο γλιτώνει ένα λεπτό και κοστίζει ένα απόγευμα.

Σχετικά άρθρα