Το προφίλ μας στο Google Plus
15

Πώς δουλεύουν τα δίκτυα: Ο δικός μας caching name server

Θέλουμε να πιστεύουμε ότι τα τρία άρθρα περί DNS, που δημοσιεύτηκαν στο τεύχος 046, έχουν βάλει στο νόημα ακόμη κι εκείνους που είχαν μόνο μια αμυδρή ιδέα για το θέμα. Πράγματι, καλύψαμε σημαντικό έδαφος και πλέον έχουμε κατανοήσει επαρκώς τη λογική του όλου συστήματος. Τόσο πολύ που έχει έρθει η ώρα να φτιάξουμε τον δικό μας name server, για τις ανάγκες του δικού μας τοπικού δικτύου.

Σε πολύ λίγο, σε ένα σύστημα με Ubuntu Server θα εγκαταστήσουμε το δημοφιλές BIND (Berkeley Internet Name Domain) και θα το ρυθμίσουμε ώστε να λειτουργεί ως caching name server για τα μηχανήματα του τοπικού δικτύου. Το BIND θα συμπεριφέρεται είτε ως recursive είτε ως forwarding name server. Πρόκειται για απόφαση που θα πάρουμε σταθμίζοντας τις ικανότητες του (εικονικού ή φυσικού) μηχανήματος με το BIND, το διαθέσιμο bandwidth για τις εξερχόμενες συνδέσεις προς το Internet, όπως επίσης και τη στάση μας ως προς την εξάρτηση από άλλους name servers.

Ας συζητήσουμε τα προηγούμενα λίγο πιο αναλυτικά. Κατ’ αρχάς η επιλογή του BIND δεν είναι μονόδρομος. Θα μπορούσαμε να επιλέξουμε άλλο λογισμικό, όπως, π.χ., είναι το Dnsmasq (caching και forwarding) ή το Unbound (caching και recursion ή forwarding). Όμως το BIND είναι εξαιρετικά ευέλικτο, κατάλληλο για απλά καθώς και για σύνθετα σενάρια, ενώ συναντάται συχνά στο Internet αλλά και σε τοπικά δίκτυα όλων των μεγεθών. Σκεφτήκαμε λοιπόν ότι, αν μη τι άλλο για εκπαιδευτικούς λόγους, δεν θα ήταν καθόλου κακή ιδέα να εξοικειωθούμε με το BIND, ξεκινώντας από τα ρηχά.

Σε ένα τυπικό οικιακό δίκτυο θεωρούμε ότι δεν υπάρχει θέμα με την ισχύ του μηχανήματος που θ’ αναλάβει χρέη name server. Πράγματι, το ρόλο αυτό θα μπορούσε να έχει ακόμη κι ένα Raspberry Pi. Στην απόφασή μας, λοιπόν, για το αν ο name server θα είναι recursive ή forwarding, θα βαρύνουν άλλοι παράγοντες. Σημειώστε πάντως ότι για τους clients δεν έχει καμία σημασία τι από τα δύο θα είναι: Το μόνο που μετράει γι’ αυτούς είναι η ικανότητα για caching — κι αυτή θα την έχουμε και στις δύο περιπτώσεις. Πώς πρέπει να συμπεριφέρεται ο name server μας, λοιπόν;

Recursive. Σ’ αυτή την περίπτωση o server δεν έχει ανάγκη άλλους resolvers. Όταν δεν βρίσκει στην τοπική του cache την απάντηση σε κάποιο ερώτημα, ξεκινά την αναζήτηση από τους root name servers, μετά από τον κατάλληλο TLD server, ύστερα από τον domain-level server που θα του υποδειχθεί κ.ο.κ. Τις απαντήσεις που παίρνει δεν τις επιστρέφει απλά στους ενδιαφερόμενους πελάτες, αλλά ταυτόχρονα τις αποθηκεύει και στην cache του για μελλοντική αναφορά (και για όσο χρόνο επιτρέπουν τα αντίστοιχα TTL). Αν δεν θέλετε τα ερωτήματα των πελατών σας να φτάνουν σε δημόσιους caching name servers ή σε εκείνους του ISP σας, προτείνεται τότε να ρυθμίσετε το BIND ώστε να λειτουργεί ως recursive name server.

Forwarding. Όταν ένας name server της κατηγορίας δεν βρίσκει στην cache του την απάντηση σε ερώτημα πελάτη, τότε αμέσως προωθεί το ίδιο ερώτημα σε άλλους name servers που του έχουμε υποδείξει και είναι ικανοί για recursion. Με το που μαθαίνει ένας forwarding name server μιαν απάντηση, τη γνωστοποιεί στον ενδιαφερόμενο πελάτη αλλά την αποθηκεύει και στην cache του για μελλοντική χρήση. Είναι προφανές ότι ένας forwarding name server είναι σχεδιασμένος ώστε να αποφεύγει τη βαριά δουλειά. Υπό αυτή την έννοια, όταν το bandwidth που διαθέτουμε προς τον έξω κόσμο είναι περιορισμένο ή/και όταν η ποιότητα της σύνδεσης είναι χαμηλή, τότε η επιλογή ενός name server του είδους αποτελεί άριστη ιδέα. Θα εξαρτώμαστε βέβαια από άλλους recursive name servers, όπως, π.χ., είναι εκείνοι της Google, της OpenDNS ή του ISP μας (δεν τους προτείνουμε), ωστόσο ένας τέτοιος συμβιβασμός δεν είναι απαραίτητα τραγικός.

Τι ακολουθεί
Σε πολύ λίγο θα εγκαταστήσουμε το BIND σε ένα μηχάνημα με Ubuntu Server LTS 14.04, το οποίο θα ρυθμίσουμε ώστε να λειτουργεί ως caching name server με ικανότητες για recursion. Βασιζόμενοι σ’ αυτή τη διαμόρφωση θα δούμε πώς τροποποιείται, ώστε εναλλακτικά το BIND να λειτουργεί ως forwarding name server. Δεν θα παραλείψουμε να κάνουμε και μερικές δοκιμές, ώστε τέλος πάντων να δούμε πόσο πιο γρήγορος είναι –αν είναι– ο δικός μας name server, σε σύγκριση με έναν μεγάλο και σπουδαίο όπως, π.χ., είναι εκείνοι της Google ή της OpenDNS. Σε αυτό το άρθρο παρουσιάζουμε και μερικές στρατηγικές εκμετάλλευσης του νέου name server. Εξετάζουμε, μ’ άλλα λόγια, τρόπους ώστε κάποιες ή και όλες οι συσκευές του LAN να εξυπηρετούνται από τον καινούργιο name server.

Εγκατάσταση BIND
Από την κονσόλα του Ubuntu Server ή απομακρυσμένα, μέσω SSH, ενημερώνουμε πρώτα την τοπική λίστα με τα πακέτα από τα διαθέσιμα αποθετήρια:

~$ sudo apt-get update

Αμέσως μετά εγκαθιστούμε το BIND (bind9), ένα πακέτο με χρήσιμα εργαλεία (bind9utils), καθώς και τη συνοδευτική τεκμηρίωση (bind9-doc, προαιρετικό πακέτο):

~$ sudo apt-get install bind9 bind9utils bind9-doc

Αυτό ήταν. Όλα τα αρχεία ρυθμίσεων του BIND είναι συγκεντρωμένα κάτω από τον κατάλογο /etc/bind, οπότε ας μεταβούμε σ’ αυτόν:

~$ cd /etc/bind

Το βασικό αρχείο ρυθμίσεων είναι το named.conf (“named” είναι το εναλλακτικό όνομα του BIND), το οποίο ως έχει δεν κάνει τίποτε άλλο από το να διαβάζει τα περιεχόμενα των αρχείων named.conf.default-zones, named.conf.local και named.conf.options. Στο παρόν άρθρο –και για τα είδη των name servers που μας ενδιαφέρουν– θα μας απασχολήσει μόνο το named.conf.options.

Recursive name server
Όπως προαναφέραμε το BIND είναι εξαιρετικά ευέλικτο κι αμέσως τώρα θα του πούμε να συμπεριφέρεται ως caching name server, με δυνατότητες recursion. Χωρίς άλλες περιστροφές ανοίγουμε το αρχείο named.conf.options με έναν text editor, όπως, π.χ., είναι το nano:

/etc/bind$ sudo nano named.conf.options

Ιδού πώς δείχνει το αρχείο χωρίς τα σχόλια:

options {
    directory "/var/cache/bind";
    dnssec-validation auto;
    auth-nxdomain no;
    listen-on-v6 { any; };
};

Πρώτη μας δουλειά είναι να ορίσουμε ένα ACL (Access Control List), δηλαδή μια λίστα, με τους πελάτες που επιτρέπεται να μιλούν με τον name server. Ο ορισμός αυτής της λίστας γίνεται στην αρχή του αρχείου named.conf.options κι έξω από το μπλοκ ονόματι “options”. Τη λίστα την ονομάζουμε όπως θέλουμε:

acl goodfellas {
    10.0.0.0/24;
    localhost;	
};

Επηρεασμένοι από την ταινία GoodFellas που είχαμε θυμηθεί προσφάτως, ονομάσαμε τη λίστα μας goodfellas (όλα πεζά) και φροντίσαμε ώστε να περιλαμβάνει:

  • όλα τα μηχανήματα με IP της μορφής 10.0.0.*, αφού αυτές είναι οι διευθύνσεις IP που παίρνουν οι clients του τοπικού μας δικτύου
  • το τοπικό μηχάνημα (localhost), ώστε οι εφαρμογές του συστήματος να είναι σε θέση να χρησιμοποιούν κι αυτές τον name server

Σημειώστε ότι στη θέση των “10.0.0.0/24” και “127.0.0.1” κάλλιστα μπορούμε να βάλουμε το “localnets”, το οποίο πάντα σημαίνει “το τοπικό μηχάνημα μαζί με τα δίκτυα κάθε network interface”. Πιο συγκεκριμένα: Το μηχάνημά μας με το BIND διαθέτει μία μόνο κάρτα δικτύου Ethernet (ένα network interface), έχει διεύθυνση IP την 10.0.0.5 και μάσκα δικτύου την 255.255.255.0, επομένως για την περίπτωση του παραδείγματός μας το localnet σημαίνει “127.0.0.1 και 10.0.0.0/24” (Περισσότερα για τις διευθύνσεις IP, τις μάσκες δικτύου, τη μορφή CIDR κ.λπ., διαβάστε εδώ). Το goodfellas, λοιπόν, μπορεί να οριστεί συντομότερα κι έτσι:

acl goodfellas {
    localnets;	
};

Να πώς μοιάζει το named.conf.options έως αυτή τη στιγμή:

acl goodfellas {
    localnets;	
};

options {
    directory "/var/cache/bind";
    dnssec-validation auto;
    auth-nxdomain no;
    listen-on-v6 { any; };
};

Ο ορισμός του ACL δεν είναι αρκετός, ώστε τα queries από τα μηχανήματα που περιγράφει να γίνονται αποδεκτά. Απαιτείται επιπρόσθετα η οδηγία “allow-query { goodfellas; };”, εντός του μπλοκ “options”. Χρειάζεται εξάλλου να ζητήσουμε την ενεργοποίηση του recursion με την οδηγία “recursion yes;” — πάντα μέσα στο μπλοκ “options”. Δείτε ξανά το named.conf.options, το οποίο πλέον περιλαμβάνει και τις δύο προαναφερθείσες οδηγίες:

acl goodfellas {
    localnets;	
};

options {
    directory "/var/cache/bind";

    recursion yes;
    allow-query { goodfellas; };

    dnssec-validation auto;
    auth-nxdomain no;
    listen-on-v6 { any; };
};

Δεν χρειάζεται καμία άλλη ρύθμιση ώστε το BIND να λειτουργεί ως caching name server με ικανότητες recursion. Αν δεν θέλετε να συμπεριφέρεται ως forwarding name server, τότε προσπεράστε την επόμενη ενότητα και συνεχίστε με τη μεθεπόμενη. Διαφορετικά συνεχίστε το διάβασμα κανονικά.

Forwarding name server
Ξεκινάμε από το τροποποιημένο named.conf.options, ακριβώς όπως το αφήσαμε στην προηγούμενη ενότητα. Προσοχή: Επειδή φτιάχνουμε έναν forwarding name server, δεν σημαίνει ότι τώρα θ’ αλλάξουμε την οδηγία “recursion yes;” σε “recursion no;”. Αντιθέτως θα την αφήσουμε ως έχει, αφού ο name server συνεχίζει ν’ απαντά για domains που δεν είναι στην ευθύνη του κι επομένως για τους πελάτες συνεχίζει να παρέχει recursive υπηρεσίες. Σίγουρα φορτώνει το μεγαλύτερο μέρος της δουλειάς σε άλλους name servers, αλλά αυτό δεν έχει σημασία και υπό μία έννοια είναι recursive. Και μιας κι αναφερθήκαμε σ’ αυτούς τους άλλους servers, ας ορίσουμε μια λίστα με caching name servers στους οποίους θα προωθούνται τα αιτήματα των πελατών. Ο ορισμός λαμβάνει χώρα εντός του μπλοκ “options”:

forwarders {
    8.8.8.8;
    8.8.4.4;
};

Η λίστα υλοποιήθηκε με το μπλοκ “forwarders” και περιλαμβάνει τους δύο δημόσιους name servers που απλόχερα παρέχει η Google. Θα μπορούσαμε να χρησιμοποιήσουμε άλλους, όπως, π.χ., εκείνους της OpenDNS (208.67.222.222 και 208.67.220.220) ή ακόμη και συνδυασμούς. Χρωστάμε και την οδηγία “forward only;”, ώστε ο name server μας να προωθεί πάντα τα αιτήματα των πελατών και να μην επιχειρεί να τα εξυπηρετεί ο ίδιος (εκτός κι αν έχει τις απαντήσεις στην cache του, δηλαδή). Δείτε παρακάτω όλα τα περιεχόμενα του αρχείου named.conf.options για τον forwarding name server μας:

acl goodfellas {
    localnets;
};

options {
    directory "/var/cache/bind";

    recursion yes;
    allow-query { goodfellas; };

    forwarders {
        8.8.8.8;
        8.8.4.4;
    };
    forward only;

    dnssec-enable yes;
    dnssec-validation yes;

    auth-nxdomain no;
    listen-on-v6 { any; };
};

Οι παρατηρητικοί θα διαπιστώσατε ότι:

  • το “dnssec-validation auto;” έχει γίνει ” dnssec-validation yes;”
  • από πάνω του έχει προστεθεί η οδηγία “dnssec-enable yes;”

Χωρίς αυτές τις δύο αλλαγές, οι ρυθμίσεις DNSSEC των name servers στους οποίους προωθούμε τα αιτήματα θα μολύνουν τα log files του server μας με μηνύματα λάθους.

Έλεγχος ορθής λειτουργίας κι ενεργοποίηση
Αποθηκεύουμε τις αλλαγές στο αρχείο named.conf.options (στο nano, π.χ., δίνουμε [CTRL+O], [Enter]) κι αμέσως εγκαταλείπουμε τον editor (π.χ., με [CTRL+X] στο nano). Έχοντας δικαιώματα root ανοίγουμε στα γρήγορα το αρχείο ρυθμίσεων του BIND daemon, το /etc/default/bind9:

/etc/bind$ sudo nano /etc/default/bind9

Φροντίζουμε ώστε η γραμμή

OPTIONS="-u bind"

να γίνει

OPTIONS="-u bind -4"

Αποθηκεύουμε την αλλαγή κι εγκαταλείπουμε τον editor. Μόλις προσθέσαμε αυτό το “-4” και, ως αποτέλεσμα, το BIND σε λίγο θα δέχεται μόνο αιτήματα για resolving διευθύνσεων IPv4. Στο Ubuntu, εξάλλου, η υπηρεσία ενεργοποιείται αμέσως μετά την εγκατάσταση του αντίστοιχου πακέτου (bind9). Αυτή τη στιγμή βέβαια δεν έχουν ληφθεί υπόψη οι τροποποιήσεις στο /etc/bind/named.conf.options και, πριν επανεκκινήσουμε το BIND ώστε να τις διαβάσει, είναι καλή ιδέα να ελέγξουμε το named.conf.options για συντακτικά λάθη. Προς τούτο θα καταφύγουμε στο εργαλείο named-checkconf, το οποίο βρισκόταν στο πακέτο bind9utils που εγκαταστήσαμε νωρίτερα:

/etc/bind$ sudo named-checkconf

Αν δεν υπάρχει λάθος, τότε το παραπάνω δεν θα επιστρέψει κάτι. Ας επανεκκινήσουμε λοιπόν το BIND:

/etc/bind$ sudo service bind9 restart
* Stopping domain name service... bind9
waiting for pid 1341 to die                 [ OK ]
* Starting domain name service... bind9     [ OK ] 
/etc/bind$

Πολύ ωραία. Ένας τρόπος για να βεβαιωθούμε ότι το BIND αφουγκράζεται για αιτήματα πελατών, είναι με τη βοήθεια του netstat:

/etc/bind$ sudo netstat -antp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 10.0.0.5:53             0.0.0.0:*               LISTEN      1622/named      
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      1622/named      
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1312/sshd       
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      1622/named      
tcp        0     36 10.0.0.5:22             10.0.0.104:60922        ESTABLISHED 1483/sshd: admin [p
tcp6       0      0 :::22                   :::*                    LISTEN      1312/sshd       
/etc/bind$

Παρατηρούμε ότι το BIND δέχεται αιτήματα από το port 53/TCP και, όπως βλέπετε, στο σύστημά μας τα αναμένει από το network interface με IP το 10.0.0.5, αλλά κι από το loopback interface με IP το 127.0.0.1.

Δοκιμές και σύγκριση επιδόσεων
Τις πρώτες μας δοκιμές μπορούμε να τις κάνουμε από μια κονσόλα του ίδιου του Ubuntu Server με τη βοήθεια του εργαλείου dig, το οποίο παρέχεται από το πακέτο dnsutils που είναι ήδη εγκατεστημένο. Ας ζητήσουμε από τον τοπικό name server το IP του colder.xyz:

~$ dig @127.0.0.1 colder.xyz

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> colder.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12027
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;colder.xyz.			IN	A

;; ANSWER SECTION:
colder.xyz.		1799	IN	A	46.101.173.140

;; Query time: 290 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Sep 27 09:34:07 EEST 2015
;; MSG SIZE  rcvd: 55

Προκειμένου να μην ερωτηθεί ο name server που ήδη γνωρίζει το μηχάνημα αλλά ο τοπικός, στο dig δώσαμε την οδηγία “@127.0.0.1”. Το BIND δεν είχε το IP του colder.xyz στην cache του, το αναζήτησε, το βρήκε (είναι το 46.101.173.140), το αποθήκευσε στην cache του και το επέστρεψε στον πελάτη (που σ’ αυτή την περίπτωση είναι το dig). Η διαδικασία της αναζήτησης διήρκησε 290 χιλιοστά του δευτερολέπτου (290 msec, βλ. γραμμή με το Query time). Ας ρωτήσουμε ξανά το BIND, πάλι για το colder.xyz:

~$ dig @127.0.0.1 colder.xyz

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @127.0.0.1 colder.xyz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21003
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;colder.xyz.			IN	A

;; ANSWER SECTION:
colder.xyz.		1246	IN	A	46.101.173.140

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Sep 27 09:43:20 EEST 2015
;; MSG SIZE  rcvd: 55 

Αυτή τη φορά το BIND είχε τη ζητούμενη πληροφορία στην cache του, οπότε το ερώτημα εξυπηρετήθηκε σε μηδενικό, πρακτικά, χρόνο! (Query time: 0 msec) Τώρα, για να εκτιμήσουμε πόσο μεγάλη βελτίωση στις επιδόσεις προσφέρει ένας τοπικός name server, ας απευθύνουμε το ίδιο ερώτημα διαδοχικά σε έναν εξωτερικό, όπως, π.χ., είναι ο 8.8.8.8 της Google. Θα καταφύγουμε και πάλι στο dig αλλά για οικονομία χώρου θα φιλτράρουμε την έξοδό του με το grep, ώστε να βλέπουμε μόνο τη γραμμή με το “Query time”:

~$ dig @8.8.8.8 colder.xyz | grep "Query time"
;; Query time: 301 msec
~$ dig @8.8.8.8 colder.xyz | grep "Query time"
;; Query time: 85 msec
~$ dig @8.8.8.8 colder.xyz | grep "Query time"
;; Query time: 124 msec
~$ dig @8.8.8.8 colder.xyz | grep "Query time"
;; Query time: 116 msec
~$ dig @8.8.8.8 colder.xyz | grep "Query time"
;; Query time: 73 msec
~$

Αμέσως μετά το πρώτο ερώτημα, το οποίο απαντήθηκε σε 301 msec, ο name server της Google αποθηκεύει στην cache του το IP του colder.xyz και στα επόμενα ερωτήματα απαντά γρηγορότερα (85 msec, 124 msec, 116 msec, 73 msec κ.ο.κ.) Παρά το γεγονός ότι πρόκειται για πανίσχυρο μηχάνημα, λόγω της απόστασής του από το δίκτυό μας είναι αδύνατον να συναγωνιστεί τον τοπικό μας name server!

Δοκιμή του name server μας από μηχάνημα του τοπικού δικτύου το οποίο έχει ενημερωθεί για την παρουσία του και τον χρησιμοποιεί.

Τον νέο μας name server καλό είναι να μην τον δοκιμάζουμε μόνο τοπικά, αλλά κι από κάποιο άλλο μηχάνημα του τοπικού δικτύου. Στο screenshot φαίνεται μέρος των ελέγχων που κάναμε στο πλαίσιο της προετοιμασίας του παρόντος άρθρου. Ο name server βρισκόταν στη διεύθυνση 192.168.201.133, ενώ ο υπολογιστής από τον οποίο εργαζόμασταν είχε ήδη ενημερωθεί για την παρουσία του. Παρατηρήστε τη διαφορά στους χρόνους απόκρισης μεταξύ δύο διαδοχικών ερωτημάτων για το ίδιο domain: Την πρώτη φορά η απάντηση ήλθε σε 150 msec, ενώ τη δεύτερη 150 φορές γρηγορότερα.

Η συνέχεια
Στο σημείο αυτό ο name server μας πρέπει να λειτουργεί σωστά και να ‘ναι πανέτοιμος για δράση. Διαβάστε στη συνέχεια για τους διάφορους τρόπους που τα μηχανήματα του τοπικού μας δικτύου είναι δυνατόν να εξυπηρετούνται από το BIND του Ubuntu Server.

15 Responses to “Πώς δουλεύουν τα δίκτυα: Ο δικός μας caching name server”

  1. sip03ds | 11/10/2015 at 09:56

    Καλησπέρα,

    Πολύ καλά, σημαντικά και πολύ κατατοπιστικά τα άρθρα για DNS.
    Καλό είναι να συμπεριληφθεί και το configuration για reverse zones.

    Επιπλέον μου δημιουργήθηκε μια απορία:
    – Έστω ότι έχω ένα domain που έχω 2 subnets
    10.0.0.0/24
    192.168.168.0/24

    – Θέλω 1 recursive dns για το domain
    Πως είναι configuration των zones σε αυτή την περίπτωση;

    ευχαριστώ και keep up the good work!

    • subZraw | 11/10/2015 at 11:28

      Καλημέρα Δημήτρη,

      Αν κατάλαβα καλά, αυτό που χρειάζεσαι είναι ένα διαφορετικό ACL:

      acl goodfellas {
      	10.0.0.0/24;
      	192.168.168.0/24;
      	localhost;  
      };
      

      Αν δεν κατάλαβα καλά, απλά διευκρίνισέ μου :)

  2. hlias | 11/10/2015 at 11:54

    Καλημερα σας,
    Θελω να σας ερωτησω το εξης:Εχω εγκαταστηση τον squid ως cashing proxy server(ubuntu 15.04) γινεται να ρυθμιστη και ως cashing dns server;
    ΔΗΛΑΔΗ ΝΑ ΑΠΟΘΗΚΕΥΟΝΤΑΙ ΣΕ ΚΑΠΟΙΟ ΑΡΧΕΙΟ ΟΙ ΑΝΤΙΣΤΟΙΧΙΣΕΙΣ domain name @Ιp και αρα ταχυτατα να παιρνει απαντηση;

    • subZraw | 11/10/2015 at 12:33

      Καλησπέρα,

      Το squid πράγματι χρησιμοποιεί DNS servers για τις δικές του ανάγκες, δεν λειτουργεί όμως ως name server για τους πελάτες του: δεν υπάρχει λόγος να κάνει κάτι τέτοιο.

      Αν λοιπόν χρειάζεσαι ή απλά επιθυμείς caching name server κοντά στους clients του δικτύου σου, τότε θα πρέπει να εγκαταστήσεις και να ρυθμίσεις έναν.

  3. hlias | 11/10/2015 at 14:21

    θα μπορουσα να εγκαταστησω και ρυθμισω εναν caching name server στο pc μου αρα να εχω γρηγοροτερο σερφαρισμα;και αν υπαρχει ρυθμηση να εχουν προσβαση και οι αλλοι client του lan μου; οσο φυσικα εναι το pc μου anoixto.
    ΕΥΧΑΡΙΣΤΩ ΓΙΑ ΤΟ ΧΡΟΝΟ ΣΑΣ

  4. sip03ds | 12/10/2015 at 10:50

    Καλημέρα,
    περίπου, είναι προαπαιτούμενο το:
    acl goodfellas {
    10.0.0.0/24;
    192.168.1.0/24;
    localhost;
    };
    για να δέχεται queries o DNS και από τα 2 subnet.
    Έστω ότι έχω τα παρακάτω μηχανηματα:
    router με 192.168.1.1 και Internet IP από ISP
    L3 switch με 192.168.1.2 και 10.0.0.1
    Server1 με 192.168.1.3 και 10.0.0.2 (πες ότι είναι web server)
    Server2 με 192.168.1.4 (mySQL)
    Server3 με 192.168.1.5 (θα τον setarω σαν DNS bind)
    (αν βάλεις και firewall μπροστά από το L3 έχεις κλασσικό single DMZ μπροστά από τοπικό δίκτυο – αλλά άστο έξω προς το παρόν)
    Έστω ότι μου ανήκει το domain mitsos.net. Θέλω να configurάρω τον bind ούτως ώστε:
    από το internet να μπορώ να βλέπω:
    –www.mitsos.net ==> Server1
    –router.mitsos.net ==> router
    από το lan να μπορώ να βλέπω:
    –www.mitsos.net ==> Server1
    –router.mitos.net ==> router
    –l3.mitsos.net ==> L3 switch
    –dns.mitsos.net ==> DNS server
    –mysql.mitsos.net ==> mysql server
    Ερωτήσεις:
    1) Τα zone files μου πώς πρέπει να είναι; (Η υλοποίηση γίνεται dns views αν δεν κάνω λάθος)
    2) O DNS server πρέπει να κάτσει κ αυτός στην DMZ (correction);

    • subZraw | 15/10/2015 at 16:25

      Καλησπέρα,

      Οι απαντήσεις στις ερωτήσεις σου θα μπορούσαν να αποτελούν το θέμα ολόκληρου άρθρου — και δεν αποκλείω να το αναπτύξουμε. Προς το παρόν, το μόνο που θα ήθελα να πω είναι ότι αν χρειάζεσαι name server στο Internet, ο οποίος θα είναι προσβάσιμος από παντού, τότε θα πρέπει να τον εγκαταστήσεις και ρυθμίσεις σε κάποιο VPS κι όχι στο σπίτι (κι ας είναι στο DMZ).

  5. hlias | 14/10/2015 at 20:42

    Καλησπερα σας.Θελω να ρωτησω το εξης,οταν χρησιμοποιω την dig @127.0.0.1 http://www…….. για να μου δωσει τον χρονο προσβασης στον dns server 127.0.0.1 την πρωτη φορα ειναι πχ 80msec την δευτερη φορα ειναι 0msec(γιατι προφανως εχει αποθηκευσει το ερωτημα στην cash) ωραια,μετα απο λιγο(1min περιπου)η εντολη μου δινει ξανα μεγαλο χρονο (70msec),που σημαινει οτι δεν διατηρειται to apotelesma για πολυ χρονο στην cash ,μπορω να αλλαξω το ttl;πως;Υπαρχει καποιο αρχειο με την cash
    στο bind;Apo poio arxeio pairnei taxytata h dig thn plhroforia(την δευτερη φορα).Συνχωρεστεμε για την φλυαρια αλλα προσπαθω να καταλαβω.

    • subZraw | 15/10/2015 at 16:19

      Πολύ καλές οι ερωτήσεις σου, Ηλία!
      Το Bind δεν διατηρεί την cache σε κάποιο αρχείο στο δίσκο, αλλά στη μνήμη RAM του υπολογιστή. Για να δεις τα περιεχόμενα της cache στο Ubuntu Server σου πληκτρολόγησε

      $ sudo rndc dumpdb
      

      και μετά δες το αρχείο named_dump.db, στον κατάλογο /var/cache/bind.

      Τέλος, το πόσο κρατάει στην cache το Bind τις πληροφορίες για τα zones δεν εξαρτάται από το ίδιο, αλλά από το TTL του εκάστοτε name server.

  6. hlias | 20/10/2015 at 14:29

    Eυχαριστω για τις πολυ διδακτικες απαντησεις σου.
    Καπου αναφερεις οτι Μερικοί clients, όπως οι web browsers, δεν βιάζονται διότι διατηρούν μια εσωτερική DNS cache,πρωτα κοιτάει την dns cash του,οπου αποθηκευει προσωρινά τα ερωτηματα(αρα ειναι γρηγοροτερος),που ειναι η dns cash αυτη;που βρισκεται;(η ιδια λογικη με την λειτουργια cashing καποιων φιλλομετρητων που αποθηκευουν περιεχομενα ιστοσελιδων;….)
    Επισης θα μπορουσαμε να αντιγραψουμε καποια ζευγη domain-ip στο αρχειο hosts μιας και ειναι το πρωτο που κοιταει ο cliet;και αν εχει αλλαξει κατι να παραπεμπεται σε resolver;
    ΕΥΧΑΡΙΣΡΩ

    • subZraw | 21/10/2015 at 21:13

      Το πού ακριβώς διατηρούν οι browsers την DNS cache τους δεν το γνωρίζω. Θα στοιχημάτιζα για τη RAM, αλλά δεν υπάρχει λόγος για στοιχήματα. Θα έλεγα λοιπόν να το ψάξεις και να μου πεις κι εμένα :)

      Τώρα, στο αρχείο hosts κάλλιστα μπορείς να έχεις όσες αντιστοιχήσεις domain < --> IP θέλεις. Αν όμως έχει αλλάξει κάτι (το IP), τότε μην περιμένεις να ερωτηθεί αυτόματα κάποιος name server.

  7. sancroth | 11/01/2018 at 16:40

    Να κάνω και εγώ την απορία μου.
    Θα ήθελα ο registar μου, να κάνει χρήση των δικών μου name servers αντί των δικών του.

    Έβαλλα τον dns μου να ακούει Public, έφτιαξα τα zone files με τη βοήθεια του παρακάτω link Και των άρθρων σας :
    https://www.atlantic.net/community/howto/authoritative-dns-server-installation/
    Δεν κάνω post τα configs γιατί φοβάμαι το κακό κόσμο.

    Με τη χρήση της dig επστρέφονται τα σωστά records όπως τα έχω θέσει.
    Όσον αναφορά του θέμα του registar έθεσα 3 Α name records να ns1.domain , ns2.domain , ns3.domain να δείχνουν στο server και άλλαξα τους nameservers στους αντίστοιχους 3.

    Το παραπάνω οφείλει να δουλέψει ή τσάμπα θεωρώ πως δεν παίζει ακόμα λόγω το propagation delay? :P

    • sancroth | 11/01/2018 at 17:58

      Να προσθέσω ότι η dig δουλεύε κομπλέ μέσα απο τον ίδιο server αλλά από εξωτερικά κάνοντας χρήση της dig με την ip του ns1 τρώω timeout ενώ με 8.8.4.4 πέρνω απάντηση SAO(δεν υπάρχει εν ολίγης αυτό που ψάχνεις) από τον registar. :/

      • sancroth | 12/01/2018 at 12:00

        Λοιπόν δεν ήταν θέμα propagation αλλά λάθος record.
        Για να επιτύχεις το παραπάνω αρκεί να κλείσεις στον registar το domain και να δηλώσεις πως οι nameservers για το συγκεκριμένος είναι αυτοί που θα στήσεις.
        Μετά αρκεί να φτιάξεις τα κατάλληλα forward records(δεν είμαι σίγουρος για τα reverse ακόμα) και να κλείσεις recursion και caching με μονάχα allow-query{“any”};
        αφού είσαι public πλεον.
        Για το πως θα το οχηρώσεις καλά δεν είμαι σίγουρος ακόμα μιας και dns και mail servers είναι τα πιο συχνά abused.
        Χίλια ευχαριστώ για την όλη επεξήγηση και καθοδήγηση των άρθρων σας, ήταν τεράστια βοήθεια. money well spent και lifetime access Secured :d

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

Αρχείο δημοσιεύσεων