Σε αυτό το κείμενο περιγράφονται οι
βασικές αρχές λειτουργίας του DNS (Domain Name System), καθώς και η
βασική παραμετροποίηση του δημοφιλέστερου DNS server, του BIND.
Εισαγωγή
Το 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 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).
[h3]Recursive / Iterative queries[/h3]
Υπάρχουν 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).
[h3]Διακρίσεις DNS servers[/h3]
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 του.
[h3]Reverse Mapping[/h3]
Μία σημαντική 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
[h3]Γενικά[/h3]
Ο BIND (Berkeley Internet Name Domain) είναι ιστορικά η δεύτερη
υλοποίηση DNS server και η ευρύτερα διαδεδομένη μέχρι σήμερα. Γράφτηκε
το 1985 από τον Kevin Dunlap για το BSD Unix και αποτελεί την πιο σωστή
προσέγγιση στα DNS specifications. Πλέον συντηρείται από το Internet
Systems Consortium με ελεύθερη άδεια χρήσης και η ανάπτυξή του προχωράει
σύμφωνα με την αιχμή της τεχνογνωσίας σχετικά με το DNS.
[h3]Εγκατάσταση του BIND[/h3]
- Εγκαθιστούμε τον 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 διαμόρφωσης.
[h3]Διαγνωστικά και άλλα βοηθήματα του BIND[/h3]
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 τι πληροφορίες έχει ο ίδιος για το 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:
;www.hack-box.net. IN A
Το ερώτημα που υποβάλαμε. Εμείς ορίσαμε μόνο το domain name, οπότε οι υπόλοιπες πληροφορίες (ΙΝ class και Α RR) ορίστηκαν από το πρόγραμμα ως default.
Παράθεση
;; ANSWER SECTION:
www.hack-box.net. 10800 IN CNAME www.rootforge.org.
www.rootforge.org. 10800 IN A 69.93.154.162
Το www.hack-box.net. είναι μία CNAME καταχώρηση mapped στο
www.rootforge.org. Δεν υπάρχει Α RR για το www.hack-box.net, αλλά το
CNAME RR ορίζει ότι θα είναι μία συντόμευση για το 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.
Δημοσιεύθηκε στο http://www.insomnia.gr
Αναφορές:
Η εκκίνηση του υπό ανάπτυξη νεότερου λειτουργικού συστήματος της
Microsoft ολοκληρώνεται τόσο γρήγορα ώστε ο χρήστης δεν προλαβαίνει να
πατήσει το κατάλληλο πλήκτρο λειτουργιών για να την διακόψει σκόπιμα.
Όμως έτσι, καθίστανται αδύνατες απαραίτητες επιλογές όπως η δυνατότητα
εκκίνησης του συστήματος σε Safe Mode σε περίπτωση δυσλειτουργίας, η
εναλλακτική εκκίνηση όχι από τον δίσκο αλλά από DVD ή USB, η επιλογή
διαφορετικού λειτουργικού συστήματος ή η είσοδος στις ρυθμίσεις του
υλικού.
Αν
θέλετε τα αρχεία της Ελληνικής γλώσσας για το δημόσιο τμήμα (site) και
τη διαχείριση (admin) του Joomla 1.5.x είσαστε στο σωστό μέρος.
