Σε αυτό το κείμενο περιγράφονται οι βασικές αρχές λειτουργίας του DNS (Domain Name System), καθώς και η βασική παραμετροποίηση του δημοφιλέστερου DNS server, του BIND.
__TOC__
Εισαγωγή
Το Internet είναι βασισμένο στο IP πρωτόκολλο, το οποίο διασφαλίζει την επικοινωνία μέσω της μοναδικότητας των μονάδων του (hosts). Κάθε host χαρακτηρίζεται από μία διεύθυνση αποτελούμενη από τέσσερις ομάδες ψηφίων (octets), κάθε μία από τις οποίες φέρει μέγιστη τιμή 2^8 (255). Κάθε μονάδα για να προσπελάσει και να προσπελαστεί από μία άλλη και να διατελέσει τις δραστηριότητες που καθορίζονται από τα υψηλότερου επιπέδου πρωτόκολλα, χρησιμοποιεί ως αναγνωριστικό την IP address. Πρακτικά, αυτό σημαίνει για παράδειγμα ότι όταν εμείς θέλουμε να αντλήσουμε δεδομένα από το αγαπημένο μας website, ο υπολογιστής (ή ο router) μας, όντας μία μονάδα του internet, επικοινωνεί με τον server εντοπίζοντας τον από την IP address του και στέλνοντας ως αναγνωριστικό τη δική του.
Ωστόσο εάν οι αριθμητικές διευθύνσεις είναι ό,τι καλύτερο χρειάζεται ο υπολογιστής, δεν είναι ότι καλύτερο και για τους ανθρώπους. Για λόγους απομνημόνευσης, κομψότητας και ευκαμψίας (στη διαχείριση) χρειαζόταν ένα naming address scheme που θα περιελάμβανε αλφαβητικούς χαρακτήρες και θα επέτρεπε την αποκεντρωτική διαχείριση. Αυτό μπορούσε να γίνει ευκολότερα, ευφυέστερα και χωρίς αλλαγή στο IP, λειτουργώντας ως μία υπηρεσία υψηλότερου επιπέδου, πάνω από το IP, και έτσι έγινε. Έτσι το 1983 δημιουργήθηκε το DNS από τον Paul Mockapetris, καθώς και η πρώτη υλοποίηση server με το όνομα "Jeeves", που έτρεχε σε TOPS-20 λειτουργικό. Το DNS λοιπόν είναι ένα σύστημα που αναλαμβάνει την αντιστοίχηση IP διεύθυνσης και Hostname (η hostname με hostname), προβλέποντας και τις απαιτήσεις για κάτι τέτοιο σε δίκτυα μεγάλου βεληνεκούς στα οποία τα domains και οι διευθύνσεις είναι πολυπληθή και μεταβάλλονται συχνά και οι πόροι μπορούν να φανούν ανεπαρκείς.
Θεωρία
Γενικά
Το DNS είναι στην ουσία μία διανεμόμενη και αρθρωτή βάση δεδομένων. Αρθρωτή γιατί φιλοξενείται σε πολλούς και διασπαρμένους nodes (ή μονάδες αναφοράς), κανένας από τους οποίους δεν περιέχει ολόκληρη τη βάση, και διανεμόμενη γιατί οι πληροφορίες της μοιράζονται και αντιγράφονται αυτοματοποιημένα από τον ένα node στον άλλον. Η δομή του DNS είναι ιεραρχική και δενδρική, που σημαίνει ότι τα πάντα ξεκινάνε από ένα σημείο, τη ρίζα (το οποίο εκφράζουμε με μία τελεία ".") και κάτω από αυτό εκτείνεται ένα "δένδρο" από καταχωρήσεις κάθε μία από τις οποίες υπάγεται σε κάποια άλλη. Κάθε καταχώρηση ονομάζεται περιλαμβάνοντας όλες τις μητρικές καταχωρήσεις (καταχωρήσεις υψηλότερου επιπέδου) στα δεξιά του ονόματός της (γνωστού και ως hostname), χωρισμένες μεταξύ τους από μία τελεία, που είναι στην ουσία σημείο διακλάδωσης (branching point). Δηλαδή το domain http://www.microsoftsucks.com, παραπέμπει στην καταχώρηση "www" της καταχώρησης "microsoftsucks", που με τη σειρά του είναι καταχώρηση της "com", που τέλος με τη σειρά της είναι καταχώρηση του ".", της ρίζας. Όπως είναι προφανές, η ρίζα είναι το μοναδικό σημείο το οποίο αν κατέρρεε θα προκαλούσε και την ολική κατάρρευση όλων των διακλαδώσεων. Τη ρίζα του Internet DNS τη διαχειρίζεται η Internic. Η ρίζα, ως σημείο αρχής των πάντων πρέπει να ορίζεται πάντα, όποτε θέλουμε να εκφράσουμε τη πλήρη διαδρομή μίας καταχώρησης, απλά για λόγους ευχρηστίας και επειδή για την περίπτωση των clients πάντα θέλουμε, έχει επικρατήσει οι *resolvers μας να δέχονται από τους clients domains για αντιστοίχηση χωρίς την ρίζα στο τέλος, και να τα ερμηνεύουν ως πλήρους διαδρομής καταχωρήσεις με αρχή τη ρίζα. Εμείς επειδή θα ασχοληθούμε με τον server, θα την ορίζουμε πάντα.
*resolver είναι η εφαρμογή που αναλαμβάνει να επικοινωνήσει με έναν DNS server (να στείλει ένα query), συνήθως για λογαριασμό κάποιας άλλης εφαρμογής και να της παραδώσει την απάντηση. Κάθε λειτουργικό σύστημα με TCP/IP υποστήριξη τυπικά ενσωματώνει ένα resolver στο API του.
Συνεχίζοντας, ξαναγυρίζουμε στο παράδειγμα του δένδρου. Όπως κάθε κλαρί ενός δένδρου περιλαμβάνει φύλα αλλά και άλλα κλαριά, έτσι ένα domain μπορεί να υπάρχει απλά ως καταχώρηση σε κάποιο άλλο domain, ή μπορεί να αποτελεί παράλληλα γονέα και για άλλα domains. Στο DNS, στην πρώτη περίπτωση το ονομάζουμε RR (Resource Record) και στη δεύτερη Zone. Θα εξετάσουμε παρακάτω πως ορίζουμε κάθε ένα στο configuration του BIND, καθώς και ορισμένες επιμέρους κατηγοριοποιήσεις. Για την ώρα προχωράμε με κάποιες ακόμα ιδιότητες της λειτουργίας του DNS.
Για τη λειτουργία του DNS σε εκτενή δίκτυα όπως το Internet, χρειάζεται το σύστημα να δουλεύει αποκεντρωτικά (διαμοιρασμένος φόρτος εργασίας, μεγαλύτερη αξιοπιστία), αλλά να παραμείνει και έγκυρο. Αυτό κατορθώνεται με τον ορισμό των DNS Servers ως "Slave" (ή Secondary) και "Master" (ή Primary).
Recursive / Iterative queries
Υπάρχουν 2 είδη DNS ερωτημάτων: Recursive και Iterative. Συνήθως, αν ένας DNS server δέχεται Recursive queries, τότε θα ακολουθήσει τα εξής τρία βήματα για να εξυπηρετήσει το query:
- Θα ελέγξει την Cache του μήπως υπάρχει εκεί η απάντηση, αν όχι:
- Θα στείλει ένα iterative query στον τοπικό resolver (ο οποίος χρησιμοποιεί τους DNS servers που αναφέρονται στο configuration του, πχ για τα περισσότερα Unices /etc/resolv.conf) και αν δεν πάρει απάντηση για την διεύθυνση του authorative server της ζητούμενης ζώνης ή κάποιου μητρικού του:
- Θα καταφύγει στη λιγότερο επιθυμητή λύση (λιγότερο επιθυμητή γιατί συνεπάγεται τα περισσότερα queries, δηλαδή σε όλους τους parent authorative servers μέχρι και τον ζητούμενο), να ρωτήσει τους ίδιους τους rootservers, οι οποίοι θα τον παραπέμψουν στον authorative του μητρικού domain κ.ο.κ μέχρι να φτάσει σε κάποιο authorative του ζητούμενου domain. Αν αποτύχει να φτάσει εκεί, τότε θα επιστρέψει error.
Ένας server που εξυπηρετεί μόνο non-recursive queries, τότε αν αποτύχει το πρώτο βήμα, θα στείλει με τη σειρά του ένα non-recursive query στον τοπικό resolver, ή στους rootservers και θα δώσει αυτή την προσεγγιστική απάντηση στον client (hint) ο οποίος θα αναλάβει ο ίδιος το recursion, δηλαδή να κάνει query έναν-έναν τους servers μέχρι να φτάσει στο επιθυμητό αποτέλεσμα. Αυτή η διαδικασία ονομάζεται και "walking the tree". Σε κάθε περίπτωση, το query και η απάντηση αποθηκεύονται στην cache για το χρονικό διάστημα που έχει ορίσει ο εκάστοτε Master server (TTL). Αυτό συμβαίνει ακόμα και αν η απάντηση είναι ένα error που δηλώνει την αποτυχία του server, οπότε ονομάζεται negative caching, μόνο που τότε το χρονικό διάστημα αποθήκευσης τις περισσότερες φορές καθορίζεται από τον ίδιο τον caching server.
Η τυπική διαδικασία για το dns resolution του rootforge.org. Η διαδοχή των σχημάτων αντιπροσωπεύει την σειρά των ενεργειών με τη φορά του ρολογιού, μέχρι να υπάρξει positive answer. Οι κόκκινες γραμμές αντιπροσωπεύουν το ερώτημα (query), οι μπλε προσδιοριστικές απαντήσεις που προσδιορίζουν τους authorative servers ή μητρικούς τους (οι οποίοι θα ερωτηθούν στη συνέχεια, σύμφωνα με τη διαδικασία του recursion) και οι πράσινες την ίδια την απάντηση στο ερώτημα. Ο ORG. TLD server σε ότι αφορά την κατανόηση του σχήματος, είναι απλά ένας μητρικός του domain μας server και μπορούμε να εννοήσουμε όσους τέτοιους θέλουμε (ανάλογα το επίπεδο του domain).
Διακρίσεις DNS servers
Master/Primary Servers
Ένας Master DNS server είναι αρμόδιος (authorative) τουλάχιστον μίας ζώνης, δηλαδή περιλαμβάνει τις ακριβείς πληροφορίες (όλα τα resource records) αυτής της ζώνης. Είναι ακόμα ο server που θα αναλαμβάνει την ανάθεση αρμοδιότητας (delegation of authority) για τα domains ενός βαθμού υψηλότερα από την ζώνη που ελέγχει, σε άλλους Master DNS servers. Πρακτικό παράδειγμα, έστω ότι έχουμε το domain "rootforge.com". Είναι ένα domain δευτέρου επιπέδου, για το οποίο έχει ανατεθεί αρμοδιότητα στο DNS της επιλογής μας, από έναν rootserver (κεντρικό server) που έχει την αρμοδιότητα για το TLD (Top Level Domain) "com". Ο server της επιλογής μας θα πρέπει να έχει μία ζώνη η οποία να περιέχει ακριβώς τις αντιστοιχίσεις (mappings) του "rootforge.com" και των subdomains αμέσως υψηλότερου βαθμού ("κάτι.rootforge.com) με τις IP διευθύνσεις ή με τα domains (ανάλογα το είδος του Resource Record). Για την περίπτωση που θέλαμε να έχουμε domains ακόμα υψηλότερου βαθμού (π.χ. "κάτι.nske.rootforge.com"), θα έπρεπε να κάνουμε 2 πράγματα:
- Να περιλάβουμε στη ζώνη του rootforge.com ένα "NS" Resource Record για το nske.rootforge.com subdomain που να έχει τιμή το domain του DNS server ο οποίος θα είναι authoritative (αρμόδιος) για το domain "nske.rootforge.com", κάνοντας έτσι ανάθεση αρμοδιότητας (authority delegation) σε αυτόν τον dns server.
- Να φτιάξουμε μία ζώνη στον server που δηλώσαμε ως authorative για το nske.rootforge.com η οποία θα περιέχει όλα τα Resource Records για αυτό το domain.
Slave/Secondary Servers
Ένας Slave DNS server, είναι ένας server ο οποίος έχει ρυθμιστεί να συνδέεται σε τακτά διαστήματα σε έναν ή περισσότερους master servers και να μεταφέρει τοπικά τις πληροφορίες για τις ζώνες τους. Έτσι είναι και αυτός ένας authorative server, όμως η εγκυρότητα των πληροφοριών του εξαρτάται από το πόσο πρόσφατα τις έχει αντλήσει από τον authorative Master server. Οι Slave DNS servers υπάρχουν κατά κύριο λόγο για λόγους αξιοπιστίας, εάν δηλαδή καταρρεύσει ο Master να συνεχίσουν να εξυπηρετούνται οι αιτήσεις, αλλά και για να μοιράζεται το traffic. Για να λειτουργήσει έτσι, χρειάζεται στη ζώνη που πρόκειται να εξυπηρετηθεί, να περιλαμβάνεται και ο Slave, σε ένα NS RR. Η διαδικασία ενημέρωσης των ζωνών λέγεται Zone Transfer (μεταφορά ζώνης) και η συχνότητά της εξαρτάται από το configuration του Master Server.
Caching-Only Servers
Ένας server που λειτουργεί ως caching-only, είναι ένας server ο οποίος δεν έχει αρμοδιότητα για καμία ζώνη, αλλά αναλαμβάνει να επικοινωνήσει με τους authorative servers μίας ζώνης για την οποία ρωτήθηκε και να επιστρέψει την απάντηση. Παράλληλα την αποθηκεύει σε μία cache, στη μνήμη συνήθως (temporary cache), ώστε να την έχει έτοιμη τοπικά σε περίπτωση που του ξαναζητηθεί. Caching-only DNS servers είναι κατά κανόνα οι servers των ISPs που χρησιμοποιούνται από τους χρήστες τους.
Forwarding Servers
Ένας DNS server μπορεί να ρυθμιστεί να λειτουργεί προωθώντας τα queries σε άλλους servers, ως recursive queries, και απλά να παραλάβει την απάντηση και να την παραδώσει στον client. Και σε αυτή την περίπτωση βέβαια, ελέγχει συνήθως πρώτα την cache του αν υπάρχει ακριβής απάντηση και αντίστοιχα καταγράφει την απάντηση όταν του παραδοθεί. Ουσιαστικά ένας forwarding dns είναι ρυθμισμένος αν δεν έχει στην cache του την απάντηση να "αγγαρέψει" τους servers που του έχουμε ορίσει για απάντηση με τον ίδιο τρόπο που ο client "αγγάρεψε" αυτόν 
. Φυσικά ο server που θα αγγαρευτεί θα πρέπει είτε να είναι ρυθμισμένος να εξυπηρετεί recursive queries, είτε να είναι και ο ίδιος forwarding server. Οι DNS forwarding servers χρησιμοποιούνται σε αρκετά εξειδικευμένες περιπτώσεις, όπου λειτουργούν πίσω από περιοριστικά firewalls ή τίθεται θέμα ανεπάρκειας των διαθέσιμων πόρων.
*Μερικές σημειώσεις:
- Όταν αναφερόμαστε σε "dns server" δεν εννοούμε αναγκαστικά ένα και μόνο μηχάνημα με ένα DNS service σηκωμένο, αλλά οποιοδήποτε αριθμό DNS servers το οποίο σε ότι μας ενδιαφέρει λειτουργεί ως μία DNS μονάδα. Θα μπορούσε (και έτσι είναι συνήθως σε μεγάλα κέντρα του δικτύου) να είναι ένας αριθμός μηχανημάτων σε ένα εσωτερικό δίκτυο πίσω από έναν router, τα οποία να μοιράζονται το traffic μεταξύ τους, πχ με "round robin" τεχνική (*Round Robin: οι servers σα να περιστρέφονται, αν υποθέσουμε ότι το μηχάνημα που αντιστοιχεί στον αριθμό "1" αναλαμβάνει πάντα να εξυπηρετήσει την τρέχουσα αίτηση, με την λήψη της αίτησης το κάθε μηχάνημα παίρνει x+1 δείκτη, όπου x ο τρέχον δείκτης, εκτός από το τελευταίο το οποίο παίρνει 1. Έτσι κατανέμονται όσο το δυνατόν περισσότερο ισοδύναμα οι πόροι.
- Ένας DNS server δεν λειτουργεί κατ' ανάγκη ως ένα είδος DNS server (Primary, Slave, Recursive Caching, Iterative Caching, Forwarding, Stealth) αλλά μπορεί να λειτουργεί με οποιοδήποτε συνδυασμό των παραπάνω, ανάλογα την περίπτωση και το configuration του.
Reverse Mapping
Μία σημαντική DNS λειτουργία του Internet είναι το Reverse Mapping. Το reverse mapping έχει οριστεί να αναλαμβάνει την αντιστοίχηση IP διευθύνσεων σε canonical names (hostnames). Για να γίνει αυτό, χρειάστηκε να φτιαχτεί ένα TLD το οποίο ονομάστηκε "arpa." (το οποίο δε διαφέρει σε τίποτα από ένα TLD όπως το com. ή το org.). Μέσα του υπάρχουν άλλα υπο-domains, εμάς μας ενδιαφέρει το "IN-ADDR" γιατί αυτό αφορά στην κλάση του Internet. Στη συνέχεια, μέσα στο domain "in-addr.arpa.", υπάρχουν άλλα 255 domains, ένα για κάθε αρχικό IP address octet, με το όνομα του (π.χ. 69.in-addr.net). Εκεί μέσα υπάρχουν άλλα 255 domains κ.ο.κ, μέχρι να συμπληρωθούν και τα τέσσερα IP address octets. Το ότι παραθέτονται αντεστραμένα οφείλεται στο ότι ενώ στο format των IP διευθύνσεων το γενικό μέρος (δίκτυο) δηλώνεται στα αριστερά και στο τέλος μένει ο host, στo format του DNS το γενικό (domain) μπαίνει στα δεξιά και αριστερά του το ειδικό (host).
Έχουμε λοιπόν ένα standard name space "IN-ADDR.ARPA.", το οποίο περιλαμβάνει καταχωρήσεις για όλες τις IP διευθύνσεις. Το dns έχει προβλέψει την ύπαρξη ενός τύπου query ειδικά για reverse mapping resolution, ώστε το "IN-ADDR.ARPA." namespace να υπάρχει μόνο λειτουργικά και η διαδικασία να γίνεται απλά και διάφανα από τις εφαρμογές και τον χρήστη.
Τις IN-ADDR.ARPA καταχωρήσεις μπορούμε να τις κάνουμε map όπου θέλουμε, κανονικά όπως προβλέπεται από το RFC, θα πρέπει να αντιστοιχήσουμε την κάθε IP για την οποία ήμαστε υπεύθυνοι (μέσω PTR records) σε ένα πραγματικό hostname (που να είναι και το ίδιο mapped μέσω Address record με την IP του host). Αυτό κατά κανόνα είναι που κάνουν οι υπεύθυνοι ISPs οι οποίοι διαθέτουν ολόκληρα IP ranges (ούτως ή άλλως συμβατικά μπορεί να οριστεί αρμόδιος server για ένα IN-ADDR.ARPA. domain μόνο με ακρίβεια octet, δηλαδή στην καλύτερη μίας κλάσης C IP διευθύνσεων). Ωστόσο υπάρχει ένα κάπως πολύπλοκο hack ως λύση, το οποίο επιτρέπει το αποτελεσματικό authority delegation σε άλλον server οποιουδήποτε range. Το hack αυτό περιγράφεται στο RFC2317 και χρησιμοποιείται από τους περισσότερους ISPs πλέον. Ο καθένας που διαθέτει στατική IP μπορεί να ζητήσει από τον ISP του το authority delegation για το reverse mapping της IP του σε δικό του server, ώστε να την αντιστοιχήσει σε ό,τι θέλει, ή την αλλαγή του record στον server του ISP. Σε ελάχιστες περιπτώσεις μόνο θα υπάρξει άρνηση, κυρίως σε περιπτώσεις που χρησιμοποιούν το reverse DNS mapping ως αναγνωριστικό για δικές τους υπηρεσίες όπως στατιστικά traffic, access control κλπ. όπου θα ήταν μπελάς.
Στο internet μπορείτε να συναντήσετε πολλούς hosts οι οποίοι δε διαθέτουν reverse DNS record, και άλλους που δε διαθέτουν πραγματικό, αλλά ένα ανύπαρκτο domain. Στην πρώτη περίπτωση, ο host θα αντιμετωπίζει προβλήματα και καθυστερήσεις όταν λειτουργεί ως server για κάποια services (κυρίως mailservers) και τα emails που αποστέλλονται από αυτόν μπλοκάρονται από πολλούς ISPs με αυστηρό antispam policy.
BIND DNS Implementation
Γενικά
Ο BIND (Berkeley Internet Name Domain) είναι ιστορικά η δεύτερη υλοποίηση DNS server και η ευρύτερα διαδεδομένη μέχρι σήμερα. Γράφτηκε το 1985 από τον Kevin Dunlap για το BSD Unix και αποτελεί την πιο σωστή προσέγγιση στα DNS specifications. Πλέον συντηρείται από το Internet Systems Consortium με ελεύθερη άδεια χρήσης και η ανάπτυξή του προχωράει σύμφωνα με την αιχμή της τεχνογνωσίας σχετικά με το DNS.
Εγκατάσταση του BIND
- Εγκαθιστούμε τον BIND από το πακέτο της διανομής μας και τον ρυθμίζουμε να εκτελείται αυτόματα στο default runlevel
- Τώρα είμαστε έτοιμοι για το configuration.. Ξεκινάμε φτιάχνοντας το αρχείο /etc/named.conf. To αρχείο αυτό περιλαμβάνει κάθε παράμετρο που αφορά στη γενική συμπεριφορά του BIND και τις πιο βασικές παραμέτρους για κάθε ζώνη.
// Στο block options{} μπαίνουν οι γενικές παράμετροι. Αναφέρω τις πιο χρήσιμες.
options {
directory "/var/named";[/b]
// "Path" όπου βρίσκοντα τα αρχεία των ζωνών
query-source address * port 53;
// IP_NIC_που_θα_γίνει_bind()_ο_daemon (με * ακούει σε όλα τα NIC) port Αριθμός_Πόρτας
allow-query { any; };
// IP_addr || ACL_name || none/any || localhost || localnets. Από πού θα δέχεται queries ο server
allow-recursion { none; };
// IP_addr || ACL_name || none/any || localhost || localnets. Από πού θα δέχεται recursive queries ο server
blackhole { none; };
// IP_addr || ACL_name || none/any || localhost || localnets. Aπό πού ΔΕΝ θα δέχεται queries ο server
notify yes ;
// yes || no || explicit. Αν θα ενημερώνει by default τους slave servers μίας ζώνης όταν αυτή ανανεωθεί για να κατεβάσουν το νέο αντίγραφο. Με "explicit" θα ενημερώνονται μόνο οι slaves που εμπεριέχονται στην "also-notify" directive μίας ζώνης.
};
// Στο block zone "Όνομα-Ζώνης"{} μπαίνουν οι βασικές παράμετροι της κάθε ζώνης. Έχουν μεγαλύτερη προτεραιότητα (για τη συγκεκριμένη ζώνη) από τυχόν κοινές παραμέτρους του options{} block. Αναφέρω τις πιο χρήσιμες.
zone "rootforge.com"{
type master;
// slave || master. Λειτουργία του server για αυτή τη ζώνη, slave ή master.
file "named.rootforge.org";
// filename. Όνομα αρχείου μέσα στο directory path
notify yes;
// Όπως παραπάνω
allow-query { any; };
// Όπως παραπάνω
allow-transfer { 10.26.122.21; };
// IP_addr || ACL_name || none/any || localhost || localnets. Από πού θα δέχεται ο server να κατέβει αντίγραφο της ζώνης.
allow-update { none; };
// IP_addr || ACL_name || none/any || localhost || localnets. Από πού θα δέχεται ο server να ανανεωθούν οι πληροφορίες της ζώνης.
masters { 10.26.122.20; };
// IP_addr || ACL_name || none/any || localhost || localnets. Ποιος είναι ο Master Server της ζώνης, αν ο server μας έχει οριστεί slave.
};
// Στο block ACL "Όνομα-List"{} μπορούμε να ονομάσουμε μία δική μας Access Control List, δηλαδή μία λίστα με IP addresses ή ολόκληρα subnets. Έτσι θα μπορούμε να δίνουμε στις παραμέτρους κάθε ζώνης το όνομα της λίστας κάθε φορά αντί να χρειάζεται να γράφουμε το περιεχόμενό της. Μπορούμε μέσα είτε να παραθέσουμε τις IP addresses τη μία κάτω απ' την άλλη, είτε να δώσουμε IP και subnet με το παρακάτω *format.
acl "trusted" {
10.26.122.0/27;
};
// * Πχ το 10.26.122.0/27 θα ανταποκρίνεται σε ένα subnet όπου "μασκάρονται" (περιγράφουν το δίκτυο) τα 27 bits από τα συνολικά 32, δηλαδή στο subnet 255.255.255.224.
// Στο block Logging{} περιέχεται ότι παράμετρος έχει να κάνει με την καταγραφή των δραστηριοτήτων του server (logging). Αναφέρω τις πιο συνηθισμένες.
logging{
channel input-xfers {
// Επειδή ο Bind μπορεί να καταγράφει μηνύματα από μεγάλη ποικιλία δραστηριοτήτων, θα ήταν άβολο να αποθηκεύονταν όλα σε ένα αρχείο. Το υπο-block channel λοιπόν ονομάζει ένα logging facility, δηλαδή ένα μέρος που θα κρατιούνται logs για κάποια ή κάποιες συγκεκριμένες κατηγορίες (θα ορίσουμε αργότερα ποιες). Συνεπώς μπορούμε να έχουμε πολλά channels, κάθε ένα από τα οποία θα καταγράφει logs για διαφορετικές διεργασίες του server σε διαφορετικό μέρος και με διαφορετικό μήκος ιστορικού.
file "/var/logs/named/xfers_in.log" versions 3 size 20m;
// Στο file option δίνουμε το όνομα του αρχείου όπου θα καταγράφονται τα μηνύματα αυτού του channel. Στην παράμετρο versions ορίζουμε τα επίπεδα του rolling, δηλαδή πόσες εκδόσεις του αρχείου θα κρατιούνται. Κάθε φορά που γίνεται start o daemon ή το xfers_in.log φτάνει το size limit -αν έχουμε ορίσει-, θα γίνεται rename σε xfers_in.log.0, το xfers_in.log.0 σε xfers_in.log.1 κ.ο.κ, μέχρι το version number που έχουμε δηλώσει, το οποίο ως παλαιότερο διαγράφεται. Για το size τώρα, μπορούμε να δηλώσουμε απλά αριθμό ο οποίος θα δηλώνει bytes, ή να δώσουμε τον αριθμό και μονάδα δίπλα, δηλαδή xm για x MB, xk για x ΚΒ και xg για x GB.
print-time yes;
// yes || no. Αν θα καταγράφεται ημερομηνία και ώρα για κάθε μήνυμα στο logfile
print-severity no;
// yes || no. Αν θα καταγράφεται το επίπεδο σημαντικότητας κάθε μηνύματος
};
// Κλείνει το block του channel, με τον ίδιο τρόπο μπορούμε να ονομάσουμε όσα channels θέλουμε. Πρώτα θα πρέπει να πάρουμε μία ιδέα για τις διαθέσιμες κατηγορίες, ώστε να αποφασίσουμε ποιες μας ενδιαφέρουν και ποιες από αυτές μπορούν να εξυπηρετούνται στο ίδιο logfile.
category xfer-in {
// default || config || parser || queries || lame-server || statistics || panic || update ||ncache || xfer-in || xfer-out || db || eventlib || packet || notify || cname || security || os || insist || maintenance || load || response-checks. Αυτές είναι οι διαθέσιμες κατηγορίες, για να μην ξεφύγουμε δεν περιγράφω που αναφέρεται κάθε μία, μπορείτε να τις ελέγξετε από το manual page. Το συγκεκριμένο παράδειγμα, input-xfers, αναφέρεται στα μηνύματα που προκύπτουν από τα zone transfers προς τον server μας.
"input-xfers";
// Το όνομα ενός channel που έχουμε δημιουργήσει και θέλουμε να χρησιμοποιήσουμε για τον έλεγχο των logs αυτής της κατηγορίας. Μπορούμε να βάλουμε πολλά channels το ένα κάτω από το άλλο.
};
};
Εδώ τελειώσαμε με το configuration του server και συνεχίζουμε με την κατασκευή της βάσης, δηλαδή των zone files του.
- Πηγαίνουμε στον κατάλογο που έχουμε ορίσει για directory, /var/named, και δημιουργούμε το αρχείο που ορίσαμε σε κάθε "zone" statement του named.conf. Στο συγκεκριμένο παράδειγμα, προχωρούμε φτιάχνοντας το named.rootforge.org:
Κάθε γραμμή που ξεκινάει με ";" θεωρείται σχόλιο και αγνοείται.
$TTL 3Η
; Η διάρκεια εγκυρότητας (expiration time) όλων των Resource Records αυτής της ζώνης προς πληροφόρηση όλων των caching servers. Δηλαδή για πόσο χρονικό διάστημα θα μένουν οι πληροφορίες στην cache των non-authorative caching servers. Δηλώνουμε την τιμή δίπλα στην ένδειξη της μονάδας (D για Μέρες, W για εβδομάδες, H για ώρες, M για λεπτά και S για δευτερόλεπτα). Όσο μικρότερη τιμή τόσο γρηγορότερα θα απορρίπτονται οι απαντήσεις προηγούμενων αιτήσεων από την cache περιφερειακών servers, πρακτικά τόσο γρηγορότερα θα λαμβάνουν ισχύ οι αλλαγές μας αλλά και τόσο μεγαλύτερος φόρτος εργασίας θα δημιουργείται. Μία συνηθισμένη τιμή είναι 3 ημέρες (3D), αν δεν είναι πρόβλημα το traffic, πχ αν ο server είναι αρμόδιος για λίγα και μέτριας επισκεψιμότητας domains μπορείτε να βάλετε μία μικρή τιμή όπως 3 ώρες (3H). Το TTL πρέπει να δηλώνεται πρώτο, στη συνέχεια ακολουθούν τα RR της ζώνης. Κάθε RR μπορεί να έχει δικό του TTL, δηλωμένο ακριβώς μετά το όνομά του.
; Domain Name Class RR Type Master Auth. Server Hostmaster Email
@ IN SOA ns1.rootforge.org. nske.rootforge.org. (
2004061400 ; Serial Number
2D ; Refresh Period
2H ; Retry Frequence
4W ; Expiration Time
1H ; Negative Cache Expiration Time
)
; Το πρώτο RR πρέπει να είναι πάντα το SOA (Start Of Authority). Σε κάθε ζώνη δηλώνεται μόνο ένα SOA RR που δηλώνει τη διεύθυνση του DNS server ο οποίος είναι authorative γι' αυτό το domain (το domain "@" αντιπροσωπεύει την τιμή της μεταβλητής $ORIGIN, η οποία by default είναι το αρχικό domain της ζώνης, ανά πάσα στιγμή μπορούμε να την ορίσουμε σε ό,τι θέλουμε, $ORIGIN "value" ). Η "κλάση" περιγράφει την κλάση του πρωτοκόλλου, πάντα την ορίζουμε IN (Internet Protocol). Στη συνέχεια δηλώνεται μία δεύτερη τιμή η οποία μοιάζει και αυτή με domain, αλλά στην πραγματικότητα δηλώνει το email του διαχειριστή του DNS server, του Hostmaster (απλά επειδή ο χαρακτήρας "@" έχει συγκεκριμένη χρήση στο συντακτικό του αρχείου ζώνης, αντικαθίσταται με τελεία). Στη συνέχεια, δηλώνονται ορισμένες ακόμα τιμές όπως βλέπουμε. Η πρώτη (Serial Number), είναι ένας ακέραιος αριθμός 32-bit (με τιμή από 1 μέχρι 2147483647), ο οποίος δηλώνει την "έκδοση" του αρχείου ζώνης. Οι περιφερειακοί servers γνωρίζουν αν έχουν αλλάξει οι πληροφορίες της ζώνης κοιτάζοντας αυτή την τιμή και μόνο αν είναι μεγαλύτερη από την τελευταία φορά που έλεγξαν ανανεώνουν την cache τους. Μπορούμε να βάλουμε ό,τι θέλουμε, το σημαντικό είναι με κάθε αλλαγή στο αρχείο ζώνης να ανεβάζουμε την τιμή του. Συνηθισμένο format για να μη μπερδευόμαστε είναι το εξής: ΧρονολογίαΜήναςΗμερομηνίαΔιψήφιοςΑριθμός, πχ 2004071200 για μία αλλαγή που έγινε στις 12-7-2004 και είναι η πρώτη αυτής της ημέρας. Ο επόμενος αριθμός (Refresh Period), δηλώνει πόσο τακτικά θα ελέγχουν οι Secondary Servers για ανανεωμένες εκδόσεις του αρχείου ζώνης. Πλέον δεν έχει τόση σημασία εφόσον υπάρχει η επιλογή notification (περιγράφεται στις ρυθμίσεις του named.conf παραπάνω). Μπορούμε να δηλώσουμε μία μεγάλη τιμή όπως 2D. Ο επόμενος αριθμός (Retry Frequency) δηλώνει το χρόνο που θα μεσολαβήσει σε περίπτωση που αποτύχει η σύνδεση κάποιου secondary server με τον primary, μέχρι να ξαναπροσπαθήσει. Μία λογική τιμή είναι 2H. Ο επόμενος αριθμός (Expiration Time) δηλώνει πόσο γρήγορα ένας Slave server που δε μπορεί να επικοινωνήσει με τον Μaster του θα συνεχίσει να εξυπηρετεί αιτήσεις με το αντίγραφο της ζώνης που έχει. Μετά από αυτό το διάστημα, εφόσον δεν έχει καταφέρει να επικοινωνήσει με τον Master, θα συνεχίσει να προσπαθεί σύμφωνα με το Retry Frequency, αλλά δε θα αποκρίνεται σε αιτήσεις για αυτή τη ζώνη. Μία τυπική τιμή είναι 1 μήνας (4W). Τέλος, η τελευταία τιμή (Negative Cache Expiration Time) στον Bind 9 δηλώνει το διάστημα για το οποίο θα κρατηθεί στην cache του server μία αρνητική απάντηση (NXDOMAIN Record) για ένα domain που ρωτήθηκε και δε μπόρεσε να βρει. Μέγιστη τιμή είναι 3H.
NS ns1.rootforge.com.
NS ns2.rootforge.com.
nske NS ns1.nske.rootforge.com.
nske NS ns2.nske.rootforge.com.
; Με NS RR ορίζουμε όλους τους servers οι οποίοι είναι authorative για το εκάστοτε domain name. Όπως βλέπουμε μπορούμε να παραλείψουμε αν θέλουμε το Domain Name ("@") και την Class ("IN"), καθώς εννοούνται αυτά που δηλώσαμε στο παραπάνω RR. To Domain name "nske" αντιστοιχεί σε "nske.@", δηλαδή σε nske.rootforge.com. Θα μπορούσαμε να δώσουμε ολόκληρο το domain name, αλλά θα έπρεπε να συμπεριλάβουμε και το root (την "."). Στο συγκεκριμένο παράδειγμα ορίζουμε ότι authorative server για τη ζώνη nske.rootforge.com είναι ο ns1.nske.rootforge.com και o ns2.nske.rootforge.com υπάρχει ως secondary, οπότε οτιδήποτε σχετικό request θα στέλνεται εκεί.
@ A xxx.xxx.xxx.xxx
mail A xxx.xxx.xxx.xxx
mail2 A xxx.xxx.xxx.xxx
www A xxx.xxx.xxx.xxx
ns1 A xxx.xxx.xxx.xxx
ns2 A xxx.xxx.xxx.xxx
ns1.nske.rootforge.com. A xxx.xxx.xxx.xxx
ns2.nske.rootforge.com. A xxx.xxx.xxx.xxx
; Εδώ ορίσαμε τα Α records για αυτή τη ζώνη. Είναι τα records τα οποία αντιστοιχίζουν το domain με μία συγκεκριμένη IP address. Παρατηρούμε μία εξαίρεση μόνο, ότι ορίσαμε 2 domain names τα οποία δεν ανήκουν στην ζώνη μας. Αυτό γιατί έχουμε αναθέσει την αρμοδιότητα για κάποιο domain (nske.rootforge.com.) σε αυτούς τους dns, οι οποίοι έστω και αν δεν ανήκουν σε αυτή τη ζώνη χρειάζεται να έχουν ένα έγκυρο A record για να λειτουργήσει η διαδικασία του delegation (είναι το λεγόμενο "glue record"). Εφόσον ο dns server βρίσκεται σε ένα subdomain της ζώνης μας, αναγκαστικά θα πρέπει είτε σε αυτή (ή σε κάποια μητρική ζώνη, πχ στη ζώνη του .com.) να έχει δηλωθεί, αλλιώς προφανώς δε θα βρεθεί.
@ MX 10 mail.rootforge.com.
@ MX 20 mail2.rootforge.com.
; Επόμενος τύπος RR είναι το MX. To MX record αφορά μόνο στα emails και μας επιτρέπει χωρίς κόπο να παραπέμπουμε emails που αποστέλλονται σε λογαριασμούς κάποιου domain της ζώνης μας σε οποιονδήποτε mailserver θέλουμε. Δίπλα από τον τύπο του RR ("MX") μπαίνει προαιρετικά ένας αριθμητικός δείκτης. Έτσι μπορούμε να έχουμε πολλούς mailservers για να χειρίζονται emails από τα ίδια domains, είτε ορίζοντας διαφορετικούς δείκτες (ο mailserver με το μικρότερο δείκτη θα χρησιμοποιηθεί πρώτα και αν αποτύχει η σύνδεση σε αυτόν το email θα προωθηθεί σε αυτόν με τον αμέσως μεγαλύτερο) είτε ορίζοντας ίδιους δείκτες (θα επιλέγεται τυχαία ένας από τους mailservers κάθε φορά, ώστε να διαμοιράζεται ο φόρτος).
Αυτοί είναι οι βασικότεροι τύποι Resource Records, υπάρχουν και άλλοι αλλά η χρήση τους είναι πιο περιορισμένη και εξειδικευμένη. Τα σημαντικότερα από αυτά είναι :
ΑAAA – Address RR, παρόμοια με τα A Records μόνο που χρησιμοποιούνται για IPv6 διευθύνσεις.
CNAME – Canonical Names, δημιουργεί συντόμευση για ένα domain name σε ένα άλλο.
DNAME – Domain Name Aliases, δημιουργεί συντόμευση για ένα ολόκληρο domain σε ένα άλλο.
PTR – Domain Name Pointers, παρέχει τη δυνατότητα αντιστοίχησης domain names με άλλα domain names. Κατά κύριο λόγο χρησιμοποιείται για το Reverse DNS mapping των IP addresses σε canonical names, μέσω της in-addr.arpa διαμόρφωσης.
Διαγνωστικά και άλλα βοηθήματα του BIND
DIG - Η dig είναι ένα συνοδευτικό εργαλείο του bind που αντικαθιστά το παλαιότερο nslookup. Αυτό που κάνει είναι να φτιάχνει και να στέλνει iterative ή recursive udp ή tcp ερωτήματα στον DNS server της επιλογής μας και να μας παραδίδει την πλήρη απάντηση (χωρισμένη σε sections: question, answer, authority, additional). Η βασική σύνταξη της εντολής είναι “[dig domain name] @[dns server] [RR]”. Για παράδειγμα θα μπορούσαμε να ρωτήσουμε τον dns ns1.rootforge.com τι πληροφορίες έχει ο ίδιος για το http://www.rootforge.org A record δίνοντας
>$ dig A www.rootforge.org @ns1.rootforge.com
Τυχαίνει να είναι ο authorative server για αυτό το domain, οπότε θα πρέπει να μας επιστρέψει “answer section”. Επίσης θα μας επιστρέψει και Authority Section (τους authorative servers) ακόμα και αν δε του το ζητήσαμε. Ακόμα έχει κάποιες πρόσθετες πληροφορίες να μας επιστρέψει (τις IP διευθύνσεις όπου είναι mapped οι authorative servers).
Αναλυτικά:
;; QUESTION SECTION:
;http://www.hack-box.net.'>http://www.hack-box.net.'>http://www.hack-box.net. IN A
Το ερώτημα που υποβάλαμε. Εμείς ορίσαμε μόνο το domain name, οπότε οι υπόλοιπες πληροφορίες (ΙΝ class και Α RR) ορίστηκαν από το πρόγραμμα ως default.
;; ANSWER SECTION:
http://www.hack-box.net. 10800 IN CNAME http://www.rootforge.org.'>http://www.rootforge.org.'>http://www.rootforge.org.
http://www.rootforge.org. 10800 IN A 69.93.154.162
Το http://www.hack-box.net. είναι μία CNAME καταχώρηση mapped στο http://www.rootforge.org. Δεν υπάρχει Α RR για το http://www.hack-box.net, αλλά το CNAME RR ορίζει ότι θα είναι μία συντόμευση για το http://www.rootforge.org, το οποίο έχει A RR. Οπότε μας το βγάζει κι αυτό.
;; AUTHORITY SECTION:
hack-box.net. 10800 IN NS ns1.rootforge.com.
hack-box.net. 10800 IN NS ns2.rootforge.com.
Οι authoritative servers, επιστρέφονται πάντα όταν γνωρίζονται από τον ερωτώμενο server.
;; ADDITIONAL SECTION:
ns1.rootforge.com. 259200 IN A 69.93.154.162
ns2.rootforge.com. 259200 IN A 69.93.154.162
Τα A RR των authoritative servers, επιστρέφονται πάντα όταν γνωρίζονται από τον ερωτώμενο server.
Μία άλλη χρήσιμη σύνταξη του dig είναι η "dig -x [IP]" η οποία στέλνει reverse dns queries για αυτή την IP διεύθυνση, στο in-addr.arpa namespace.
Αναφορές: