DNS Server- Δεν παίζει η reverse zone

[macabre_sunsets]

Έστω ότι έχουμε την IP 1.2.3.4.

 

Έχω προσθέσει στο named.conf το ακόλουθο:

>zone "3.2.1.in-addr.arpa" {
       type master;
       file "3.2.1.in-addr.arpa";
       allow-transfer {
               common-allow-transfer;
       };
};

acl common-allow-transfer {
       none;
};

Το αντίστοιχο αρχείο "3.2.1.in-addr.arpa" περιέχει τα εξής:

>$TTL    86400

@       IN      SOA     plesk.domain.gr. admin.domain.gr. (
                       1330404249      ; Serial
                       10800   ; Refresh
                       3600    ; Retry
                       604800  ; Expire
                       10800 ) ; Minimum

                IN NS   plesk.domain.gr.
4               IN PTR  plesk.domain.gr.

Στο "/var/log/messages" βλέπω την ακόλουθη γραμμή:

>Feb 28 06:44:09 plesk named[30863]: zone 3.2.1.in-addr.arpa/IN: loaded serial 1330404249

Βλέπετε κάτι λάθος μέχρι εδώ; Να σημειώσω πως τα αρχεία έχουν φτιαχτεί αυτόματα από το Plesk, με ό,τι αυτό συνεπάγεται.

 

Δοκιμάζοντας να κάνω nslookup, χρησιμοποιώντας τον δικό μου DNS Server, παίρνω το ακόλουθο:

>[root@plesk var]# nslookup 1.2.3.4 1.2.3.4
;; Truncated, retrying in TCP mode.
Server:         1.2.3.4
Address:        1.2.3.4#53

4.3.2.1.in-addr.arpa     name = plesk.domain.gr.

Δοκιμάζοντας να κάνω nslookup, χρησιμοποιώντας τον DNS Server της Google, παίρνω το ακόλουθο:

>[root@plesk var]# nslookup 1.2.3.4 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

** server can't find 4.3.2.1.in-addr.arpa.: NXDOMAIN

Να σημειώσω πως η forward zone παίζει κανονικά:

>[root@plesk var]# nslookup domain.gr 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   domain.gr
Address: 1.2.3.4

Υπάρχει κάποια ιδέα για το τι μπορεί να φταίει; Τι άλλες δοκιμές μπορώ να κάνω ώστε να διαπιστώσω πιο είναι το πρόβλημα;

 

Λειτουργικό: CentOS release 5.5

[NullScan]

Στο πολύ γρήγορο, γιά δοκίμασε αυτό για 3.2.1-in-addr.arpa

>$TTL    86400

@       IN      SOA     plesk.domain.gr. admin.domain.gr. (
                       1330404249      ; Serial
                       10800   ; Refresh
                       3600    ; Retry
                       604800  ; Expire
                       10800 ) ; Minimum

                IN NS   plesk.domain.gr.
1               IN PTR  www.domain.gr. ;εδώ το qualified name και μήν ξεχνάς τις τελείες στο τέλος του domain name

[macabre_sunsets]

Δυστυχώς δεν έγινε τίποτα.

 

Δεν ξέρω αν έχει σημασία, αλλά υπάρχουν αρκετές εγγραφές στο αρχείο της reverse zone, οι οποίες αντιστοιχούν στην ίδια IP. Για παράδειγμα:

>4               IN PTR  plesk.domain.gr.
4               IN PTR  domain2.gr.
4               IN PTR  domain3.gr.
4               IN PTR  domain4.gr.
4               IN PTR  domain5.gr.

 

Επίσης υπάρχουν εγγραφές που αντιστοιχούν σε άλλη IP. Για παράδειγμα:

>6               IN PTR  web.domain.gr.
6               IN PTR  web.domain2.gr.
6               IN PTR  web.domain3.gr.
6               IN PTR  web.domain4.gr.
6               IN PTR  web.domain5.gr.

Εφόσον δουλεύει η forward zone, είναι ασφαλές να υποθέσω πως δεν δημιουργείται πρόβλημα από κάποιο firewall; Ο Server έχει public static IP, οπότε δεν χρειάζεται κάποιο Port forward (υποθέτω).

 

Επίσης, υπάρχει περίπτωση να με εμποδίζει ο πάροχος του Server από το να δημιουργήσω reverse DNS (για παράδειγμα να μπορεί να δημιουργήσει μόνο αυτός); Ο Server είναι ένας dedicated και μου έχουν δώσει 5 Static IP.

[imitheos]

Έστω ότι έχουμε την IP 1.2.3.4.

 

Δοκιμάζοντας να κάνω nslookup, χρησιμοποιώντας τον δικό μου DNS Server, παίρνω το ακόλουθο:

>[root@plesk var]# nslookup 1.2.3.4 1.2.3.4
;; Truncated, retrying in TCP mode.
Server:         1.2.3.4
Address:        1.2.3.4#53

4.3.2.1.in-addr.arpa     name = plesk.domain.gr.

 

Δοκιμάζοντας να κάνω nslookup, χρησιμοποιώντας τον DNS Server της Google, παίρνω το ακόλουθο:

>[root@plesk var]# nslookup 1.2.3.4 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

** server can't find 4.3.2.1.in-addr.arpa.: NXDOMAIN

Να σημειώσω πως η forward zone παίζει κανονικά:

>[root@plesk var]# nslookup domain.gr 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   domain.gr
Address: 1.2.3.4

Υπάρχει κάποια ιδέα για το τι μπορεί να φταίει; Τι άλλες δοκιμές μπορώ να κάνω ώστε να διαπιστώσω πιο είναι το πρόβλημα;

 

Λειτουργικό: CentOS release 5.5

Επίσης, υπάρχει περίπτωση να με εμποδίζει ο πάροχος του Server από το να δημιουργήσω reverse DNS (για παράδειγμα να μπορεί να δημιουργήσει μόνο αυτός); Ο Server είναι ένας dedicated και μου έχουν δώσει 5 Static IP.

 

Όταν χρησιμοποιείς τον δικό σου nameserver για το query παίζει μια και έχεις ρυθμισμένη την ζώνη. Όταν όμως χρησιμοποιείς κάποιον εξωτερικό nameserver όπως αυτόν του google, αυτός μιλάει με το δικό σου ή μήπως όχι ?

 

Για forward lookup, ας υποθέσουμε ότι θέλουμε να βρούμε το www.insomnia.gr. Μπορούμε να χρησιμοποιήσουμε την μη-recursive λειτουργία του nslookup για να δούμε τι παίζει.

 

>
% nslookup
> set query = ns
> set norec
> www.insomnia.gr
Authoritative answers can be found from:
. nameserver = A.ROOT-SERVERS.NET
> server 198.41.0.4
> www.insomnia.gr
Authoritative answers can be found from:
gr nameserver = estia.ics.forth.gr (έχω forthnet)
estia.ics.forth.gr internet address = 139.91.191.3
> server 139.91.191.3
> www.insomnia.gr
Authoritative answers can be found from:
insomnia.gr	nameserver = ns1.insomnia.gr.
ns1.insomnia.gr	internet address = 62.1.42.20
> server 62.1.42.20
> set query=a
> www.insomnia.gr
www.insomnia.gr	canonical name = insomnia.gr.
Name:	insomnia.gr
Address: 62.1.42.20
> exit

 

Όπως βλέπεις, ο υπεύθυνος διακομιστής κάθε βήματος ξέρει μόνο την διεύθυνση του διακομιστή που είναι υπεύθυνος για το επόμενο βήμα. Ο root server παραπέμπει στον υπεύθυνο για το .gr, εκείνος στον υπεύθυνο για το insomnia.gr. Αυτή τη διαδικασία φυσικά δεν την κάνεις εσύ χειροκίνητα αλλά γίνεται αυτόματα (τις περισσότερες φορές δεν χρειάζεται κιόλας να γίνει γιατί το αποτέλεσμα υπάρχει στο cache). Όταν εσύ έκανες register το domain.gr μπήκε μια καταχώρηση που λέει ότι υπεύθυνος nameserver για αυτό είναι η τάδε IP. Αυτό είναι το εύκολο κομμάτι μια και το domain ανήκει σε σένα οπότε μπορείς να δηλώσεις όποιο διακομιστή θέλεις ή να κάνεις resolve το domain.gr σε οποιαδήποτε IP θέλεις. Για παράδειγμα, μερικοί κάνουν redirect το domain.gr σε dyndns στο σπίτι τους.

 

Παρόμοια βάση υπάρχει και για τις reverse συνήθως όμως ανήκει στον πάροχο σου οπότε δεν έχεις άμεση πρόσβαση. Όταν εσύ (ή ο server του google) κάνει reverse lookup πέφτει πάνω στον nameserver που είναι υπεύθυνος για τις 5 στατικές IP σου. Πολύ πιθανώς, αυτός να μην είναι ο δικός σου server οπότε δεν βλέπει καν την zone που έφτιαξες.

 

Ας δούμε πάλι ως παράδειγμα το insomnia.gr

>
% host 62.1.42.20
Host 20.42.1.62.in-addr.arpa. not found: 3(NXDOMAIN)

 

Χμ γιατί δεν βγάζει insomnia.gr ? Ας δούμε ποιος είναι υπεύθυνος διακομιστής.

 

>
% host -t ns 42.1.62.in-addr.arpa
42.1.62.in-addr.arpa name server teiresias.forthnet.gr

 

Όπως βλέπεις, ενώ υπεύθυνος για το forward είναι η ίδια η ip και ο διαχειριστής του insomnia μπορείς να δηλώσει άμεσα ό,τι όνομα θέλει (πχ mitsos.insomnia.gr), υπεύθυνος διακομιστής για reverse lookup στο 62.1.42 υποδίκτυο είναι ο teiresias.forthnet.gr οπότε για το reverse πρέπει να μεριμνήσει ο διαχειριστής της forthnet να βάλει μια καταχώρηση εκεί που να λέει 20 IN PTR insomnia.gr. για να παίζει σωστά. Μια συνήθης πρακτική είναι όταν έχεις μία στατική IP να πρέπει να μιλάς με τον πάροχο για να σου αλλάζει το reverse. Από 8 στατικές και πάνω μερικοί πάροχοι εκχωρούν σε σένα αυτό το κομμάτι της reverse ζώνης οπότε μπορείς να παίξεις απευθείας μπάλα εσύ.

 

Για να δεις στη δική σου περίπτωση ποιος είναι ο υπεύθυνος διακομιστής, μπορείς να τρέξεις την εντολή που έτρεξα παραπάνω αλλά με όρισμα 3.2.1.in-addr.arpa. Λογικά δεν θα πρέπει να δεις τον server σου αλλά κάποιον διακομιστή του παρόχου.

[macabre_sunsets]

Όντως, δεν είναι ο δικός μου DNS Server υπεύθυνος για την reverse ζώνη.

 

>[root@plesk ~]# host -t ns 3.2.1.in-addr.arpa
3.2.1.in-addr.arpa name server ns2.host.com.
3.2.1.in-addr.arpa name server ns3.host.com.
3.2.1.in-addr.arpa name server ns1.host.com.

Οπότε άντε τώρα να βγει άκρη με την εταιρεία που μου παρέχει τις IP.

 

Ευχαριστώ πολύ για την βοήθεια και την αναλυτική εξήγηση.

[imitheos]

Όντως, δεν είναι ο δικός μου DNS Server υπεύθυνος για την reverse ζώνη.

 

>[root@plesk ~]# host -t ns 3.2.1.in-addr.arpa
3.2.1.in-addr.arpa name server ns2.host.com.
3.2.1.in-addr.arpa name server ns3.host.com.
3.2.1.in-addr.arpa name server ns1.host.com.

Οπότε άντε τώρα να βγει άκρη με την εταιρεία που μου παρέχει τις IP.

 

Ευχαριστώ πολύ για την βοήθεια και την αναλυτική εξήγηση.

 

Έτσι λοιπόν όταν κάνεις reverse lookup, επικοινωνείς με τον ns1.host.com και όχι με τον δικό σου για αυτό και δεν φαίνονται καθόλου τα ονόματα που δήλωσες. Στείλε mail στον κάτοχο των IP και πες του ότι θέλεις reverse lookup. Αν δεχτεί να σου εκχωρήσει τις διευθύνσεις, πολύ ωραία. Αν όχι, τότε θα πρέπει να τους πεις τι ονόματα θέλεις πχ web.domain.gr, foo.domain.gr, bar.domain.gr και να στα περάσει αυτός και για κάθε αλλαγή ή πρόσθεση νέου να του ξαναλές να το κάνει.

 

ΑΝ δεχτεί να σου εκχωρήσει τις διευθύνσεις, ίσως χρειαστείς να αλλάξεις τη ζώνη σου. Αν υποθέσουμε ότι έχεις τις διευθύνσεις 1.2.3.1-6 (δηλαδή το δίκτυο 1.2.3.0/29) τότε ένας τρόπος να σου δώσει τις διευθύνσεις είναι να βάλει στην ζώνη του:

>
1 in ns τάδε_ns
2 in ns τάδε_ns
..
6 in ns τάδε_ns

Συνήθως όμως δημιουργείται μια ψευτοζώνη και οι διευθύνσεις γίνονται cname σε αυτήν, δηλαδή:

>
0/29 in ns τάδε_ns
1 in cname 1.0/29.3.2.1.in-addr.arpa
2 in cname 2.0/29
..
6 in cname 6.0/29

Έτσι η ζώνη για την οποία είσαι υπεύθυνος είναι η ψεύτικη ζώνη 0/29.3.2.1.in-addr.arpa (αντί για 0/29 θα μπορούσε επίσης να είναι 0-29 ή οτιδήποτε άλλο χαρακτηριστικό όνομα θέλει ο διαχειριστής). Θα σου πουν οδηγίες για το τι θα κάνεις αν δεχτούν φυσικά.

[macabre_sunsets]

Μίλησα με τον διαχειριστή και έβαλε αυτός τελικά τις εγγραφές. Ελπίζω να μην χρειαστούν αλλαγή σύντομα.

 

Ευχαριστώ πολύ για την βοήθεια.