BIND πάνω από VPN: υπό όρους προώθηση ή ζώνη stub;

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

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

Τρεις διατάξεις για έναν χώρο ονομάτων

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

Υπό όρους προώθηση: η μικρότερη δέσμευση

Υποθέστε έναν resolver γραφείου στη 192.168.10.53 και έναν εταιρικό διακομιστή στη 10.40.0.53, προσβάσιμο μέσω εγκεκριμένης σήραγγας. Η δήλωση είναι τρεις γραμμές, και η ενδιαφέρουσα είναι forward only, γιατί αλλάζει τη συμπεριφορά αποτυχίας και όχι τη διαδρομή.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

Με forward only, ένα μη προσβάσιμο upstream παράγει SERVFAIL για αυτή τη ζώνη αντί για υποχώρηση σε επαναληπτική επίλυση. Αυτό είναι συνήθως το επιθυμητό για έναν ιδιωτικό χώρο ονομάτων, γιατί η υποχώρηση θα έστελνε ιδιωτικά ονόματα σε δημόσιο resolver και θα επέστρεφε μια άχρηστη απάντηση από το διαδίκτυο. Η αναφορά του BIND τεκμηριώνει και τις δύο πολιτικές, και η διαφορά μετράει περισσότερο από όσο υπονοεί το απόσπασμα. Συγχωνεύστε τη ζώνη στην υπάρχουσα διαμόρφωση αντί να αντικαταστήσετε μια ζώνη που υπάρχει ήδη για το ίδιο όνομα.

Stub ή secondary: όταν η ανάθεση μετράει

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

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

Μια secondary απαντά από τοπικά δεδομένα και επιβιώνει από διακοπή του upstream, και αυτός είναι ο λόγος να δεχτείτε την εξάρτηση μεταφοράς. Σημαίνει επίσης ότι ο resolver σας κρατά τώρα αντίγραφο μιας ζώνης που δεν του ανήκει, οπότε η διαδρομή αρχείου, το ACL μεταφοράς στον primary και τα χρονόμετρα ανανέωσης γίνονται μέρος της επιχειρησιακής σας επιφάνειας.

Ο έλεγχος που αποφασίζει μεταξύ τους

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

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Επιτρέψτε UDP και TCP στη διαδρομή: μια κολοβωμένη απάντηση επιβάλλει TCP, και μια πολιτική που επιτρέπει μόνο UDP παράγει διακοπτόμενες αποτυχίες που μοιάζουν με απώλεια πακέτων. Η εταιρική πλευρά χρειάζεται και κανόνα αποδοχής για την προέλευση του resolver σας και διαδρομή επιστροφής προς αυτήν· αυτή η προέλευση μπορεί να είναι η δρομολογημένη διεύθυνση του resolver ή μια ρητά μεταφρασμένη, και σπάνια είναι διεύθυνση από δεξαμενή πελατών. Αν το ερώτημα NS αποτύχει, μια ζώνη stub δεν μπορεί να δουλέψει ό,τι κι αν κάνει η ζώνη forward.

Επαληθεύστε την απάντηση, όχι τη σήραγγα

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

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

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

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