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

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

Μαύρα.

Εκτός ειδικών περιπτώσεων, κανείς μας δεν θέλει να θυμάται τις αριθμητικές διευθύνσεις IP διαφόρων servers στο Internet. Κάθε φορά που πρόκειται να επισκεφτούμε έναν δικτυακό τόπο ή να χρησιμοποιήσουμε μια δικτυακή υπηρεσία, αρκεί να γνωρίζουμε το αντίστοιχο domain name (ή το FQDN). Αυτό το όνομα το δίνουμε –ή το έχουμε ήδη δώσει– στο αντίστοιχο πρόγραμμα-πελάτη, π.χ., στον web browser, στην εφαρμογή FTP, στον SSH client κ.ο.κ. Το πρόγραμμα οφείλει, με βάση το domain name, να μάθει την αντίστοιχη διεύθυνση IP. Μόνον αφού τη γνωρίσει θα ‘ναι σε θέση να στείλει και να λάβει πακέτα προς και από το απομακρυσμένο μηχάνημα. Για να βρει το IP του domain, λοιπόν, το πρόγραμμα θα επικοινωνήσει με κάποιον name server. Μερικοί clients, όπως οι web browsers, δεν βιάζονται. Και δεν βιάζονται διότι διατηρούν μια εσωτερική DNS cache, στην οποία αποθηκεύουν τις απαντήσεις από προηγούμενα ερωτήματα του στιλ “ποιο είναι το IP του τάδε domain”. Αν στην cache της εφαρμογής δεν υπάρχει απάντηση στο ερώτημα, τότε εκείνη απευθύνεται στον λεγόμενο system resolver.

Γενικά, κάθε πρόγραμμα που λειτουργεί ως πελάτης του συστήματος DNS χαρακτηρίζεται ως resolver. Όπως φαντάζεστε, υπάρχουν resolvers και resolvers Εκεί Έξω™. Για παράδειγμα, το λειτουργικό σύστημα του υπολογιστή διαθέτει μια βιβλιοθήκη, στην οποία καταφεύγουν οι εφαρμογές κάθε φορά που υπάρχει ερώτημα για τη διεύθυνση IP ενός domain. Ουσιαστικά πρόκειται για έναν απλοϊκό resolver, τον οποίο –εντελώς δικαιολογημένα– ονομάζουμε και stub resolver. Πράγματι, η δουλειά του είναι εξαιρετικά απλή. Κοιτάζει πρώτα σε τοπικά αρχεία, όπως σ’ εκείνο το hosts file που αναφέραμε στο προηγούμενο άρθρο. Αν βρει την απάντηση στο ερώτημα που του απευθύνθηκε, την επιστρέφει στον client (π.χ., στον web browser). Αν πάλι δεν βρει απάντηση, δεν πολυσκοτίζεται: αμέσως προωθεί το ερώτημα σε κάποιον άλλον, περισσότερο ικανό name server.

Ο άλλος name server, ο ικανότερος, σε πολλές περιπτώσεις είναι αυτό που ονομάζουμε recursive. Ένας server του είδους εγγυημένα επιστρέφει μιαν απάντηση, ακόμη κι αν είναι ένα μήνυμα λάθους. Πριν ο recursive name server απαντήσει ρωτά ένα πλήθος άλλων servers, ακόμη κι αν χρειαστεί να φτάσει στην κορυφή της ιεραρχίας του DNS, εκεί που κατοικούν οι root servers. Αλλά προσέξτε: Κατά πάσα πιθανότητα, ένας recursive name server θα διαθέτει και μνήμη cache. Πριν λοιπόν ενοχλήσει άλλους servers θα ρίξει μια ματιά σ’ αυτή. Αν βρει εκεί την απάντηση στο ερώτημα, έχει καλώς: την επιστρέφει στον πελάτη και ησυχάζει. Αν δεν τη βρει αρχίζει τις ερωτήσεις πιο ψηλά στην ιεραρχία του DNS.

Στο σημείο αυτό αξίζει να δούμε ένα παράδειγμα. Συγκεκριμένα, ας υποθέσουμε ότι ζητάμε από το Thunderbird, ένας από τους αγαπημένους μας email clients λόγω άψογης συνεργασίας με το Enigmail, να ελέγξει το Inbox του λογαριασμού μας για εισερχόμενη αλληλογραφία. Ο λογαριασμός αυτός είναι σε έναν δικό μας mail server, ο οποίος είναι υπεύθυνος για το email του domain ονόματι colder.xyz. Το πλήρες όνομα του host που διακινεί την αλληλογραφία είναι το box.colder.xyz. Το Thunderbird γνωρίζει αυτό το όνομα, δεν γνωρίζει όμως το αντίστοιχο IP. Ακριβώς γι’ αυτό απευθύνει σχετικό ερώτημα στον system resolver (ο stub resolver που λέγαμε). Εκείνος ψάχνεται για ελάχιστα κλάσματα του δευτερολέπτου, δεν βρίσκει κάτι για το box.colder.xyz, οπότε προωθεί το ερώτημα στον name server του router μπροστά από τον υπολογιστή μας. O router του παραδείγματος που έχουμε κατά νου είναι ένα pfSense box κι ο name server που έχει ενεργοποιημένο είναι ο λεγόμενος Unbound. Πρόκειται για έναν recursive αλλά ταυτόχρονα και caching name server, οπότε η πρώτη του κίνηση είναι να κοιτάξει στην cache του. Αν εκεί υπάρχει το IP του box.colder.xyz, το επιστρέφει χαρούμενος στον stub resolver κι εκείνος με τη σειρά του στο Thunderbird. Αν πάλι ο Unbound δεν βρει το ζητούμενο IP, δεν το βάζει κάτω. Αντίθετα, κοιτάζει μήπως γνωρίζει το IP του name server που είναι υπεύθυνος για το colder.xyz. Αν το έχει τον ρωτά απευθείας, αλλιώς ελέγχει μήπως και γνωρίζει το IP του TLD server που είναι υπεύθυνος για το xyz. Φαντάζεστε τη συνέχεια: Αν έχει το προαναφερθέν IP, ρωτά τον TLD server του xyz για τη διεύθυνση του name server για το colder.xyz. Διαφορετικά ενοχλεί τους root name servers, ώστε να μάθει το IP του TLD server για το xyz. Αφού το πληροφορηθεί ρωτά τον TLD server του xyz, μετά τον name server του colder.xyz κι εκείνος, αν λειτουργεί σωστά, του δίνει την πολυπόθητη διεύθυνση IP (για το box.colder.xyz). Ο recursive name server θα περάσει στον stub resolver τη ζητούμενη διεύθυνση IP και, ταυτόχρονα, στην τοπική του cache θα αποθηκεύσει την αντιστοίχιση box.colder.xyz <-> IP address.

Η κοπιώδης αναζήτηση της διεύθυνσης IP που αντιστοιχεί στο box.colder.xyz, από πλευράς ενός recursive name server.Σχηματικά: Η κοπιώδης αναζήτηση της διεύθυνσης IP που αντιστοιχεί στο box.colder.xyz, από πλευράς ενός recursive name server.

Είναι προφανές ότι υπάρχουν διάφορα είδη name servers και κάθε είδος έχει έναν σημαντικό ρόλο να παίξει. Προκειμένου να φτάσουμε στο σημείο να στήνουμε τους δικούς μας name servers, είναι απαραίτητο να γνωρίζουμε τι ακριβώς κάνει κάθε είδος και για ποια εργασία είναι καταλληλότερο. Αν και υπάρχει εξαιρετικά ευέλικτο λογισμικό για την υλοποίηση name servers που συνδυάζουν διάφορες λειτουργίες –και κατά νου έχουμε το Bind–, σε πολλές περιπτώσεις καλό είναι ο name server να εξειδικεύεται.

Authoritative-only name server. Ένας server του είδους απαντά μόνο σε ερωτήματα που αφορούν σε zones της ευθύνης του. Για άλλα ερωτήματα δεν μπαίνει καν στον κόπο να επικοινωνήσει με άλλους servers. Το πολύ πολύ να ενημερώσει τον client για κάποιον delegate server, ο οποίος έχει αναλάβει την ευθύνη για subdomains ενός domain της ευθύνης του authoritative-only name server. Όπως και να ‘χει, οι authoritative-only servers είναι γρήγοροι και δεν λειτουργούν ποτέ ως πελάτες του DNS, αφού δεν ασχολούνται με recursive requests. Επίσης δεν διαθέτουν μνήμη cache, διότι πολύ απλά τους είναι άχρηστη: Όλες οι πληροφορίες που μπορούν να προσφέρουν στους πελάτες βρίσκονται ήδη στο τοπικό σύστημα – και συγκεκριμένα στα zone files.

Caching name server. Ουσιαστικά πρόκειται για servers που αναλαμβάνουν recursive requests, δηλαδή μπαίνουν στον κόπο να βρίσκουν απαντήσεις σε ερωτήματα πελατών ακόμη κι αν δεν γνωρίζουν τις απαντήσεις. Κατά πάντα πιθανότητα, οι servers με τους οποίους επικοινωνεί ο stub resolver του λειτουργικού συστήματος θα είναι caching. Για εξοικονόμηση bandwidth αλλά και χρόνου, οι caching name servers αποθηκεύουν στην τοπική τους cache τις απαντήσεις στα ερωτήματα που δέχονται. Έτσι, συν τω χρόνω η πιθανότητα να γνωρίζουν τις απαντήσεις σε δημοφιλή ερωτήματα αυξάνει. (Να σημειώσουμε βεβαίως ότι δεν αποθηκεύουν απαντήσεις στην cache τους για πάντα, αλλά μόνο για όσο χρόνο υποδεικνύει η παράμετρος TTL των διαφόρων records.) Προσέξτε τώρα τι γίνεται: Αν και οι authoritative-only servers είναι απαραίτητοι για την εξυπηρέτηση συγκεκριμένων zones, οι caching name servers είναι πολύτιμοι για το Internet εν συνόλω. Πράγματι, χάρη σ’ αυτούς ακόμη και συσκευές που διαθέτουν απλοϊκό λογισμικό είναι δυνατόν να συμμετέχουν στο Internet. Το μόνο που χρειάζονται είναι ένας stub resolver ο οποίος απλά θα ενοχλεί άλλους, κατά πολύ πιο έξυπνους και ικανούς name servers.

Forwarding name server. Σκεφτείτε το σενάριο όπου χρειαζόσαστε έναν caching name server για τους πελάτες του δικτύου σας, όμως το μηχάνημα που θα μπορούσε ν’ αναλάβει αυτόν τον ρόλο δεν είναι τόσο ισχυρό ώστε να διαχειρίζεται το ίδιο τα recursive requests – ειδικά αν οι πελάτες είναι πολλοί. Ίσως επίσης το bandwidth προς τον έξω κόσμο να ‘ναι περιορισμένο, οπότε το recursion θα ήταν καλό να συνέβαινε εκτός του τοπικού δικτύου, από κάποιον άλλον server που επικοινωνεί πολύ πιο άνετα με άλλους. Η λύση για τέτοιες περιπτώσεις είναι η εισαγωγή ενός forwarding name server, ο οποίος αν και διαθέτει τοπική cache δεν ασχολείται με το recursion αλλά προωθεί απευθείας τα ερωτήματα σε κάποιον άλλον “φυσιολογικό” caching name server, ικανό για recursion. Προσέξτε ότι αυτός ο άλλος name server, στον οποίο προωθεί τα ερωτήματα ο forwarding, κάλλιστα μπορεί να ‘ναι ένας δημόσια διαθέσιμος, όπως, π.χ., είναι αυτοί της Google ή της OpenDNS. Με τη χρήση forwarding server προσθέτουμε, προφανώς, άλλον έναν κρίκο στην αλυσίδα του DNS, όμως τα μηχανήματα του τοπικού δικτύου εξακολουθούν να έχουν μια κοντινή cache, ενώ ελλείψει recursive requests η σύνδεση του δικτύου προς τον έξω κόσμο επιβαρύνεται σαφώς λιγότερο.

Συνδυασμοί. Τα τρία είδη name servers που παρουσιάσαμε μόλις, προορίζονται για συγκεκριμένα σενάρια χρήσης. Στην πράξη βέβαια συναντάμε και συνδυασμούς που εκμεταλλεύονται τα πλεονεκτήματα διαφορετικών ειδών name servers. Μια εταιρεία, για παράδειγμα, καθόλου δεν αποκλείεται να συντηρεί έναν name server ο οποίος είναι και authoritative-only αλλά και caching (με ικανότητες recursion). Αναλυτικότερα, το authoritative-only μέρος εξυπηρετεί requests που προέρχονται από οπουδήποτε στο Internet κι αφορούν στα zones ευθύνης του server. Την ίδια στιγμή, τα μηχανήματα ενός τοπικού δικτύου της εταιρείας εκμεταλλεύονται το caching μέρος του ίδιου server, ώστε να επικοινωνούν με άλλα μηχανήματα εντός κι εκτός του τοπικού δικτύου.

Αφεντικά και δούλοι

Ένας forwarding ή caching name server που για οποιονδήποτε λόγο δεν λειτουργεί σωστά, δεν επιφέρει και πολύ μεγάλη αναταραχή στο Internet γενικότερα. Σίγουρα προκαλεί μια κάποια αναστάτωση στο τοπικό δίκτυο και στους πελάτες που εξυπηρετεί, όμως είναι εύκολο να αντικατασταθεί πολύ εύκολα. Θα συμφωνήσετε, π.χ., ότι είναι μάλλον απίθανο να πέσουν ταυτόχρονα και οι δύο caching name servers της Google. Ακόμη κι αυτό να συμβεί, υπάρχουν και οι servers της OpenDNS.

Από την άλλη, ο ρόλος ενός authoritative-only server είναι πολύ πιο κρίσιμος: αρκεί να σκεφτείτε ότι σε περίπτωση που πέσει ή έστω αρχίσει να υπολειτουργεί, τότε σύντομα κανένα από τα domains της ευθύνης του δεν θα είναι προσβάσιμο – από πουθενά στο Internet και με κανέναν τρόπο. Ακριβώς γι’ αυτό, συνηθίζεται οι authoritative-only servers να διαθέτουν κάποιου είδους redundancy. Πιο συγκεκριμένα, έχουμε authoritative-only servers που είναι masters, οι οποίοι συνοδεύονται από authoritative-only servers που είναι slaves. Σε μια σχέση master-slave, αμφότεροι οι servers είναι authoritative για τα zones της ευθύνης τους. Η διαφορά τους εντοπίζεται στο από πού διαβάζει ο καθένας τις πληροφορίες για τα zones. Ο master τις διαβάζει από τα zone files στον τοπικό του δίσκο. Ο slave όμως τις λαμβάνει δικτυακά από τον master μέσω των λεγόμενων zone transfers, και τις αποθηκεύει σε μια δική του τοπική cache. Σε περίπτωση που ο slave πρόκειται να επανεκκινήσει, ελέγχει πρώτα αν οι πληροφορίες για τα zones που διαθέτει είναι συγχρονισμένες με τις αντίστοιχες πληροφορίες που έχει ο master. Αν δεν είναι, πριν την επανεκκίνηση φροντίζει να τις συγχρονίσει. Είναι προφανές ότι σε περίπτωση που ο master αρχίσει να υπολειτουργεί, τότε αντί γι’ αυτόν εξυπηρετεί ο slave. Επιτρέπεται, επίσης, να έχουμε περισσότερους από έναν slaves για κάποιον συγκεκριμένο master. Στο σημείο αυτό αξίζει να τονίσουμε ότι η σχέση master-slave ορίζεται στο επίπεδο των zones κι όχι των servers. Μπορεί, δηλαδή, κάποιο μηχάνημα να είναι master για τέσσερα zones και slave για άλλα δύο zones.

Ο mailserver που έχουμε για το colder.xyz είναι το Mail-in-a-Box (MiaB) και υποστηρίζεται από έναν μόνο name server. Μέσα από το web panel του MiaB, ο διαχειριστής έχει τη δυνατότητα να ορίσει έναν slave name server, ο οποίος αναφέρεται ως secondary. O registrar από τον οποίο πήραμε το colder.xyz παρέχει (δωρεάν) υπηρεσίες slave name server, οπότε στη σχετική θυρίδα του Mail-in-a-Box panel πληκτρολογούμε το domain name του προαναφερθέντα server.Ο mailserver που έχουμε για το colder.xyz είναι το Mail-in-a-Box (MiaB) και υποστηρίζεται από έναν μόνο name server. Μέσα από το web panel του MiaB, ο διαχειριστής έχει τη δυνατότητα να ορίσει έναν slave name server, ο οποίος αναφέρεται ως secondary. O registrar από τον οποίο πήραμε το colder.xyz παρέχει (δωρεάν) υπηρεσίες slave name server, οπότε στη σχετική θυρίδα του Mail-in-a-Box panel πληκτρολογούμε το domain name του προαναφερθέντα server.

Αυτή η απλή προσθήκη στο web panel του MiaB αντικατοπτρίζεται άμεσα στο zone file για το colder.xyz.Αυτή η απλή προσθήκη στο web panel του MiaB αντικατοπτρίζεται άμεσα στο zone file για το colder.xyz.

Είναι απαραίτητο να ενημερώσουμε τον registrar (Gandi) για τους δύο name servers που υποστηρίζουν το colder.xyz. Ο master είναι ο ns1.box.colder.xyz και είναι εκείνος που ανέκαθεν χρησιμοποιούσαμε. Ο slave ή secondary name server είναι o ns6.gandi.net.Είναι απαραίτητο να ενημερώσουμε τον registrar (Gandi) για τους δύο name servers που υποστηρίζουν το colder.xyz. Ο master είναι ο ns1.box.colder.xyz και είναι εκείνος που ανέκαθεν χρησιμοποιούσαμε. Ο slave ή secondary name server είναι o ns6.gandi.net.

Άρθρα της σειράς

Εισαγωγή στο Domain Name System

Οι name servers στο μικροσκόπιο

Zone files και resource records

Ο δικός μας caching name server

Στρατηγικές εκμετάλλευσης του name server μας