Δύο τοποθεσίες, μία ιδιωτική ζώνη DNS: ποιος κατέχει τις εγγραφές;

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

Το σύμπτωμα ονομάζει τον απόντα ιδιοκτήτη

Κάθε τοποθεσία έχει πιθανώς μια τοπική παράκαμψη, μια καταχώριση Pi-hole ή μια γραμμή dnsmasq που πρόσθεσε κάποιος όταν χρειάστηκε ένα όνομα. Η πράσινη εγγραφή υπάρχει μόνο στον πράσινο resolver, οπότε ένας πελάτης στην κίτρινη ρωτά τον δικό του resolver και λαμβάνει ένα αληθινό "δεν υπάρχει τέτοιο όνομα". Μια παλιά απάντηση φαίνεται διαφορετική: ο host μετακινήθηκε, η μία τοποθεσία ενημέρωσε το αντίγραφό της και η άλλη εξακολουθεί να επιστρέφει την παλιά διεύθυνση.

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

Επομένως το ερώτημα σχεδίασης είναι στενό και απαντήσιμο: ποιος επιτρέπεται να δημιουργήσει μια εγγραφή και πώς φτάνει αυτή η εγγραφή σε κάθε resolver που πρέπει να απαντήσει γι' αυτήν;

Επιλογή A: μία έγκυρη ζώνη με δευτερεύοντες

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

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

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

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

Επιλογή B: ένα υποπεδίο ανά τοποθεσία

Εκχωρήστε το green.internal.example.com στην πράσινη τοποθεσία και το yellow.internal.example.com στην κίτρινη. Κάθε τοποθεσία γίνεται έγκυρη για τα δικά της ονόματα και η γονική ζώνη φέρει μόνο τις εγγραφές εκχώρησης. Η διαμάχη για ένα αρχείο εξαφανίζεται και μια τοπική ομάδα μπορεί να προσθέσει host χωρίς να περιμένει κεντρική αλλαγή.

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

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

Κάντε κάθε resolver να ακολουθεί την επιλογή

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

Αν το Pi-hole παρέχει τοπική επίλυση, σημειώστε ποιες εγγραφές κατέχει και ποιες ερωτήσεις προωθεί. Δύο λίστες Pi-hole που επεξεργάζονται ανεξάρτητα εξακολουθούν να μην αναπαράγονται. Στο Pi-hole v6, οι προσαρμοσμένες γραμμές dnsmasq ορίζονται μέσω επιλογών στην πλευρά του host όπως TOML, CLI ή μεταβλητές περιβάλλοντος και δεν εκτίθενται μέσω του API· η φόρτωση αρχείων /etc/dnsmasq.d/ είναι ξεχωριστή επιλογή που είναι απενεργοποιημένη από προεπιλογή.

Στη συνέχεια δοκιμάστε και από τις δύο πλευρές με ένα όνομα που θα έπρεπε να είναι ορατό παντού:

$ dig +short newhost.green.internal.example.com @10.20.0.53
10.20.0.41
$ dig +short newhost.green.internal.example.com @10.30.0.53
10.20.0.41
$ dig SOA internal.example.com @10.30.0.53

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

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