Το VPN σας προωθεί τρεις διακομιστές DNS: ποιος απαντά;

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

Γιατί η λίστα είναι μεγαλύτερη από το προφίλ σας

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

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

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

Τι δείχνει ο καθένας από τους τρεις ελέγχους

Κάθε πηγή αφήνει το σημάδι της σε διαφορετικό σημείο, και καμία μεμονωμένη εντολή δεν τις δείχνει όλες. Αυτή είναι η αντιστοίχιση που αξίζει να κρατάτε δίπλα στη σελίδα ρυθμίσεων:

Σε σύστημα με systemd-resolved, έγκυρη είναι η resolvectl status, επειδή αναφέρει το DNS ανά σύνδεση μαζί με τους τομείς δρομολόγησης. Το macOS απαντά μέσω της scutil --dns, η οποία απαριθμεί τους επιλυτές με εύρος με τη σειρά δοκιμής. Τα Windows χωρίζουν τα δύο μισά: Get-DnsClientServerAddress για διακομιστές ανά διεπαφή και Get-DnsClientNrptPolicy για τους κανόνες επιθήματος. Εκτελέστε την εντολή που ανήκει στον επιλυτή που χρησιμοποιείται στην πραγματικότητα, επειδή ένα μηχάνημα με χρόνο εκτέλεσης κοντέινερ και επιλυτή επιφάνειας εργασίας μπορεί να έχει περισσότερους από έναν εγκατεστημένους.

Ένας εφεδρικός επιλυτής που δεν μπορεί να απαντήσει στη ζώνη σας

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

Split DNS υπάρχει για να το εμποδίζει: τα επιθήματα της εταιρείας πηγαίνουν σε επιλυτή που κρατά τη ζώνη, και τα δημόσια ονόματα μένουν στην προεπιλεγμένη διαδρομή. Ο σχεδιασμός είναι υγιής, και εξαρτάται από το ότι η λίστα επιθημάτων είναι πλήρης. Η Microsoft τεκμηριώνει την πολιτική επιλυτή ανά επίθημα που το οδηγεί στα Windows, και η ίδια ιδέα εμφανίζεται ως τομείς δρομολόγησης στο systemd-resolved και ως επιλυτές με εύρος στο macOS.

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

Ρωτήστε μέσα από την πολιτική, όχι γύρω από αυτή

Ρωτήστε μέσω του επιλυτή του λειτουργικού συστήματος, επειδή ένα άμεσο ερώτημα σε διακομιστή παρακάμπτει την πολιτική και αναφέρει μόνο τι θα έλεγε αυτός ο διακομιστής. Το κενό ανάμεσα στις δύο απαντήσεις είναι όλο το νόημα:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Αν το ερώτημα συστήματος επιστρέφει ιδιωτική διεύθυνση ενώ το άμεσο ερώτημα επιστρέφει NXDOMAIN, η πολιτική λειτουργεί και το εφεδρικό είναι το αδύναμο σημείο. Αν και τα δύο επιστρέφουν την ίδια δημόσια απάντηση, το όνομα επιλύεται έξω από το εύρος που σκοπεύατε, και η λίστα επιθημάτων είναι το σημείο αναζήτησης. Κρατήστε και τις δύο εξόδους, επειδή μια διαφωνία για επιλυτή λύνεται γρηγορότερα με δύο γραμμές παρά με ένα στιγμιότυπο της σελίδας ρυθμίσεων.

Στη συνέχεια ασκήστε τη διαδρομή αποτυχίας, επειδή ένα εφεδρικό που δεν δοκίμασε κανείς είναι υπόθεση. Μετατρέψτε τον προτιμώμενο επιλυτή σε μαύρη τρύπα για ένα ερώτημα και δείτε ποια διεύθυνση επιστρέφει:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

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

Αποφασίστε: κρατήστε, περιορίστε ή αφαιρέστε

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

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