Μετά από δύο χρόνια ανάπτυξης, η κοινοπραξία ISC κυκλοφόρησε την πρώτη σταθερή έκδοση ενός μεγάλου νέου κλάδου του διακομιστή BIND 9.18 DNS. Η υποστήριξη για τον κλάδο 9.18 θα παρέχεται για τρία χρόνια έως το 2ο τρίμηνο του 2025 ως μέρος ενός εκτεταμένου κύκλου υποστήριξης. Η υποστήριξη για τον κλάδο 9.11 θα λήξει τον Μάρτιο και η υποστήριξη για τον κλάδο 9.16 στα μέσα του 2023. Για την ανάπτυξη της λειτουργικότητας της επόμενης σταθερής έκδοσης του BIND, έχει δημιουργηθεί ένας πειραματικός κλάδος BIND 9.19.0.
Η κυκλοφορία του BIND 9.18.0 είναι αξιοσημείωτη για την εφαρμογή υποστήριξης για DNS μέσω HTTPS (DoH, DNS μέσω HTTPS) και DNS μέσω TLS (DoT, DNS μέσω TLS), καθώς και για τον μηχανισμό XoT (XFR-over-TLS). για ασφαλή μεταφορά περιεχομένου DNS.ζώνες μεταξύ διακομιστών (υποστηρίζονται και οι ζώνες αποστολής και λήψης μέσω XoT). Με τις κατάλληλες ρυθμίσεις, μια μεμονωμένη διαδικασία με όνομα μπορεί πλέον να εξυπηρετεί όχι μόνο παραδοσιακά ερωτήματα DNS, αλλά και ερωτήματα που αποστέλλονται χρησιμοποιώντας DNS-over-HTTPS και DNS-over-TLS. Η υποστήριξη πελάτη για DNS-over-TLS είναι ενσωματωμένη στο βοηθητικό πρόγραμμα dig, το οποίο μπορεί να χρησιμοποιηθεί για την αποστολή αιτημάτων μέσω TLS όταν έχει καθοριστεί η σημαία "+tls".
Η υλοποίηση του πρωτοκόλλου HTTP/2 που χρησιμοποιείται στο DoH βασίζεται στη χρήση της βιβλιοθήκης nghttp2, η οποία περιλαμβάνεται ως προαιρετική εξάρτηση συναρμολόγησης. Τα πιστοποιητικά για DoH και DoT μπορούν να παρέχονται από τον χρήστη ή να δημιουργηθούν αυτόματα κατά την εκκίνηση.
Η επεξεργασία αιτημάτων με χρήση DoH και DoT ενεργοποιείται προσθέτοντας τις επιλογές "http" και "tls" στην οδηγία ακρόασης. Για να υποστηρίξετε μη κρυπτογραφημένο DNS-over-HTTP, θα πρέπει να καθορίσετε "tls none" στις ρυθμίσεις. Τα κλειδιά ορίζονται στην ενότητα "tls". Οι προεπιλεγμένες θύρες δικτύου 853 για DoT, 443 για DoH και 80 για DNS-over-HTTP μπορούν να παρακαμφθούν μέσω των παραμέτρων tls-port, https-port και http-port. Για παράδειγμα:
tls local-tls { key-file "/path/to/priv_key.pem"; cert-file "/path/to/cert_chain.pem"; }; http local-http-server { endpoints { "/dns-query"; }; }; επιλογές { https-port 443; θύρα ακρόασης 443 tls local-tls http myserver {any;}; }
Ένα από τα χαρακτηριστικά της υλοποίησης DoH στο BIND είναι η δυνατότητα μετακίνησης λειτουργιών κρυπτογράφησης για TLS σε άλλο διακομιστή, κάτι που μπορεί να είναι απαραίτητο σε συνθήκες όπου τα πιστοποιητικά TLS αποθηκεύονται σε άλλο σύστημα (για παράδειγμα, σε μια υποδομή με διακομιστές ιστού) και διατηρούνται από άλλο προσωπικό. Η υποστήριξη για μη κρυπτογραφημένο DNS-over-HTTP υλοποιείται για την απλοποίηση του εντοπισμού σφαλμάτων και ως επίπεδο για προώθηση σε άλλο διακομιστή στο εσωτερικό δίκτυο (για μετακίνηση της κρυπτογράφησης σε ξεχωριστό διακομιστή). Σε έναν απομακρυσμένο διακομιστή, το nginx μπορεί να χρησιμοποιηθεί για τη δημιουργία επισκεψιμότητας TLS, παρόμοια με τον τρόπο οργάνωσης της σύνδεσης HTTPS για ιστότοπους.
Ένα άλλο χαρακτηριστικό είναι η ενσωμάτωση του DoH ως γενικής μεταφοράς που μπορεί να χρησιμοποιηθεί όχι μόνο για τον χειρισμό αιτημάτων πελατών προς τον επιλύτη, αλλά και κατά την επικοινωνία μεταξύ διακομιστών, κατά τη μεταφορά ζωνών από έναν έγκυρο διακομιστή DNS και κατά την επεξεργασία τυχόν ερωτημάτων που υποστηρίζονται από άλλα DNS ΜΕΤΑΦΟΡΕΣ.
Μεταξύ των ελλείψεων που μπορούν να αντισταθμιστούν με την απενεργοποίηση της έκδοσης με DoH/DoT ή τη μετακίνηση της κρυπτογράφησης σε άλλο διακομιστή, ξεχωρίζει η γενική επιπλοκή της βάσης κώδικα - προστίθεται ένας ενσωματωμένος διακομιστής HTTP και βιβλιοθήκη TLS, τα οποία ενδέχεται να περιέχουν ευπάθειες και λειτουργούν ως πρόσθετοι φορείς επίθεσης. Επίσης, όταν χρησιμοποιείτε DoH, η κίνηση αυξάνεται.
Ας θυμηθούμε ότι το DNS-over-HTTPS μπορεί να είναι χρήσιμο για την πρόληψη διαρροών πληροφοριών σχετικά με τα ονόματα κεντρικών υπολογιστών που ζητήθηκαν μέσω των διακομιστών DNS των παρόχων, την καταπολέμηση των επιθέσεων MITM και της πλαστογράφησης της κυκλοφορίας DNS (για παράδειγμα, κατά τη σύνδεση σε δημόσιο Wi-Fi), την αντιμετώπιση αποκλεισμός σε επίπεδο DNS (το DNS-over-HTTPS δεν μπορεί να αντικαταστήσει ένα VPN παρακάμπτοντας τον αποκλεισμό που εφαρμόζεται σε επίπεδο DPI) ή για την οργάνωση εργασίας όταν είναι αδύνατη η άμεση πρόσβαση σε διακομιστές DNS (για παράδειγμα, όταν εργάζεστε μέσω διακομιστή μεσολάβησης). Εάν σε μια κανονική κατάσταση τα αιτήματα DNS αποστέλλονται απευθείας σε διακομιστές DNS που ορίζονται στη διαμόρφωση του συστήματος, τότε στην περίπτωση του DNS-over-HTTPS το αίτημα για τον προσδιορισμό της διεύθυνσης IP του κεντρικού υπολογιστή ενσωματώνεται στην κίνηση HTTPS και αποστέλλεται στον διακομιστή HTTP, όπου ο επιλύτης επεξεργάζεται αιτήματα μέσω Web API.
Το "DNS μέσω TLS" διαφέρει από το "DNS μέσω HTTPS" στη χρήση του τυπικού πρωτοκόλλου DNS (συνήθως χρησιμοποιείται η θύρα δικτύου 853), τυλιγμένο σε ένα κρυπτογραφημένο κανάλι επικοινωνίας οργανωμένο χρησιμοποιώντας το πρωτόκολλο TLS με έλεγχο εγκυρότητας κεντρικού υπολογιστή μέσω πιστοποιητικών TLS/SSL από μια αρχή πιστοποίησης. Το υπάρχον πρότυπο DNSSEC χρησιμοποιεί κρυπτογράφηση μόνο για τον έλεγχο ταυτότητας του πελάτη και του διακομιστή, αλλά δεν προστατεύει την κυκλοφορία από την παρακολούθηση και δεν εγγυάται την εμπιστευτικότητα των αιτημάτων.
Μερικές άλλες καινοτομίες:
- Προστέθηκαν ρυθμίσεις tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer και udp-send-buffer για να ορίσετε τα μεγέθη των buffer που χρησιμοποιούνται κατά την αποστολή και λήψη αιτημάτων μέσω TCP και UDP. Σε απασχολημένους διακομιστές, η αύξηση των εισερχόμενων buffer θα βοηθήσει στην αποφυγή απόρριψης πακέτων κατά τη διάρκεια αιχμής κυκλοφορίας και η μείωσή τους θα βοηθήσει να απαλλαγούμε από το φράξιμο της μνήμης με παλιά αιτήματα.
- Προστέθηκε μια νέα κατηγορία καταγραφής "rpz-passthru", η οποία σας επιτρέπει να καταγράφετε ξεχωριστά τις ενέργειες προώθησης RPZ (Ζώνες πολιτικής απόκρισης).
- Στην ενότητα απάντηση-πολιτική, η επιλογή "nsdname-wait-recurse" έχει προστεθεί, όταν οριστεί σε "no", οι κανόνες RPZ NSDNAME εφαρμόζονται μόνο εάν βρεθούν έγκυροι διακομιστές ονομάτων που υπάρχουν στην κρυφή μνήμη για το αίτημα, διαφορετικά το Ο κανόνας RPZ NSDNAME αγνοείται, αλλά οι πληροφορίες ανακτώνται στο παρασκήνιο και ισχύουν για επόμενα αιτήματα.
- Για εγγραφές με τύπους HTTPS και SVCB, έχει υλοποιηθεί η επεξεργασία της ενότητας "ΠΡΟΣΘΕΤΑ".
- Προστέθηκαν προσαρμοσμένοι τύποι κανόνων πολιτικής ενημέρωσης - krb5-subdomain-self-rhs και ms-subdomain-self-rhs, που σας επιτρέπουν να περιορίσετε την ενημέρωση των εγγραφών SRV και PTR. Τα μπλοκ πολιτικής ενημέρωσης προσθέτουν επίσης τη δυνατότητα ορισμού ορίων στον αριθμό των εγγραφών, ξεχωριστά για κάθε τύπο.
- Προστέθηκαν πληροφορίες σχετικά με το πρωτόκολλο μεταφοράς (UDP, TCP, TLS, HTTPS) και τα προθέματα DNS64 στην έξοδο του βοηθητικού προγράμματος dig. Για σκοπούς εντοπισμού σφαλμάτων, το dig έχει προσθέσει τη δυνατότητα να καθορίσει ένα συγκεκριμένο αναγνωριστικό αιτήματος (dig +qid= ).
- Προστέθηκε υποστήριξη για τη βιβλιοθήκη OpenSSL 3.0.
- Για την αντιμετώπιση προβλημάτων με τον κατακερματισμό IP κατά την επεξεργασία μεγάλων μηνυμάτων DNS που προσδιορίζονται από την Ημέρα σημαίας DNS 2020, ο κώδικας που προσαρμόζει το μέγεθος της προσωρινής μνήμης EDNS όταν δεν υπάρχει απάντηση σε ένα αίτημα έχει αφαιρεθεί από το πρόγραμμα επίλυσης. Το μέγεθος της προσωρινής μνήμης EDNS έχει πλέον οριστεί σε σταθερό (edns-udp-size) για όλα τα εξερχόμενα αιτήματα.
- Το σύστημα κατασκευής έχει αλλάξει σε χρήση ενός συνδυασμού autoconf, automake και libtool.
- Η υποστήριξη για αρχεία ζώνης σε μορφή «χάρτης» (masterfile-format map) έχει διακοπεί. Συνιστάται στους χρήστες αυτής της μορφής να μετατρέπουν ζώνες σε ακατέργαστη μορφή χρησιμοποιώντας το βοηθητικό πρόγραμμα named-compilezone.
- Η υποστήριξη για παλαιότερα προγράμματα οδήγησης DLZ (Dynamically Loadable Zones) έχει διακοπεί και αντικαταστάθηκε από μονάδες DLZ.
- Η υποστήριξη δημιουργίας και εκτέλεσης για την πλατφόρμα των Windows έχει διακοπεί. Ο τελευταίος κλάδος που μπορεί να εγκατασταθεί στα Windows είναι το BIND 9.16.
Πηγή: opennet.ru