# Chat > Ερωτήσεις >  AWMN Root DNS Servers

## ntrits

Είχα κάνει και παλιότερα μια σχετική ερωτηση αλλά δεν πηρα σαφή απάντηση.

Οι Root dns servers του awmn ποιοί είναι ή που μπορώ να τους βρώ?

----------


## trendy

Δοκίμασε:
10.32.48.3
10.17.119.130
10.19.143.12
10.19.143.13

----------


## spyros_28

Μην ξεχνας οτι θελει και proxy server.

----------


## ntrits

> Δοκίμασε:
> 10.32.48.3
> 10.17.119.130
> 10.19.143.12
> 10.19.143.13


To 10.19.143.13 μοιάζει για root αλλά δεν λειτουργεί σωστα. Τα άλλα είναι 2ου επιπέδου.

----------


## ntrits

> Μην ξεχνας οτι θελει και proxy server.


Ποιός θέλει proxy και γιατί?

----------


## Cha0s

10.19.143.12

Αυτός είναι ο root dns.

Εκεί τρέχει το wind.
Εκεί τρέχει και ο bind που 'συνεργάζεται' με το wind.

----------


## spyros_28

> Αρχική Δημοσίευση από spyros_28
> 
> Μην ξεχνας οτι θελει και proxy server.
> 
> 
> Ποιός θέλει proxy και γιατί?


Θες και proxy για το internet.Πως μπαινεις στο forum και διαβαζεις  ::   ::

----------


## Cha0s

Τι σχέση έχουν τα DNS με το internet και τους proxy;  ::   ::

----------


## spyros_28

Εφοσον θελει dns δεν θα εχει βαλει πιθανον και proxy server,λεω εγω τωρα........

----------


## Cha0s

> Εφοσον θελει dns δεν θα εχει βαλει πιθανον και proxy server,λεω εγω τωρα........


Κάπου τα έχεις μπλέξει.

Άλλο το DNS άλλο ο Proxy.

Το ένα δεν απαιτεί το άλλο για να παίξουν.

----------


## ntrits

Εφόσον ο 10.19.143.12 ειναι root, θα πρέπει να μπορώ να τον ρωτήσω ποιοι είναι οι name servers για κάποιο awmn domain και να μου πει.... π.χ. για το ithaca.awmn ή για το onikoseimai.awmn κλπ.

Τον ρωτάω αλλά δεν!!! δεν ξερει τίποτε... (με nslookup του λέω να μου δειξει τους ns για ithaca.awmn κ.λ.π) 
μήπως κάνα κάτι λάθος?

(Δεν θέλω internet ευτο που κοιτάω είναι ασχετο με προσβαση στο internet)

----------


## Cha0s

```
[[email protected] ~]# dig ithaca.awmn

; <<>> DiG 9.4.1 <<>> ithaca.awmn
;; global options:  printcmd
;; connection timed out; no servers could be reached
[[email protected] ~]# dig onikoseimai.awmn

; <<>> DiG 9.4.1 <<>> onikoseimai.awmn
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56190
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;onikoseimai.awmn.              IN      A

;; ANSWER SECTION:
onikoseimai.awmn.       3600    IN      A       10.2.31.254

;; AUTHORITY SECTION:
onikoseimai.awmn.       3600    IN      NS      ns.onikoseimai.awmn.

;; ADDITIONAL SECTION:
ns.onikoseimai.awmn.    3600    IN      A       10.2.31.254

;; Query time: 44 msec
;; SERVER: 10.26.35.69#53(10.26.35.69)
;; WHEN: Mon Jul  2 14:28:58 2007
;; MSG SIZE  rcvd: 83
```

Και δεν χρησιμοποιώ τον root DNS αλλά τον δικό μου που είναι slave στον root dns. (δεν έχει διαφορά νομίζω έτσι και αλλιώς μιας και κοπιάρει όλη την ζώνη τοπικά ο slave).

----------


## ntrits

Για το ithaca.awmn γιατί δεν σου βγάζει τίποτε αφού είναι δηλωμένο στο wind?
Επιτρεπει ο 10.19.143.12 να γίνει οποιοσδήποτε slave?

----------


## trendy

Οποιοσδήποτε dns κοπιάρει τη master zone του awmn μπορεί να σου απαντήσει. Μάλλον εσύ κάνεις κάτι λάθος και πιθανώς δεν έχεις δηλώσει σωστά τον master για το ithaca.awmn για αυτό και δε γυρίζει αποτέλεσμα.

----------


## trendy

> Για το ithaca.awmn γιατί δεν σου βγάζει τίποτε αφού είναι δηλωμένο στο wind?


Έχεις δηλώσει στους dns σου ότι θα hostάρουν το ithac και το reverse του;

----------


## ntrits

Μισό....
Εχω δηλώσει στο wind 2 name servers με τις IP τους από το δικό μου class C
Εχω δηλώσει επίσης μια dns ζωνη π.χ. ithaca.awmn.
Φαντάζομαι πως η καταχώρηση γίνεται στον 10.19...12
Επίσης φανταζομαι πωε αν ρωτήσω me nslookup τον 10.19..12 θα μου πει ποιος ειναι ο name server για το ithaca.awmn, άσχετα τι έχω κανει εγώ με τον server που έχει το ithaca.awmn

Λέω κάτι λάθος μέχρι εδώ?

----------


## trendy

Στους 2 dns servers σου έχεις κάνει δήλωση ποιες zones θα hostάρουν; Στο wind πάντα αυτό.
Διόρθωση, πας πάνω στις ζώνες και κάνεις κλικ πάνω τους.
Εκεί προσθέτεις τους nameservers που είναι υπεύθυνοι για τις ζώνες σου.

----------


## ntrits

Tο έχω κάνει.

Kαι για forward και για reverse

http://wind.awmn.net/?page=nodes&node=9486

----------


## NiKoSaEi

Κατι εχεις κανει λαθος με το reverse

----------


## ntrits

> Κατι εχεις κανει λαθος με το reverse


Βλέπεις κατι λάθος?

----------


## Acinonyx

O master DNS σου "παραχωρεί" το ithaca.awmn να το hostάρεις εσύ. Αν εσύ δε το hostάρεις ή το hostάρεις αλλά όχι σωστά, τότε το ithaca.awmn δεν θα κάνει resolve.

Ο master server σε γνωρίζει:



```
host ns0.ithaca-1.ns.awmn
;; Truncated, retrying in TCP mode.
ns0.ithaca-1.ns.awmn has address 10.2.164.1
```

Οι αιτήσεις κατευθύνονται στον server σου αλλά δεν υπάρχει response (τουλάχιστον σε μένα). Προφανώς δεν έχει σηκωθεί ο server.


```
dig ithaca.awmn

; <<>> DiG 9.3.4 <<>> ithaca.awmn
;; global options:  printcmd
;; connection timed out; no servers could be reached
```

O onikoseimai δίνει απάντηση στο *dig onikoseimai.awmn* γιατί ο server του λειτουργεί και έχει προσθέσει συγκεκριμένα A εγγραφή για το hostname αυτό. Αν δεν είχε βάλει αυτή την εγγραφή, το dig θα επέστρεφε ότι δεν υπάρχει (NXDOMAIN).

----------


## ntrits

Βασίλη αυτό που λες έψαχνα και δεν μου το έβγαζε.
Τώρα που το δοκίμασα πάλι μου απαντά.

Οπότε root servers είναι : 10.19.143.12 - 10.19.143.13

Ευχαριστώ όλους για την βοήθεια

----------


## dalex

....

----------


## ntrits

> Εγώ δεν κατάλαβα
> 
> πρέπει να είμαι slave σε όλη τη awmn ζώνη;
> 
> Γιατί με βάζει (μαζί με όλους) στα ns του awmn;
> 
> και μούρχονται όλα τα I πακέτα.
> 
> 
> ...


Παρεπιπτόντως δεν θέλω να γίνω slave σε όλη την awmn ζώνη.

Ο 10.2.164.1 ειναι mikrotik και δεν μπορεί να κρατήσει ζώνη ούτε reverse, μόνο Α records κρατάει.

Εκείνο που ήθελα, επειδή στήνω έναν αξιοπρεπή dns (bind) να ξέρω να δηλώσω τους root servers, για αυτό ρώτησα, άσχετα αν η κουβέντα πήγε αλλού λόγω διάφορων παρατηρήσεων που προέκυψαν. 

(στην περίπτωση αυτή ο dns είναι primary για τις ζώνες του αλλά για το υπόλοιπο awmn πρέπει να ξέρει που να ρωτήσει (root servers) για να μάθει ποιος κρατά την εκάστοτε dns ζώνη ώστε στην συνέχεια να πάρει σπό συτόν την πληροφορία για τον κάθε δηλωμένο host της.)

----------


## Winner

> Εγώ δεν κατάλαβα
> 
> πρέπει να είμαι slave σε όλη τη awmn ζώνη;
> 
> Γιατί με βάζει (μαζί με όλους) στα ns του awmn;
> 
> και μούρχονται όλα τα I πακέτα.
> 
> 
> ...


Αυτό το κάνουμε για την περίπτωση που θέλεις να είσαι. Ώστε να σου έρχονται οι νέες ενημερώσεις αυτόματα.

Λέγαμε να το αλλάξουμε και να βάλουμε 5-6 μοιρασμένους σε γειτονιές αλλά τελικά ακόμα δεν το έχουμε προχωρήσει.

----------


## spirosco

ntrits, μπορεις αντι για slave να δηλωνεις forward τις awmn fw/rev zones στον bind σου, αλλα δεν παιζει και τοσο καλα οσο η σημερινη μεθοδος.

Προτιμοτερο για λογους σταθεροτητας ειναι να ακολουθησεις την κλασσικη οδο:


```
zone "10.in-addr.arpa" IN {
        type slave;
        file "zone/10.in-addr.arpa.dns";
        masters { 10.19.143.13; 10.19.143.12; };
        notify no;
        forwarders { };
};

zone "awmn" IN {
        type slave;
        file "zone/awmn.dns";
        masters { 10.19.143.13; 10.19.143.12; };
        notify no;
        forwarders { };
};
```

Η σειρα των 2 masters δεν εχει σημασια, δεδομενου του uptime αυτων των μηχανηματων.

----------


## DVD_GR

για να μην ανοιγω θεμα παρεμφερες,
ψαχνω πως μεσω των windows πως μπορουμε να δουμε σε ποια ip δειχνει ο dns για ενα site???

----------


## Cha0s

Από command prompt γράφεις 

```
nslookup subdomain.domain.tld
```

Υπάρχουν πάρα πολλά utilities και σε γραφικό περιβάλλον...

Άμα το googlίσεις θα βρεις σίγουρα κάτι που να σε βολεύει.

----------


## mojiro

> για να μην ανοιγω θεμα παρεμφερες,
> ψαχνω πως μεσω των windows πως μπορουμε να δουμε σε ποια ip δειχνει ο dns για ενα site???


επισης υπαρχει και ffox plugin που σου το βγαζει στη status bar

----------


## dalex

....

----------


## DVD_GR

ευχαριστω  ::

----------


## acoul

Σχετικά με την υλοποίηση Root DNS για το δίκτυο του AWMN όπως αυτό γίνεται και στο Internet:

Με την αποχώρηση του harisk και αργότερα του paravoid πραγματικά το όλο σχήμα είναι στον αυτόματο πιλότο ... υποπτεύομαι ότι κάποιο φεγγάρι είχε ασχοληθεί ο mojiro ή/και ο sokratisg αλλά η όλη κατάσταση είναι φλου. Αυτό που πρέπει να γίνει, είναι μια συνάντηση όσων θέλουν να εμπλακούν προκειμένου να σηκωθούν 3-5 Root DNS για το AWMN σε διάφορα σημεία του δικτύου και να βρεθεί τρόπος συγχρονισμού τους, ώστε όταν πέφτει ο μοναδικός Root DNS που έχουμε σήμερα να μην τρέχουμε πανικόβλητοι όπως έγινε με τη μεταφορά των server από την ACN στο ΤΕΙ Πειραιά, ή το down time που υπήρξε το διήμερο που μας πέρασε. Καλό θα ήταν να υπάρξουν redundant υπηρεσίες και για το Forum και το WiND.

Όλα αυτά μπορούν να ξεκινήσουν με την θέληση και διάθεση σε πρώτη φάση και από εκεί και πέρα να υλοποιηθούν. Είναι κάτι που αφορά όλο το δίκτυο και δεν είναι απόφαση μόνο του συλλόγου. Ο σύλλογος απλά μπορεί να βοηθήσει ή να μη βοηθήσει, ανάλογα την διάθεσή του.

Προτείνω λοιπόν, όσοι ενδιαφέρονται να μετέχουν στο να βρεθεί μια λύση σε αυτό το βασικό πρόβλημα να περάσουν μια βόλτα την ερχόμενη Τετάρτη από το σύλλογο προκειμένου να δούμε τι μπορεί να γίνει.

----------


## NetTraptor

Δεν μπορεί ρε παιδιά. Αυτό είναι Bot!  ::

----------


## spirosco

Και ποσο συχνα ειπαμε πως μενει το awmn χωρις root dns?

----------


## acoul

> Και ποσο συχνα ειπαμε πως μενει το awmn χωρις root dns?


κάθε φορά που σκοράρεις ...  ::   ::   ::  γιατί νομίζεις ο john70 έχει τόσα ... down times ...

----------


## bedazzled

> Αρχική Δημοσίευση από spirosco
> 
> Και ποσο συχνα ειπαμε πως μενει το awmn χωρις root dns?
> 
> 
> κάθε φορά που σκοράρεις ...    γιατί νομίζεις ο john70 έχει τόσα ... down times ...


OMG, ο acoul χρησιμοποίησε για πρώτη φορά το mrgreen smiley !!  ::   ::   :: 

Άντε και το twisted ! Πήξαμε στα ψεύτικα χαμόγελα ..

----------


## spirosco

::  τα παραλες  ::  

Ειλικρινα τωρα, ακομη και στη μεταφορα των servers απο την Altec στο ΤΕΙ δεν εξαντληθηκε ο χρονος που χρειαζεται για να γινουν expire οι parent zones.
Τετοιο downtime σε επιπεδο dns δεν ειχαμε ξανα, τουλαχιστον οσο μπορω να θυμηθω για 3-4 χρονια πισω.
Ειχαμε μεμονωμενα downtime που οφειλοταν σε hardware faillure των servers, προ Xen εποχης, σε μια περιπτωση στο server του Wind και σε αλλη μια περιπτωση στο server του forum.
Βεβαια ακομη και σε αυτες τις περιπτωσεις ο ενας εκ των δυο dns επαιζε συνεχως, κι επιπλεον με καποιο redirect ή καποια αλλη προχειρη λυση ο κοσμος απο internet εβλεπε και μια ενημερωτικη σελιδα τουλαχιστον.

Ok, ειναι προφανες πως οσο καλη συνεργασια και υποστηριξη να εχουμε απο το εργαστηριο που μας φιλοξενει, η διαθεσιμοτητα του ειναι κατι που εξαρταται απο την πολιτικη λειτουργιας του ιδρυματος κι οχι μονο απο τους ανθρωπους του αρμοδιου εργαστηριου, με αποτελεσμα να μην μπορει να συγκριθει με το dataroom ενος ISP.

Μιας λοιπον κι ετυχε τωρα αυτο, ετσι και για να θυμηθουμε λιγο το ατυχες θαψιμο που δεχθηκε η επιλογη του σωματειου καποια στιγμη να βαλουμε καποιους servers σε dataroom ISP, καταλαβαινεις Αλεξ πως για να εχουμε αποτελεσματικο redudancy χρειαζομαστε ενα ακομη σημειο φιλοξενιας στο οποιο να μπορουμε να "κουμπωσουμε" τον 2ο server.
Ετσι τουλαχιστον δεν θα εχουμε την εγνοια πως μπορει να "εξαφανιστει" παλι για κανα τριημερο το forum και το wind.

Αν θελουμε redudancy πρεπει να βλεπουμε πως θα καλυψουμε ολα τα critical services, κι οχι μεμονωμενα το dns.
Επειδη με το θεμα dns και περισσοτερων ns εχουμε ξανασχοληθει στο παρελθον, εμπειρικα σου λεω πως δεν μπορεις να συγκρινεις τη διαθεσιμοτητα του server που τρεχει σε ενα "προστατευομενο" περιβαλλον με αυτη του δικου μου ή του δικου σου ή του χ,ψ κλπ.
Το να αυξησουμε την ποσοτητα λοιπον αδιαφορωντας προς στιγμη για την ποιοτητα, δεν εχει νοημα -το εχουμε δοκιμασει ηδη στη πραξη και δεν ειχε αποτελεσμα. Αν ψαξεις λιγο στο forum θα βρεις και καποιες σχετικες συζητησεις τεσπα.

----------


## commando

μπα δε χρειαζεται το AWMN ζει κ βασιλευει,ολα αυτα μαλλον προεκλογικα μου ακουγονται,ευτυχως που ο απολογισμος αυτου του ΔΣ θα ειναι γραμμενος σε μια παραγραφο να παμε για σουβλακια νωριτερα του χρονου το Μαρτη γιατι δε μπορω τις ενστασεις....
Spirosco πηγαινε στη ΣΤΕΦ μηχανολογων το σερβερι και αγορασε ηλιακα που κατεχεις το αντικειμενο για redundancy....
Λυσεις υπαρχουν αλλα ο κορβανας της Αλτεκ επεσε και ουκ αν λαβεις παρα του μη εχοντος....οποτε οοοοοοοτι και να ακουσουμε απο τωρα και μεχρι την επομενη στραβη σας λεω ποιος φταιει προκαταβολικα και ας με πουν προφητη.
Το ευρω.

----------


## bedazzled

> μπα δε χρειαζεται το AWMN ζει κ βασιλευει,*ολα αυτα μαλλον προεκλογικα μου ακουγονται*,ευτυχως που ο απολογισμος αυτου του ΔΣ θα ειναι γραμμενος σε μια παραγραφο να παμε για σουβλακια νωριτερα του χρονου το Μαρτη γιατι δε μπορω τις ενστασεις....
> Spirosco πηγαινε στη ΣΤΕΦ μηχανολογων το σερβερι και αγορασε ηλιακα που κατεχεις το αντικειμενο για redundancy....
> Λυσεις υπαρχουν αλλα ο κορβανας της Αλτεκ επεσε και ουκ αν λαβεις παρα του μη εχοντος....οποτε οοοοοοοτι και να ακουσουμε απο τωρα και μεχρι την επομενη στραβη σας λεω ποιος φταιει προκαταβολικα και ας με πουν προφητη.
> *Το ευρω.*


Ενώ αν είχαμε την δραχμή ...  ::  συμφωνώ για τις (πεταλουδίσιες) προεκλογικές φανφάρες.  ::

----------


## paravoid

Το συγκεκριμένο σχήμα DNS έχει συγκεκριμένα flaws εδώ και χρόνια (λέγε με >512 bytes answer για απάντηση σε NS queries, δηλ. overhead λόγω αλλαγής σε TCP) τα οποία τα γνωρίζουν αυτοί που έχουν τις τεχνικές ικανότητες.
Με άλλα λόγια, δείχνει κάποια σημάδια ηλικίας και scalability που δεν προβλέφθηκε, ούτε μπορούσε να προβλεφθεί, 6+ χρόνια πριν.

Όταν ήμουν μέλος της ομάδας Hostmaster, είχα κάνει συγκεκριμένη πρόταση επ' αυτού (κοντά 3 χρόνια τώρα).
Δυστυχώς ποτέ δεν υλοποιήθηκε.

Υπάρχουν κάποια μυαλά εδώ μέσα που είναι ικανοί για την υλοποίηση ενός άξιου σχήματος (είτε έχει σχέση με το δικό μου είτε όχι), ελπίζω για σας να ασχοληθούν  ::

----------


## acoul

το πρόβλημα με τους γνώστες είναι ότι συνήθως έχουν κακό τρόπο και διάθεση. προσωπικά προτιμώ τους λιγότερο γνώστες με καλύτερο τρόπο, διάθεση, φρεσκάδα και ενθουσιασμό! Όπως και με το open source, μπορεί να μην έχει την καλύτερη ποιότητα μια και ο κόσμος που ασχολείται με αυτό είναι ερασιτέχνης, αλλά έχει πιο πλούσια ανάπτυξη, μεγαλύτερη δυναμική και φυσικά είναι ελεύθερο για όλους !!

----------


## bedazzled

> το πρόβλημα με τους γνώστες είναι ότι συνήθως έχουν κακό τρόπο και διάθεση.


Καλό πράγμα η αυτοκριτική !!  :: 




> προσωπικά προτιμώ τους λιγότερο γνώστες με καλύτερο τρόπο, διάθεση, φρεσκάδα και ενθουσιασμό! Όπως και με το open source, μπορεί να μην έχει την καλύτερη ποιότητα μια και ο κόσμος που ασχολείται με αυτό είναι ερασιτέχνης, αλλά έχει πιο πλούσια ανάπτυξη, μεγαλύτερη δυναμική και φυσικά είναι ελεύθερο για όλους !!


Αντιφάσεις ...  ::  




> το ζουμί είναι οι λίγοι και εκλεκτοί που ξεχωρίζουν





> λίγοι, τρελαμένοι και εκλεκτοί !!





> Καλώς να κοπιάστε όσοι πιστοί, συνήθως λίγοι και εκλεκτοί !!





> η ποιότητα έρχεται συνήθως σε μικρό μέγεθος ...





> η ποιότητα πάντως είναι μαλωμένη με την ποσότητα, αυτό και μόνο καταμαρτυρά πολλά.





> Το βάρος θα πρέπει να δίνεται στην ποιότητα και όχι την ποσότητα





> Δεν νομίζω ότι ο στόχος μας είναι η ποσότητα των κόμβων όσο η ποιότητα.

----------


## mojiro

Acoul, όσοι ασχοληθήκαμε, δε κατακρίναμε τους παλαιότερους ή αυτούς που δεν ασχολούνται, ούτε κοιτάξαμε να ανακοινώσουμε αμέσως την εκκίνηση του project μας... Όλοι μας κάναμε ότι κάναμε για την καφρίλα μας και χαιρόμαστε που έστω και ένας ασχολούνταν με αυτό που φτιάχναμε...


Εσύ σίγουρα θα έχεις να λες για τον proxy σου, από εκεί και πέρα τι έχεις να επιδείξεις; έχεις να επιδείξεις τίποτα άλλο; όχι δε πειράζει δε σε κυνήγησε κανείς...


Φυσικά δε περιμένω να μου απαντήσεις τίποτα πέρα από ανέμους και ύδατα, αλλά πραγματικά απορώ μέχρι που μπορεί να φτάσει αυτή η στάση σου όταν όλος ο κόσμος σε αποδοκιμάζει. Προφανώς αφού δεν έχεις να επιδείξεις τίποτα άλλο (πέρα από τον proxy) χρησιμοποιείς τέτοιες μεθόδους ώστε να δείξεις ότι όλοι είναι άχρηστοι και εσύ που βρίσκεις τα λάθη είσαι ο άξιος... Αμ δε...


Άραγε μήπως έχεις αυτή τη στάση επειδή όλοι οι παλαιοί έχουμε κρυφτεί, λόγω εργασίας, στρατού, κλπ, και καιροφυλακτείς για να γίνεις Administrator, President ή δε ξέρω τι άλλο (Θέλω να δω John70 με Acoul στο ΔΣ);

----------


## fengi1

Ε-περβολες. 
Ψαξε κανα post του blucky και διαβασε την υπογραφη του.

----------


## ShadowCaster

Σπύρο αυτά που λές για datacenter και διαθεσιμότητα ισχύουν όπως όμως ισχύει ότι δεν χρησιμοποιείς πότε έναν root dns. Εξάλλου δεν είμαστε ούτε ISP ούτε καμιά εταιρία για να έχουμε στην διάθεσή μας datacenters κλπ. 

Για μένα ένα replication του root dns σε άλλα 3-5 μηχανήματα στο awmn για αρχή είναι μια σωστή τακτική. Μπορεί να μην έχουμε στο σπίτι μας 99,9% διαθεσιμότητα αλλά δεν έγινε και κάτι, εάν είναι 6 σύνολο τουλάχιστον 3 θα λειτουργούν πάντα, μόνο κάτω από τραγικές συνθήκες θα είναι όλοι οι servers εκτός. Πραγματικά το βρίσκω παράλογο να είσαι αρνητικός σε κάτι τέτοιο. 

Δεν διαφωνώ ότι η διαθεσιμότητα του dns είναι υψηλή αλλά δεν νομίζω ότι βλάπτει κανέναν να υπάρχουν και κάποιοι backup root servers ειδικά εάν κατάλαβα καλά και ο server τώρα βρίσκετε σε ένα εργαστήριο σχολής στο ΤΕΙ Πειραιά. 

Όσο για αυτά που ανέφερε ο Φαίδων όντως μπορούν να διορθωθούν και κάποια ακόμα πράγματα στο dns χρειάζεται λίγο lifting  ::   ::  ...

----------


## NetTraptor

Τρώγεστε με τα ρούχα σας μιας και υπάρχουν ένα κάρο slave και ακόμα και αν δεν σας αρέσει αυτή η λύση μπορουμε να φτιάξουμε και duplicates πανεύκολα. 

Επίσης θα ήθελα να ακούσω επιγραμματικά για το lifting. Πια είναι η μεθοδολογία που προτείνεται πόσα πρέπει να αλλάξουν τα script του wind αν αλλάξει το schema.

Πραγματικά αν υπάρχει ρεαλιστικό σχέδιο .. γιατί να μην το δούμε. 

Ακούω...

----------


## Cha0s

> Σπύρο αυτά που λές για datacenter και διαθεσιμότητα ισχύουν όπως όμως ισχύει ότι δεν χρησιμοποιείς πότε έναν root dns. Εξάλλου δεν είμαστε ούτε ISP ούτε καμιά εταιρία για να έχουμε στην διάθεσή μας datacenters κλπ. 
> 
> Για μένα ένα replication του root dns σε άλλα 3-5 μηχανήματα στο awmn για αρχή είναι μια σωστή τακτική. Μπορεί να μην έχουμε στο σπίτι μας 99,9% διαθεσιμότητα αλλά δεν έγινε και κάτι, εάν είναι 6 σύνολο τουλάχιστον 3 θα λειτουργούν πάντα, μόνο κάτω από τραγικές συνθήκες θα είναι όλοι οι servers εκτός. Πραγματικά το βρίσκω παράλογο να είσαι αρνητικός σε κάτι τέτοιο. 
> 
> Δεν διαφωνώ ότι η διαθεσιμότητα του dns είναι υψηλή αλλά δεν νομίζω ότι βλάπτει κανέναν να υπάρχουν και κάποιοι backup root servers ειδικά εάν κατάλαβα καλά και ο server τώρα βρίσκετε σε ένα εργαστήριο σχολής στο ΤΕΙ Πειραιά. 
> 
> Όσο για αυτά που ανέφερε ο Φαίδων όντως μπορούν να διορθωθούν και κάποια ακόμα πράγματα στο dns χρειάζεται λίγο lifting   ...


Το πρόβλημα δεν είναι σε πόσους DNS Servers έχουμε αλλά στο ότι όλοι πάνε και χρησιμοποιούν το wind σαν forwarder (ούτε καν τραβάνε την ζώνη) και μόλις πέσει μία φορά στο τόσο ψάχνονται όλοι και αποδίδουν το πρόβλημα μέχρι και στο routing...  ::  

Δεν υπάρχει καν η στοιχειώδης τεχνογνωσία από όσους σηκώνουν υπηρεσίες, πόσο μάλλον η διαθεσιμότητα (μέσω αυτών).

Εμένα όσες μέρες ήταν down το wind μια χαρά παίζανε τα dns μου... Δεν πρόλαβε να γίνει expire το zone και όλα καλά.

Πόσοι χρησιμοποιούν dns servers της 'γειτονιάς' τους; Έστω σε επίπεδο δήμου (ή όπως αλλιώς θέλετε χαρακτηρίστε το) να παίζουν μεταξύ τους χωρίς να ζητάνε dns records από το wind...
Πόσοι κάνουν transfer τα zones από το wind ώστε όταν πέσει το wind να συνεχίσουν να παίζουν;
Πόσοι διαφημίζουν τους dns τους ή τους περνάνε σε ανίδεους users ενώ δεν είναι στημένοι να λειτουργούν αν πέσει το wind; (βλ. forwarders πχ)


Πρώτα το πρόβλημα είναι στους κομβούχους (ανέκαθεν ήταν δλδ  ::   ::  ) και μετά στο wind και την διαθεσιμότητα του.
Αν μη τη άλλο είναι το πιο διαθέσιμο service στην ιστορία του awmn.

Το να στηθούν backup servers, νομίζω υπάρχει ήδη σαν υλοποίηση από αρκετούς, εκτός αν δεν μιλάμε για απλό transfer της ζώνης από το wind.
Το να γίνει άλλου είδους replication, είναι πιο περίπλοκο δεδομένου ότι η ζώνη για το .awmn και τα reverse γράφονται από το script του wind.


btw, acoul έχεις να κάνεις τεχνική πρόταση*; 
Νομίζεις ότι οι τεχνικοί την βρίσκουμε με τους μανατζαρέους;

*Αν η απάντηση περιλαμβάνει οτιδήποτε άλλο από τεχνική πρόταση σχετικά με την 'πρωτοτυπη' (  ::   ::  ) ιδέα σου τότε επιβεβαιώνεις ότι είναι ένας ταπεινός μανατζαρέος που τον αγνοούμε επιδεικτικά  ::

----------


## Vigor

> Ακούω...


Ιωσήφ για να μην παρεξηγηθούμε, το σωστό είναι ακού*με*. Όλο το AWMN ακούει.

----------


## NetTraptor

Σχήμα λόγου ... sorry

----------


## papashark

> Αρχική Δημοσίευση από NetTraptor
> 
> Ακούω...
> 
> 
> Ιωσήφ για να μην παρεξηγηθούμε, το σωστό είναι ακού*με*. Όλο το AWMN ακούει.


Χαίρομε που ακόμα ένας το πρόσεξε.

Το "ακούω" σε πρώτο ενοικό είναι πολύ προσβλητικό για τους υπόλοιπους...

----------


## NetTraptor

Ξεκολλήστε. Πάρτε το και επί της ουσίας. Προφανώς όσο και να ακούσω εγώ (με οποιαδήποτε ιδιότητα και γα@#[email protected] την καταδίκη μου αν το εννοούσα με τον τρόπο που τo πασάρατε δις) δεν πρόκειται να δοθεί κάποια λύση αν περισσότεροι και διάφοροι του ενός δεν δουλέψουν για αυτό τον σκοπό. 

Άρα πέφτω στα γόνατα σας για συχώρεση που έγραψα αυτό που σκεφτόμουν εν τάχη. Ελεοc ποια ρε παιδιά. Η τεχνική πρόταση είναι το θέμα μας όχι το ω και το με... αμέσως να πεταχτεί κάποιος να το κ@[email protected]#ψει. What a waste of time

----------


## acoul

πιάνω το διάβασμα ... η ελπίδα πεθαίνει τελευταία αλλά αντί για ανάδραση επί της ουσίας πλημμυρίσαμε πάλι στην εμπάθεια και τις φιλοφρονήσεις από τους γνωστούς αγνώστους ...

άναρχα και με πρωτοβουλίες εδώ και εκεί και όπου βγει ... πάντως αύριο θα είμαι στη λέσχη για κους κους και μπραίην στόρμινγκ ... κοιτάζω λίγο το powerDNS που ήθελε κάποτε να παίξει ο paravoid ...

μια σκούπα στις εμπάθειες, όταν αυτό είναι δυνατόν, μπας και ξαναβρούμε την ουσία της ενότητας που είναι σημαντική.

----------


## papashark

> Ξεκολλήστε. Πάρτε το και επί της ουσίας. Προφανώς όσο και να ακούσω εγώ (με οποιαδήποτε ιδιότητα και γα@#[email protected] την καταδίκη μου το εννοούσα με τον τρόπο που τo πασάρατε δις) δεν πρόκειται να δοθεί κάποια λύση αν περισσότεροι και διάφοροι του ενός δεν δουλέψουν για αυτό τον σκοπό. 
> 
> Άρα πέφτω στα γόνατα σας για συχώρεση που έγραψα αυτό που σκεφτόμουν εν τάχη. Ελεοc ποια ρε παιδιά. Η τεχνική πρόταση είναι το θέμα μας όχι το ω και το με... αμέσως να πεταχτεί κάποιος να το κ@[email protected]#ψει. What a waste of time


Tεχνική πρόταση ?

Για ποιο πράγμα ?

Ποιό ειναι το πρόβλημα ?

Μάλλον από συνήθεια δεν διάβασες με προσοχή...

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

----------


## badge

> κοιτάζω λίγο το powerDNS που ήθελε κάποτε να παίξει ο paravoid ...


Bump κάνε.




> Το πρόβλημα το έχει οριοθετήση σαφέστατα ο cha0s και έχει δώσει και την λύση του


Νομίζω ότι αυτό προσωπικά με καλύπτει απόλυτα επί του θέματος.

----------


## NetTraptor

> κοιτάζω λίγο το powerDNS που ήθελε κάποτε να παίξει ο paravoid ...


Ο PowerDNS έχει καλό integration με MySQL thats all. It's another common DNS. Πέραν αυτού δεν καταλαβαίνω γιατί επιλέγεις να ασχοληθείς με αυτό? 

Εδώ υπάρχουν υπόνοιες ότι η αρχιτεκτονική είναι για τα μπάζα, όχι το ίδιο το DNS server app. Αν θες να κάνω Power on ένα PowerDNS vm που είχα φτιάξει τις προαλλες. Μην παιδευτείς και πολύ με τα Install, compile.

----------


## NetTraptor

Papashark αυτο που πρότεινε ο Cha0s είναι αυτό που είπα και εγώ ακριβώς παραπάνω με τους slave. Δεν προσφέρεις και μπήκες μπηχτός να μου την πεις και εσύ σαν να μην μπορούσες να αφήσεις ένα σχήμα λόγου με ω και ένα με στην ησυχία του.

Νομίζω όμως ότι θέλουμε να ακούσουμε αν έχουμε κάποιο άλλο θέμα όπως είπε ο paravoid για τους root πάνω στο θέμα του schema. Εκεί είναι το ζουμί για μένα μιας και η υπόλοιπη συζήτηση είναι περί ανέμων και υδάτων. Κάποιοι δεν ξερουν ότι ένας secondary στην γειτονιά λύνει 200 προβλήματα, κάποιοι αλλοι κάνουν 40 άσχετα σχόλια και τέλος το ποιο σημαντικό point πέρασε απαρατήρητο. 

Αυτό βέβαια δεν το έπιασε κανείς από αυτούς που πετάνε άσχετα και έσπευσαν να συμφωνήσουν με φίλους και εχθρούς.

Θα ήθελα να ακουσου*με* τι πρόβλημα έχει ακριβώς το schema και τι μπορουμε να κάνουμε να το βελτιώσουμε paravoid?

----------


## acoul

το διάβασμα είναι ο πονοκέφαλος αλλά χωρίς αυτό δε γίνεται τίποτε! απλά πριν πέσω σε αυτό αναζήτησα μια σχετική ανάδραση επί του θέματος ... αλλά τελικά το μοντέλο που παίζει καλά σε εμάς φαίνεται να είναι το one man show ... ??

----------


## spirosco

Το θεμα των επιπλεον root dns εχει ξανασυζητηθει/δοκιμασθει, π.χ. AWMN Alternate DNS
Το πιο ευκολο ειναι να πεις οτι οι μακης, τακης, σουλα θα εξυπηρετουν ως επιπλεον root dns servers.
Με τον τροπο ομως που λειτουργουν οι τωρινοι root servers, οταν θα ειναι ξανα down για οποιοδηποτε λογο, θα πρεπει ο μακης ο τακης και η σουλα να σπευσουν να γυρισουν τις 2 parent ζωνες τους απο slave σε master (οπως εκανες κι εσυ δηλαδη προσφατα στο δικο σου) πριν αυτες γινουν expire.
Αυτο ειναι manual λυση κι οχι αυτοματοποιημενη διαδικασια.

Φυσικα αιντε τωρα ξεκινα να μαθεις στον κοσμακη να μην χρησιμοποιει μονο τους 10.19.143.12 & .13 και περιμενε να δεις ποσο γρηγορα θα γινει... κορυφαια κατασταση  ::  

Μαλλον πιο ευκολο τελικα ειναι να γυρισουμε το ttl σε π.χ. μια βδομαδα για να τελειωνουμε σε πρωτη φαση.
Αλλα μετα με τι θα ασχοληθουμε εδω?

----------


## badge

> Φυσικα αιντε τωρα ξεκινα να μαθεις στον κοσμακη να μην χρησιμοποιει μονο τους 10.19.143.12 & .13


Είναι άπειρες φορές που έχω δει clients να αναφέρουν πρόβλημα με DNS, και η συμβουλή που έρχεται από σχεδόν όλους είναι _"Ελα μωρέ, κάρφωσε αυτές και θα παίξει"_.

Αυτό που ανέφερε ο Cha0s παραπάνω είναι το πρακτικά ορθόν. Οι γειτονικοί DNS να κοιτάζουν τους διπλανούς και παραδιπλανούς, οι clients των κομβούχων άντε και στα 2 hops, και αυτό ανά γειτονιά/δήμο θα παίξει μια χαρούλα χωρίς πολλά πολλά. Οπότε το θέμα καταλήγει στο κλασσικό "educate your users".

----------


## acoul

Μια και το ζήτησε ο Βαγγέλης, ποια είναι η ουσία; η ουσία είναι ότι οι πηγές του δικτύου θα πρέπει να είναι ανοικτές και διαθέσιμες σε όποιον εκδηλώσει το σχετικό ενδιαφέρον να ασχοληθεί με αυτές και να μην είναι αυτές κλειδωμένες, ξεχασμένες κάπου από κάποιους “έμπιστους” που πιθανά να έληξαν λόγω ανειλημμένων υποχρεώσεων και τα συναφή ... κάτι σαν το GPL license και την πρόσβαση στον πηγαίο κώδικα. Υπάρχει πάντα και η λύση του reverse engineering ή του επανασχεδιασμού με δυνατότητα αποτύπωσης και import του υπάρχοντος σχήματος.

Το ερώτημα είναι ποιος διαχειρίζεται τα του δικτύου. Ο σύλλογος ή ομάδες άναρχα, αυτόκλητα κατά περιοχές και διάθεση.

Ένα παράδειγμα είναι το OLSR, ξεκίνησε με πρωτοβουλία συγκεκριμένων ομάδων, 1-2 άτομα, ο σύλλογος απουσίασε από αυτό το εγχείρημα, δεν εξετάζω το καλώς ή κακώς, γεγονότα παραθέτω. Το αποτέλεσμα είναι ότι ελάχιστοι γνωρίζουν τι είναι αυτή η προσπάθεια και δεν νομίζω κανείς να έχει τη διάθεση να κάνει μια σχετική παρουσίαση για αυτό και κατ επέκταση εισήγηση για την σωστή και ενιαία υλοποίησή του ανά περιοχές.

Το θέμα του root DNS και addressing plan παραμένει στον αέρα μέχρι σήμερα. Ούτε εγώ προσωπικά γνωρίζω την ακριβή ιστορία του. Κάποιοι το ξεκίνησαν, κάποιοι το παρέλαβαν και κάποιοι το συντηρούν χωρίς όμως να ξέρουμε οι υπόλοιποι χρήστες της υπηρεσίας σε τι κατάσταση βρίσκεται και αν υπάρχει ανάπτυξη αφού το ίδιο το δίκτυο αναπτύσσεται καθημερινά με ρυθμούς που είναι πολύ πιθανό σύντομα να μην ελέγχονται εύκολα.

Πως διασφαλίζεται η διαθεσιμότητα και η καλή λειτουργία του AWMN registrar, και του routing κατ επέκταση; υπάρχουν υπεύθυνοι με δεσμεύσεις στην διαθεσιμότητά και αφοσίωση τους στην υπηρεσία αυτή; πως ορίζονται; από το Δ.Σ. Είναι σύμφωνο το υπόλοιπο δίκτυο με αυτό το μοντέλο; ποιο το μέλλον αυτού του μοντέλου κλπ. Τι γίνεται αν ο winner και όποιοι άλλοι λιγοστοί γνωρίζουν τα internals απλά δεν έχουν το χρόνο και τη διάθεση αύριο να ασχοληθούν με αυτό που εθελοντικά μέχρι σήμερα ασχολούνται; θα υπάρχει συνέχεια; κλπ.

----------


## Cha0s

Έχεις λάθος.

Το πραγματικό ερώτημα ξέρεις ποιο είναι;

*Τι προσπαθείς να πετύχεις; 
Τι ακριβώς θες από το δίκτυο και έχεις λυσσάξει να τα βρεις όλα έτοιμα στο πιάτο;*


Θες DNS; Κάτσε διάβασε και έλα με ΤΕΧΝΙΚΗ ΠΡΟΤΑΣΗ όχι με πολιτικό-αμπελοφιλοσοφίες.


Μάλλον δεν το έχεις καταλάβει, αλλά σε έχουν πάρει όλοι χαμπάρι ότι δεν σκαμπάζεις γρι απόσα ζητάς κάθε τρεις και λίγο.
Μην περιμένεις να σε πάρει κανείς σοβαρά.
Τουλάχιστον όχι όσοι έχουν την τεχνογνωσία. Αυτοί δεν τα πάνε καλά με μανατζαρέους της πλάκας  :: 

Ειδικά όταν δεν δοκιμάζεις να φτιάξεις τίποτα και μόνο ζητάς τότε αρχίζει να γίνεται ύποπτο αλεξανδρίνο μου...
Τι θες να πετύχεις και δεν μας το αναφέρεις μέσα στις μακροσκελείς αμπελοφιλοσοφίες σου;
Ποιο είναι το κίνητρο σου;  ::

----------


## bedazzled

> Έχεις λάθος.
> 
> Το πραγματικό ερώτημα ξέρεις ποιο είναι;
> 
> *Τι προσπαθείς να πετύχεις; 
> Τι ακριβώς θες από το δίκτυο και έχεις λυσσάξει να τα βρεις όλα έτοιμα στο πιάτο;*
> 
> 
> Θες DNS; Κάτσε διάβασε και έλα με ΤΕΧΝΙΚΗ ΠΡΟΤΑΣΗ όχι με πολιτικό-αμπελοφιλοσοφίες.
> ...


Cha0s+++++++++++++++++++++++

----------


## badge

> η ουσία είναι ότι οι πηγές του δικτύου θα πρέπει να είναι ανοικτές και διαθέσιμες


Μα κλειστές θα ήταν εάν δε μπορούσες να τραβήξεις ζώνες. Ε, μπορείς. Και μπορείς να τις κάνεις και ό,τι επιθυμείς. Και να φτιάξεις οτιδήποτε θέλεις με βάση αυτές, και να παράγεις αποτελέσματα, και να δείξεις έργο και τα πάντα. Το ερώτημα άρα είναι *τι παραπάνω* θες να κάνεις, και ποια είναι η δυνατότητα που δεν σου δίνεται; Συγκεκριμένα πράγματα, παρακαλώ αν γίνεται. Και να σου θυμήσω ότι στη μοναδική υπηρεσία όπου υπήρχε ελεύθερη write πρόσβαση έφτιαξες fake εγγραφές, και ύστερα ζήτησες τα ρέστα πού και πώς δημιουργηθήκανε (για να μη ξεχνιόμαστε).




> Ένα παράδειγμα είναι το OLSR


Εντελώς ατυχές το παράδειγμα, και μαζί και η απόπειρα πηδήματος από το ένα θέμα στο άλλο.




> Πως διασφαλίζεται η διαθεσιμότητα και η καλή λειτουργία του AWMN registrar, και του routing κατ επέκταση; υπάρχουν υπεύθυνοι με δεσμεύσεις στην διαθεσιμότητά και αφοσίωση τους στην υπηρεσία αυτή;


Για υπευθύνους με δεσμεύσεις παρακαλώ αποτανθείτε σε εταιρίες Πληροφορικής, κατά προτίμηση τις ακριβές του κλάδου. Όσο για τη διασφάλιση, εντάξει, το καταλάβαμε, μόνο εσύ το πονάς το δίκτυο....

----------


## commando

Η απαντηση σαυτο το τοπικ θα δοθει στην 9η σελιδα και οπως λεει και ο νομος του Μερφυ θα φανει οτι ηταν ανωφελο να ξεκινησει εξαρχης.

----------


## acoul

> Αρχική Δημοσίευση από acoul
> 
> Ένα παράδειγμα είναι το OLSR
> 
> 
> Εντελώς ατυχές το παράδειγμα, και μαζί και η απόπειρα πηδήματος από το ένα θέμα στο άλλο.


Ίσα ίσα, εκεί είναι το ζουμί της υπόθεσης! Προφήτης μεν ο commando, αλλά η κατάληξη του δικτύου με την πλήρη έλλειψη διάθεσης για οργανωμένη συμμετοχή και συνεργασία έστω και σε μορφή ανάδρασης σε θέματα όπως αυτό, βαδίζει σε ένα μοντέλο με περιοχές που θα έχουν μια ανεξάρτητη διαχείριση και οργάνωση όπως γίνεται ήδη λίγο πολύ στις περιοχές που λειτουργεί το OLSR routing. Δεν λέω ότι είναι κακό ή καλό, μια ματιά μπροστά προσπαθώ να ρίξω ... εδώ είμαστε και θα δούμε πως θα είναι τα πράγματα τα επόμενα δυο χρόνια. Όσο για τα πυροτεχνήματα, αυτά πάντα θα υπάρχουν και θα είναι ωραία γιατί ακριβώς διαρκούν λίγο.

----------


## bedazzled

> Αρχική Δημοσίευση από badge
> 
> 
> 
> 
> 
> 
>  Αρχική Δημοσίευση από acoul
> 
> ...


Μήπως φοβάσαι ότι το AWMN θα έχει την τύχη της ΕΕΧΙ;

Α, και μιας και μιλάμε για προφητείες, ορίστε ένα προφητικό thread.

----------


## NetTraptor

> Η απαντηση σαυτο το τοπικ θα δοθει στην 9η σελιδα και οπως λεει και ο νομος του Μερφυ θα φανει οτι ηταν ανωφελο να ξεκινησει εξαρχης.


Το πρακτικό μέρος που περιγράφεις έχει γίνει ήδη. 

Εγώ περιμένω κάτι για αυτό 




> - Κατανομή 4-5 κεντρικών DNS στο δίκτυο, σμύκρινση των NS της ζώνης.
> => επίλυση του DNS-over-tcp bug σε κάθε query


Με ενδιαφέρει και θέλω να το ψάξουμε (αφού το θέλετε.. εγώ πάντως θα το σκαλίσω λίγο) ... 

Αναρωτιέμαι ποιο θα ήταν αυτό το schema? Με περισσότερα του ενός TLD? Μιλάμε για τα forward η τα Reverse? Πως επιτυγχάνεται η σμίκρυνση των NS? Πως σπάει η awmn root ζώνη σε πολλούς root? DNS-over-TCP? Γιατί γίνεται αυτό? έχουμε tcp chit chat μεταξύ root και local DNS servers? 

Μάλλον μπερδεύτηκα. Ίσως είναι ποιο απλά τα πράγματα και εμένα το μυαλό μου έφυγε... Χαζά ερωτήματα... Όπως το αν χ@#$% οι αρκούδες στο δάσος? Δεν εχω καταλάβει την αρχιτεκτονική της παραπάνω πρότασης (the bases of it) και κάνω ερωτήσεις ότι να ναι. 

Can someone help? Μπορείτε να μου δώσετε μια πορεία ώστε να κάνω και τις σωστές ερωτήσεις αλλά και τις σωστές κινήσεις?  ::

----------


## paravoid

> Date: Fri, 06 Jan *2006* 20:47:17 +0200
> From: Faidon Liambotis
> To: AWMN Hostmaster <hostmaster στο awmn τελεία net>
> Subject: [RFC 1/2] Anycast & Multiple masters
> 
> Καλησπέρα,
> Μια που μπήκε η νέα χρονιά (καλή χρονιά σε όσους δεν έχω ήδη πει :)
> καιρός να αρχίσουμε να κάνουμε τίποτα δημιουργικό ;-)
> Ακολουθεί Request for Comment Series (2 items για αρχή, μόνο!).
> ...


Να σημειώσω ότι πέρα από το notify storm, έχει προστεθεί και το εξής πρόβλημα:

Σε κάθε query για κάτι που είναι στη root ζώνη .awmn (π.χ. http://www.awmn) απαντώνται, λόγω πρωτοκόλλου, και οι nameservers της ζώνης αυτής (.awmn).
Επειδή αυτοί είναι *πάρα* πολλοί και ξεπερνούν τα 512 bytes σε μέγεθος (by far...), ο DNS server σύμφωνα με το spec απαντάει στην UDP ότι "reply too large" και ο client ξαναδοκιμάζει σε TCP πλέον. Epic fail :)

----------


## Mick Flemm

Καλή φάση το Anycast γενικώς αλλά νομίζω πως στην περίπτωση ενός ασύρματου δικτύου δεν είναι και ότι καλύτερο, στη περίπτωσή μας δεν σημαίνει πως ο κοντινότερος είναι και ο καλύτερος (και στο internet έχουν αντίστοιχα προβλήματα και η λύση τους θέλει αρκετό ψάξιμο -και προϋποθέτει τουλάχιστον μια ακόμα εφεδρική IP ή καλύτερα "cloud" από DNS servers-). Θέλει αρκετά καλό και προσεγμένο σχεδιασμό, δεν είναι απλό σε καμία περίπτωση, ακόμα κι αν αγνοήσουμε τα προβλήματα που αναφέρει ο Φαίδωνας. Υπάρχουν και άλλα που φαίνονται στη πράξη όπως πχ. το latency που εμφανίζεται σε αρκετές περιπτώσεις και το outage λόγω του flapping που έχουμε όταν αλλάζει συχνά η δρομολόγηση (μπορεί να είναι session-less αλλά αυτό δε σημαίνει ότι δεν χάνονται πακέτα κατά την αλλαγή δρομολόγησης και στο DNS αυτό φαίνεται !).

----------


## paravoid

> Καλή φάση το Anycast γενικώς αλλά νομίζω πως στην περίπτωση ενός ασύρματου δικτύου δεν είναι και ότι καλύτερο, στη περίπτωσή μας δεν σημαίνει πως ο κοντινότερος είναι και ο καλύτερος (και στο internet έχουν αντίστοιχα προβλήματα και η λύση τους θέλει αρκετό ψάξιμο -και προϋποθέτει τουλάχιστον μια ακόμα εφεδρική IP ή καλύτερα "cloud" από DNS servers-). Θέλει αρκετά καλό και προσεγμένο σχεδιασμό, δεν είναι απλό σε καμία περίπτωση, ακόμα κι αν αγνοήσουμε τα προβλήματα που αναφέρει ο Φαίδωνας. Υπάρχουν και άλλα που φαίνονται στη πράξη όπως πχ. το latency που εμφανίζεται σε αρκετές περιπτώσεις και το outage λόγω του flapping που έχουμε όταν αλλάζει συχνά η δρομολόγηση (μπορεί να είναι session-less αλλά αυτό δε σημαίνει ότι δεν χάνονται πακέτα κατά την αλλαγή δρομολόγησης και στο DNS αυτό φαίνεται !).


Ο κοντινότερος κόμβος είναι και ο καλύτερος.
Δεν υπάρχουν άλλα κριτήρια (το processing power είναι αμελητέο σε αυτή την υπηρεσία).

Η "εφεδρική" IP που λες ούτως ή άλλως υπάρχει, αναγκαστικά.
Όταν λες "cloud" από DNS servers τι εννοείς; Για κάτι τέτοιο πρόκειται, προφανώς.

Σοβαρά μιλάς ότι μιλάμε για latency σε δίκτυο με διψήφια νούμερα ms το πολύ;

Για το flapping -αν υπάρχει θέμα, που τότε δεν υπήρχε, δεν ξέρω για τώρα- μπορείς να "τιμωρείς" τους flappers, είναι μέσα στο spec του BGP.

----------


## NetTraptor

ΟΚ I got you... Γιατί δεν έλεγες anycast  ::  

αυτό μπορεί να γίνει με 2 clouds 3 clouds whatever (αυτό που εννοεί είναι να έχεις 2 cloud me διαφορετικά members σε περίπτωση που κάτι γίνεται με τον κοντινότερο που ανήκει στο cloud 1... πας σε άλλον που ανήκει στο δεύτερο cloud me την secondary ας πούμε IP). Η διαφήμιση στο BGP πρέπει να γίνεται από το ίδιο το μηχάνημα (DNS Server) ώστε να εξαφανίζετε με το πρώτο πρόβλημα αλλά επίσης να υπάρχει τρόπος σε περίπτωση που κρεμάσει κάποιο service να κατεβάζουμε το subnet/IPs με κάποιο watchdog (?). Έχει απαραίτητη προϋπόθεσή ένα BGP που να παίζει καλά (σε δοκιμές που είχαν γίνει υπάρχει αλλόκοτη συμπεριφορά) και να μην είναι σάπιο από πειράγματα. Δεν αλλάζει κάτι ουσιαστικό στο schema και εξακολουθεί να έχει ανάγκες replication υπό κάποια μορφή Master-something/someway-Master, Master-slave και στην ουσία αυτό που κανουμε είναι να χρησιμοποιήσουμε το shortest path για να φτάσουμε σε μια IP που στην ουσία αντικαθιστά (Κρύβει) μια πραγματική. 
Έχει ένα elegance, το προτέρημα ότι θυμάσαι 2 IP (αν έχεις 2 cloud) και ότι δεν ξεμένεις ποτέ από ένα server που θα απαντήσει ....δεν λέω, αλλά πόσο ποιο εξυπηρετικό και εύκολο είναι να οργανωθούν Slave ή replicated Master DNS ανά περιοχή. Οι server θα πρέπει να εγκατασταθούν έτσι και αλλιώς... ασε που ψάξε βρες ποια με τα filters στο Bgp...  ::

----------


## Mick Flemm

> Ο κοντινότερος κόμβος είναι και ο καλύτερος.
> Δεν υπάρχουν άλλα κριτήρια (το processing power είναι αμελητέο σε αυτή την υπηρεσία).


Αν ο κοντινότερος κόμβος δεν έχει και τόσο καλό SNR και έχεις packet loss (που συμβαίνει συχνά σε ασύρματα δίκτυα, ειδικά όταν παίζει αέρας ή προβληματικά γενικώς link) εξακολουθεί λες να είναι ο καλύτερος ? Γι' αυτό στα ασύρματα δίκτυα χρησιμοποιούμε περισσότερο link state πρωτόκολλα (ή κάτι ενδιάμεσο) και όχι τόσο distance vector. Στην παρούσα φάση που έχουμε έναν σταθερό DNS πχ. τρώμε στη μάπα μόνο τις αλλαγές στο ενδιάμεσο (που δεν είναι και τόσο πρόβλημα αν έχεις αρκετά links στον κόμβο σου), αν όμως και ο ίδιος ο DNS είναι ένα route από μόνος του και ξαφνικά χάνεται απ' το routing table (και λογικά και απ' το routing table των γειτόνων σου), μέχρι να βρεθεί ο επόμενος καλύτερος -και αυτό να φτάσει σε εσένα- έχεις επιπλέον overhead. Δεδομένου ότι στο δίκτυο έχουμε αρκετό flapping (τουλάχιστον όταν είχα δει τελευταία φορά) και κάτι τέτοιο είναι αρκετά πιθανό να συμβεί, το outage μπορεί να φτάσει τα μερικά λεπτά για ολόκληρα κομμάτια του δικτύου. Όταν αυτό συμβαίνει για τον DNS, τον τρώνε όλα τα services που χρησιμοποιούν DNS και αυτό μεταφράζεται σε latency της υπηρεσίας (όχι του δικτύου, γενικώς το anycast υποτίθεται ότι μειώνει το latency).




> Η "εφεδρική" IP που λες ούτως ή άλλως υπάρχει, αναγκαστικά.
> Όταν λες "cloud" από DNS servers τι εννοείς; Για κάτι τέτοιο πρόκειται, προφανώς.


Παραπάνω (στην πρότασή σου) λες να κάνουμε assign μια IP στην υπηρεσία (10.0.0.1), δηλαδή να έχουμε ένα cloud από DNS servers. Πάρε ένα παράδειγμα του τι μπορεί να συμβεί (το πρώτο που αναφέρει), στο internet αναφέρεται αλλά κι εμείς έχουμε αντίστοιχα θέματα με τη τοπολογία (όπου δορυφόρο, βάλε link με προβλήματα latency πχ. λόγω channel utilization και όπου different routing policies βάλε πχ. olsr confederation κλπ).
http://www.sanog.org/resources/sanog8/s ... gaurab.pdf




> Σοβαρά μιλάς ότι μιλάμε για latency σε δίκτυο με διψήφια νούμερα ms το πολύ;


Εγώ θυμάμαι κάτι 200άρες πάντως, δεν ξέρω αν έχει αλλάξει πολύ το σκηνικό από τότε. Την τελευταία φορά που είδα το Nagios πριν πέσει, είχα πετύχει αρκετούς κόμβους σε αυτή τη κατηγορία. BTW το delay που μετράς με το ping πχ. δεν έχει απαραίτητα σχέση με το latency που βλέπεις γενικά στο δίκτυο όταν πχ. αλλάζει η δρομολόγηση ή έχεις packet loss.




> Για το flapping -αν υπάρχει θέμα, που τότε δεν υπήρχε, δεν ξέρω για τώρα- μπορείς να "τιμωρείς" τους flappers, είναι μέσα στο spec του BGP.


Δεν διαφωνώ ότι μπορείς να κάνεις γενικώς optimizations στο BGP, το θέμα είναι ότι το BGP δεν είναι το καλύτερο δυνατό πρωτόκολλο για το δίκτυό μας, άσε που δεν υπάρχουν πρακτικά "borders" και ASes έτσι όπως το έχουμε κάνει με αποτέλεσμα να γεμίζουν οι routing tables και να τρώμε τάπες. Εδώ έχουμε φτάσει να έχουμε κόμβους με 2 /24άρια subnets και 2+ routers (και 2+ ASes αντίστοιχα) και να μη λέει κανείς τίποτα (ούτε καν να κόψουν το /24 δεν μπορούν σε μικρότερα και να ανακοινώνουν 1 AS), το allocation και το αρχικό μας πλάνο έχει πάει περίπατο, άντε τώρα να μαζέψεις τα ασυμμάζευτα και να κάνεις enforce σωστό routing policy. Κανονικά θα έπρεπε να έχουμε χωρίσει σωστά τα ASes ανα περιοχές, μέσα σε κάθε περιοχή να παίζει ένα link state πρωτόκολλο και κάθε AS να έχει τον δικό του DNS (anycast ή όχι), τον δικό του SIP/whatever proxy, το δικό του nagios/snmp monitor service κλπ. Το δίκτυο θα μπορούσε να είναι πραγματικά όμορφο από πλευράς τοπολογίας κλπ αλλά τα έχουμε κάνει ΛΙΜΠΑ ! Ε σε αυτό το λίμπα υπόβαθρο δεν θα πρότεινα να στήσουμε anycast υπηρεσίες, πόσο μάλλον DNS.

----------


## akops76

Καλησπέρα,

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

Αν έχω καταλάβει σωστά το πρόβλημα που προέκυψε είναι ότι αυτή την στιγμή υπάρχουν 2 μόνο
root NS οι οποίοι είναι συγκεντρωμένοι σε ένα μόνο κόμβο (του ΤΕΙ Πειραία) ο οποιος λόγω του ότι
δεν είναι ISP δεν έχει την απαιτούμενη υψηλή διαθεσιμότητα.

Συνεπώς η απλή λογική λέει οτι απλά αυξανούμε των αριθμό των root NS σε 2,3 ακόμα
προσπαθώντας βέβαια οι νέοι αυτοί NS να καλύπτουν διαφορετικές γεωγραφικές
περιοχές του δικτύου. 
Οσο αφορά την υλοποίηση, όλοι θα πρέπει να παίζουν ως master(ώστε να μην απαιτούνται manual ενέργειες
σε περιπτώσεις προβλήματος) και ο συγχρονισμός να γίνεται με άλλους τρόπους (πχ rsync). Στην περίπτωση δε του powerdns ,
τότε λόγω της εν γένης υποστήριξης mysql , υπάρχει δυνατότητα για συγχρονισμό με mysql replication. 

Απο εκεί και πέρα η δική μου εκτίμηση είναι οτι στους νέους NS που θα μπούν θα πρέπει να έχουν αποκλειστικά πρόσβαση
η όποια ομάδα έχει οριστεί και σήμερα να διαχειρίζεται την υπηρεσία DNS και οχι ο κομβούχος στον οποιο θα φιλοξενείται η υπηρεσία.
Αυτό όσο δύσκολο (& περιεργο) ακούγεται θα μπορούσε να γίνει υλοποίώντας τους NS αυτούς σε εικονικές μηχανές και απλά ο κάθε κόμβούχος
που επιθυμεί να διαθέσει κάποιους πόρους στον εξυπηρετητή που έχει.

Τέλος επειδή μπορεί σήμερα κάποιος να θέλει να φιλοξενήσει ένας NS , αλλα αύριο για χyz λόγους να μην μπορεί, αρα ο NS
θα πρέπει να πάει σε νέο κόμβο, θα πρέπει διασφαλίστει το θέμα της IP των NS ώστε αυτή να είναι σταθερή όπου και να πάει. Αυτό πχ
νομίζω οτι λύνεται αφιερώνοντας ένα class C σε κάθε NS , το οποιο θα τον ακολουθεί σε όποιο κόμβο και να πάει. Ισως να υπάρχουν
και καλύτερες λύσεις βέβαια απο αυτή. Το αnycast μάλιστα είναι μία, άλλη τη θεωρώ ιδιαίτερα πολύπλοκή.

Χαιρετώ,
Αντώνης

----------


## Cha0s

> Καλησπέρα,
> 
> Αν δεν σας πειραζεί θα ήθελα και εγώ να προσθέσω την άποψη μου για το θέμα.
> Εχω την εντύπωση λοιπον οτι το ζήτημα είναι αρκετά ποιο απλό απο ότι παρουσιάζεται.
> 
> Αν έχω καταλάβει σωστά το πρόβλημα που προέκυψε είναι ότι αυτή την στιγμή υπάρχουν 2 μόνο
> root NS οι οποίοι είναι συγκεντρωμένοι σε ένα μόνο κόμβο (του ΤΕΙ Πειραία) ο οποιος λόγω του ότι
> δεν είναι ISP δεν έχει την απαιτούμενη υψηλή διαθεσιμότητα.
> 
> ...



Μου αρέσει σε γενικές γραμμές η προταση σου.

Βέβαια μιλάμε για pseudo-master μιας και στο config θα είναι master τα zones αλλά δεν θα ενημερώνωνται ποτέ αν πέσει το wind.
Παρόλαυτα μου ακούγεται η πιο ρεαλιστική λύση στο πρόβλημα.

Αυτό με το mobile c-class μου άρεσε επίσης.
Μπορεί να χωρίστεί το δίκτυο σε 5-7 (random νούμερο) περιοχές (c-classes) πχ και να μεταφέρονται αναλόγως κάθε φορά.

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

Από την άλλη η ιδέα του anycast με έψησε στα πλαίσια του πειραματισμου και της δοκιμής νέων πραγμάτων.

Αν κατάλαβα σωστά με τον τρόπο που θα λειτουργεί αυτόματα όλοι θα επιλέγουν τον πραγματικά κοντινό (βάση bgp hops έστω) dns server δυναμικά.

Μου ακούγεται πολύ καλή ιδέα και συμβαδίζει με την άναρχη και διαρκώς μεταβαλλόμενη τοπολογία του δικτύου.
Σύν ότι δεν θα έχουμε πια τα φαινόμενα με ξεχασμένους users που τους πέρασαν κάποτε έναν dns στην άλλη άκρη της αθήνας και μόλις πέσει να μην έχει δίκτυο και να ψάχνεται ώντας αδαής (με την καλή έννοια).

Σχετικά με το latency, packet loss κλπ που αναφέρθηκαν από τον Mick & Paravoid, αφενώς το δίκτυο έχει σταθεροποιηθεί πολύ περισσότερο απότι παλιότερα και αφετέρου με εξαίρεση μερικών κόμβων, οι περισσότεροι ούτως ή άλλως πάλι το dns server του wind χρησιμοποιούν.
Άρα τι να παίζεις με anycast και να αλλάξει κάτι στο routing, τι να παίζεις όπως τώρα και να αλλάξει κάτι στο routing, το ίδιο μου φαίνεται.
Ίσα ίσα αν είναι και πιο κοντά ο dns server μέσω anycast αν γίνει κάποια αλλαγή στο bgp δεν θα την 'δεις' πιο γρήγορα  ::  

I donno... η μία λύση είναι πρακτική και γρήγορη, ή άλλη είναι πιο... challenging  ::  

Εγώ λεώ να δοκιμάσουμε και τα 2!

----------


## NetTraptor

Το ένα σχεδόν παίζει _εξαπανέκαθεν_ σχεδόν το ίδιο.
Το άλλο πάμε να το δοκιμάσουμε με την προϋπόθεση ότι πρέπει να φύγουν ή να τροποποιηθούν φίλτρα. Αφού ψήνεστε..  ::

----------


## Mick Flemm

Πάντως το mobile c class απ' το anycast δεν έχει διαφορά, τη μία ανακοινώνεις το /24 και την άλλη το /32. Ίσως θα μπορούσαμε να αρχίσουμε από αυτό που λέει ο Αντώνης χρησιμοποιώντας anycast για το χαβαλέ και κάνοντας sync όχι με τον "master of masters" που λέει ο Φαίδωνας αλλά κλασικά με rsync ή mysql replication (προτιμώ το 1ο  :: ), γενικώς είναι καλή φάση το ψάξιμο. But you 've been warned, η δρομολόγηση στο δίκτυο δεν είναι και η καλύτερη, δέχομαι αυτό που λες chaos ότι έχει σταθεροποιηθεί αρκετά, οπότε μπορούμε να το δοκιμάσουμε. Ποιοί είναι μέσα και προτίθενται να διαθέσουν τους κόμβους τους για κάτι τέτοιο ? Προϋπόθεση να είναι σταθεροί. Αλήθεια εκείνο το Nagios θα ανέβει ποτέ ? Να έχουμε μια εικόνα για το flapping των κόμβων είναι πολύ χρήσιμο σε αυτή τη φάση.

----------


## Mick Flemm

> Σχετικά με το latency, packet loss κλπ που αναφέρθηκαν από τον Mick & Paravoid, αφενώς το δίκτυο έχει σταθεροποιηθεί πολύ περισσότερο απότι παλιότερα και αφετέρου με εξαίρεση μερικών κόμβων, οι περισσότεροι ούτως ή άλλως πάλι το dns server του wind χρησιμοποιούν.
> Άρα τι να παίζεις με anycast και να αλλάξει κάτι στο routing, τι να παίζεις όπως τώρα και να αλλάξει κάτι στο routing, το ίδιο μου φαίνεται.
> Ίσα ίσα αν είναι και πιο κοντά ο dns server μέσω anycast αν γίνει κάποια αλλαγή στο bgp δεν θα την 'δεις' πιο γρήγορα


Σκέψου 2 σενάρια...

α) Μένεις στο Χαλάνδρι πχ και δεν έχουμε anycast DNS, ο DNS βρίσκεται σε έναν stable κόμβο πχ. στην Αγ. Παρασκευή. Αλλάζει κάτι στο routing ενδιάμεσα λοιπόν, αν έχεις αρκετά links (που λογικά θα έχεις γιατί είσαι router) και ο DNS δεν φεύγει από τη θέση του τότε θα γίνει resolve αρκετά γρήγορα η νέα διαδρομή γιατί όλο και κάποιος γείτονάς σου έχει μια διαδρομή που παίζει (εξαρτάται πόσο μακρυά από εσένα και τον DNS έγινε η αλλαγή και πόσο "πυκνό" είναι το δίκτυο). Αν πέσει ο DNS (ή η αλλαγή στο routing γίνει πολύ κοντά στον DNS ώστε να επηρεάσει όλους σου τους άμεσους γείτονες) τότε απλά πας στον secondary το οποίο και πάλι γίνεται γρήγορα αφού θα τον έχεις ήδη στο routing table σου.

β) Έστω τώρα ότι έχουμε anycast dns servers (ή και κάποια άλλη υπηρεσία, δεν έχει σχέση το layer4+ εδώ για layer3 μιλάμε), αν αλλάξει κάτι ενδιάμεσα στο routing συμβαίνει το ίδιο με πριν (άρα κανένα πρόβλημα), αν όμως πέσει ο DNS server (και δεν έχουμε και secondary αλλά μόνο ένα όπως προτείνει ο Φαίδωνας) τότε μέχρι να γίνουν update οι routing tables της "γειτονιάς" μας και να πάμε να πέσουμε στον παραδίπλα DNS (που μπορεί να είναι πχ. στους Αμπελόκηπους σύμφωνα με το BGP) θα τρώμε τα μούτρα μας (no route to host/destination host unreachable κλπ). Αν δεις στο internet υπάρχουν papers που έχουν κάνει μετρήσεις και παρατήρησαν ότι το outage σε μεγάλα (ενσύρματα !) δίκτυα (και το δικό μας δεν είναι μικρό έτσι όπως το έχουμε κάνει με κάτι εκατοντάδες ASes) μπορεί να ξεπεράσει το λεπτό.

----------


## Neuro

Ένα μικρό μέρος μη τεχνικών δημοσιεύσεων στάλθηκε για ανακύκλωση. Δυστυχώς παλαιότερες, μη τεχνικές δημοσιεύσεις ήταν δύσκολο να διαχωριστούν χωρίς να δημιουργηθούν κενά. Παρακαλώ αφήστε τη τεχνική συζήτηση να εξελιχθεί, χωρίς τα καθιερωμένα αστειάκια.

----------


## paravoid

> Αν έχω καταλάβει σωστά το πρόβλημα που προέκυψε είναι ότι αυτή την στιγμή υπάρχουν 2 μόνο
> root NS οι οποίοι είναι συγκεντρωμένοι σε ένα μόνο κόμβο (του ΤΕΙ Πειραία) ο οποιος λόγω του ότι
> δεν είναι ISP δεν έχει την απαιτούμενη υψηλή διαθεσιμότητα.


Τα προβλήματα είναι -ή ήταν τουλάχιστον- δύο:
α) Υπάρχουν δύο "root" NS που είναι σε ένα κομμάτι του δικτύου = SPOF
β) Υπάρχουν πάρα πολλοί "slaves", δηλαδή nameservers που είναι στα NS records της TLD ζώνης.

Το (β) είναι σημαντικότερο πρόβλημα κατ' εμέ.




> Συνεπώς η απλή λογική λέει οτι απλά αυξανούμε των αριθμό των root NS σε 2,3 ακόμα
> προσπαθώντας βέβαια οι νέοι αυτοί NS να καλύπτουν διαφορετικές γεωγραφικές
> περιοχές του δικτύου. 
> Οσο αφορά την υλοποίηση, όλοι θα πρέπει να παίζουν ως master(ώστε να μην απαιτούνται manual ενέργειες
> σε περιπτώσεις προβλήματος) και ο συγχρονισμός να γίνεται με άλλους τρόπους (πχ rsync). Στην περίπτωση δε του powerdns ,
> τότε λόγω της εν γένης υποστήριξης mysql , υπάρχει δυνατότητα για συγχρονισμό με mysql replication.


Να διευκρινήσω κάτι που δεν είναι προφανές (σε όλους, όχι σε σένα):
Το "master" και "slave" είναι technicalities που δεν βλέπει ο client.

Όλοι οι NS σε μια ζώνη είναι ισότιμοι, οι πελάτες δεν καταλαβαίνουν διαφορά.
Η μόνη διαφορές μεταξύ "master" και "slave" είναι ότι κάθε slave τραβάει τη ζώνη με *XFR από τον master.
Αυτό μπορεί να γίνει και με out-of-band μέσα (rsync, MySQL replication, LDAP, scp, whatever).

Anyway, δεν πρόκειται να ασχοληθώ με την υλοποίηση, οπότε τα specifics σε αυτούς που θα ασχοληθούν.
Καλή τύχη  ::

----------


## Acinonyx

Δυστυχώς δε βλέπω φως στο τούνελ...

Οι anycast δεν δίνουν πάντα αξιόπιστες απαντήσεις. Χρειαζόμαστε πάντα secondary backup για τα truncated. Δε μας γλυτώνει επίσης από το πρόβλημα του SPOF. Ακόμη και BGP να τρέχει ο server, θα πρέπει με κάποιο τρόπο να γίνεται monitor αν η υπηρεσία πέσει και να αποσύρεται κάπως το 10.0.0.1/32 .

Μπορούμε να έχουμε UDP απαντήσεις με πάνω από ένα πακέτο;

Τί σκέφτομαι: Η ερώτηση είναι αυτή που κινδυνεύει να χάσει το δρόμο της προς τον anycast DNS server όταν αλλάζει η δρομολόγηση, και αυτή είναι κατά κανόνα 1 πακέτο. Η απάντηση από τον DNS server θα βρίσκει πάντα το δρόμο της προς τον πελάτη. Αν μπορούσαμε να έχουμε single packet ερωτήσεις και multi packet απαντήσεις (connectionless πάντα), τότε λύνεται το πρόβλημα με το anycast.

----------


## trendy

Από κάτι snoopings που έχω δει ο dns-client στέλνει παραπάνω από μία ερωτήσεις προς τους dns-servers, επειδή ακριβώς είναι connectionless και θέλει να πάρει απάντηση.

----------


## Mick Flemm

Για το layer3 δεν υπάρχει ερώτηση και απάντηση, απλά UDP πακέτα, οπότε αυτό που λέτε για την δρομολόγηση είναι άσχετο, όσες πιθανότητες έχουν να χαθούν ερωτήσεις, το ίδιο συμβαίνει και με τις απαντήσεις (ακόμα κι αν είναι περισσότερα του ενός πακέτα αν έχει φύγει το route απ' τον table δεν έχει και πολύ σημασία). Σκέφτομαι πως ίσως θα μπορούσαμε να βάλουμε και το multicasting στο παιχνίδι αλλά θέλω λίγο χρόνο ακόμα να το δω. Προς το παρόν μπορούμε να κάνουμε μια καταγραφή των DNS servers με τις ζώνες τους και ποιοι είναι διαθέσιμοι να συμμετάσχουν στο πείραμα ???

----------


## paravoid

> Για το layer3 δεν υπάρχει ερώτηση και απάντηση, απλά UDP πακέτα, οπότε αυτό που λέτε για την δρομολόγηση είναι άσχετο, όσες πιθανότητες έχουν να χαθούν ερωτήσεις, το ίδιο συμβαίνει και με τις απαντήσεις (ακόμα κι αν είναι περισσότερα του ενός πακέτα αν έχει φύγει το route απ' τον table δεν έχει και πολύ σημασία). Σκέφτομαι πως ίσως θα μπορούσαμε να βάλουμε και το multicasting στο παιχνίδι αλλά θέλω λίγο χρόνο ακόμα να το δω. Προς το παρόν μπορούμε να κάνουμε μια καταγραφή των DNS servers με τις ζώνες τους και ποιοι είναι διαθέσιμοι να συμμετάσχουν στο πείραμα ???


Multicasting; Δεν έχεις ιδέα για τι πράγμα μιλάς, καμμία σχέση!

Το DNS έχει φτιαχτεί ώστε να αντέχει στο να χάνονται πακέτα. Δεν θα έχει κανένα πρόβλημα.

----------


## Mick Flemm

> Αρχική Δημοσίευση από Mick Flemm
> 
> Για το layer3 δεν υπάρχει ερώτηση και απάντηση, απλά UDP πακέτα, οπότε αυτό που λέτε για την δρομολόγηση είναι άσχετο, όσες πιθανότητες έχουν να χαθούν ερωτήσεις, το ίδιο συμβαίνει και με τις απαντήσεις (ακόμα κι αν είναι περισσότερα του ενός πακέτα αν έχει φύγει το route απ' τον table δεν έχει και πολύ σημασία). Σκέφτομαι πως ίσως θα μπορούσαμε να βάλουμε και το multicasting στο παιχνίδι αλλά θέλω λίγο χρόνο ακόμα να το δω. Προς το παρόν μπορούμε να κάνουμε μια καταγραφή των DNS servers με τις ζώνες τους και ποιοι είναι διαθέσιμοι να συμμετάσχουν στο πείραμα ???
> 
> 
> Multicasting; Δεν έχεις ιδέα για τι πράγμα μιλάς, καμμία σχέση!


Απαντάς απλά για να μου την πεις ως συνήθως ή ξέρεις τι έχω στο μυαλό μου ?  ::  

Έλεος ρε Φαίδωνα...

----------


## acoul

> Multicasting; Δεν έχεις ιδέα για τι πράγμα μιλάς, καμμία σχέση!


Πως φτάσαμε στο multicasting? φοβάμαι πως απλά έχεις όρεξη να παίξεις με το multicasting ή να δεις άλλους να παίζουν με αυτό όπως παλιότερα με το Xen. αυτό που προτείνεις δεν έχει να κάνει με υλοποίηση root DNS και απόδοση C-Class για το awmn που εδώ είναι και το ζητούμενο αλλά με το routing κλπ. το multicast το είχε ζητήσει και ο ysam παλιότερα για τους ίδιους λόγους πιστεύω. 

ένα απλό root DNS schema προσπαθούμε να συζητήσουμε και ένα καλύτερο και πιο αυτοματοποιημένο τρόπο διαχείρισης με το μικρότερο δυνατό διαχειριστικό κόστος για απόδοση C-Class σε Ax/Bx κόμβους που να δίνει την δυνατότητα στους τελευταίους να διαχειρίζονται και ανανεώνουν οι ίδιοι αυτόνομα αυτή την πληροφορία.

Εφόσον όπως δηλώνεις δεν έχεις διάθεση να μετέχεις σε κάποια υλοποίηση, προσωπικά το πιστεύω, μην κάνεις poison & distract με sexy ωρολογίες την πορεία της συζήτησης.

δεν είναι φλέημ, ζητώ συγνώμη αν βγήκε έτσι! Πάντως κάτι έχω βρει, αν σταματήσω το τρελό τρολάρισμα ίσως καταφέρω να ασχοληθώ λίγο κάποια στιγμή. θα βοηθούσε αν ο winner ή όποιος άλλος γνωρίζει είχε λίγο περισσότερη διάθεση να συνεργαστεί και να μας διαφωτίσει με το υπάρχον σχήμα! δεν είναι φυσικά απαραίτητο  ::

----------


## NetTraptor

Μλεξαμε το multicast, anycast, TCP, UDP και το DNS Hosting. Ολα καλα... αλλα ενα ενα... focus  ::

----------


## Vigor

Στο τέλος θα καταλήξουμε πως όλα καλά έχουν όπως είναι τώρα, και δεν χρειάζεται να αλλάξει κάτι.  ::

----------


## NetTraptor

> Από κάτι snoopings που έχω δει ο dns-client στέλνει παραπάνω από μία ερωτήσεις προς τους dns-servers, επειδή ακριβώς είναι connectionless και θέλει να πάρει απάντηση.


Ανάλογα το OS και ανάλογα τον Client. Γενικά πάντως ναι συμβαίνει αυτό. Επίσης υπάρχουν και διαφορές στο θέμα Primary to secondary DNS failover. Δεν είναι απαραίτητα roundrobin.

----------


## Acinonyx

> Για το layer3 δεν υπάρχει ερώτηση και απάντηση, απλά UDP πακέτα, οπότε αυτό που λέτε για την δρομολόγηση είναι άσχετο, όσες πιθανότητες έχουν να χαθούν ερωτήσεις, το ίδιο συμβαίνει και με τις απαντήσεις (ακόμα κι αν είναι περισσότερα του ενός πακέτα αν έχει φύγει το route απ' τον table δεν έχει και πολύ σημασία). Σκέφτομαι πως ίσως θα μπορούσαμε να βάλουμε και το multicasting στο παιχνίδι αλλά θέλω λίγο χρόνο ακόμα να το δω. Προς το παρόν μπορούμε να κάνουμε μια καταγραφή των DNS servers με τις ζώνες τους και ποιοι είναι διαθέσιμοι να συμμετάσχουν στο πείραμα ???



Διαφωνώ εντελώς!

Έχω την εντύπωση ότι δε μιλάμε για το ίδιο πράγμα. Το να χάνονται πακέτα λόγω αλλαγών στο BGP είναι δεδομένο είτε χρησιμοποιούμε unicast είτε anycast. Δεν είναι εκεί το πρόβλημα γιατί αν ήταν τότε ούτε το υπάρχον setup θα έπαιζε. Οπότε αυτό το βάζουμε στην άκρη.

Το πρόβλημα στο anycast συγκεκριμένα είναι ότι μπορεί να ξεκινήσεις να στέλνεις μία σειρά πακέτων π.χ UDP προς ένα 10.0.0.1 server και πριν ολοκληρωθεί να σου γυρίσει σε ένα άλλο 10.0.0.1. Επειδή ο προορισμός μπορεί να αλλάξει, είναι απαραίτητο να γίνει query με ένα UDP πακέτο. Για TCP δε το συζητάω, φαντάζεσαι τι θα γίνει. Η απάντηση όμως μπορεί να φτάσει με πολλά UDP πακέτα αφού ο προορισμός είναι προς ένα unicast c-class.

Αλλά ας τα ξεχάσουμε αυτά γιατί είναι θεωρίες. Στην πράξη τι μπορούμε να κάνουμε για το AWMN.

Όπως είπε ο paravoid παραπάνω, αρχικά πρέπει οπωσδήποτε να πετάξουμε όλα τα NS από τη ζώνη για να χωράνε οι απαντήσεις σε 512 bytes και να μη πλυμηρίζουμε με notifications. Αν ο master στέλνει notifications (also-notify) στους ψευτο-slaves νομίζω δε θα αλλάξει τίποτα και θα γίνονται xfrs κανονικά όπως πρώτα.

----------


## fengi1

> Στο τέλος θα καταλήξουμε πως όλα καλά έχουν όπως είναι τώρα, και δεν χρειάζεται να αλλάξει κάτι.


Εγω κατεληξα. 
Ολα μια χαρα ειναι και απλα πρεπει να μπει στο router Primary ενας κοντινος και αξιοπιστος και secontary o 10.19.143.12 ή 13.
Για την ωρα εχω primary 10.2.19.1.
Oσο για setup σε client παντα τους βαζω σαν dns τον router που συνδεονται , οποτε καθε αλλαγη που κανει ο κομβος την ακουν και αυτοι.
Σωστο ειναι ;
Το θεμα ειναι ποιοι απο τους dns που ειναι δηλωμενοι στις υπηρεσιες στο wind παιζουν ακομα  ::

----------


## NetTraptor

To θεμα με τα primary και secondary δεν ειναι απλο...δεν μπορεις να κανεις ping pong queries αναμεσα σε 2 server γιατι ετσι δεν τελειωνει ποτε το ping pong.. well sort of

ΠΧ. Να γιατί κάποιες φορές ακόμα και αν έχεις 2 DNS δηλωμένους .. παίρνεις ... αυτό που σου αξίζει...




> There are two types of DNS queries: recursive and iterative. When a DNS client requests DNS information, it uses a recursive query to do so. (And for the purposes of this discussion, a DNS client is any computer requesting DNS information, even if that computer happens to be running a server operating system.) In a recursive query, the DNS client sends its query to the first DNS server that it has been configured for in its TCP/IP configuration. It then sits and waits for the server to return an answer. If the server returns a positive response, the client will then go to the IP address returned by the server.
> 
> If it's a negative response, the client will return some sort of "Page/Resource not found" error to the user. One thing that's important to note here is that configuring multiple DNS servers on a client will not cause the client to check with subsequent servers if the first one returns a negative response. The only time a client will go to its secondary DNS server is if the first one is unavailable. If the first DNS server queried returns a negative response, the client will not try any secondary servers and will accept that negative response as final.


Για τα windows αυτο ισχυει... και περιπλεκεται λιγο με το dns client cache...

Μονο τα iterative queries περνανε και απο τους secondary. 

Think about it για λιγο...

----------


## Acinonyx

Οδηγίες υλοποίησης Anycast DNS -> https://www.awmn.net/wiki/index.php/Anycast_DNS

Λοιπόν, κάνω edit τη ζώνη awmn και 10.in-addr.arpa στο server μου και αφαιρώ τα περιττά NS. Οπότε μπορώ να πω ότι έτσι το 99% των queries εξυπηρετούνται με anycast. Το 1% που αφήνω είναι για πιθανές απάντησεις με πολλά A ή CNAME records. Μεχρi στιγμής όμως από ό,τι ξέρω δεν έχουμε κάτι τέτοιο σε αριθμό που να πλησιάζει τα 512 bytes.

Οπότε ας στήσουν και μερικοί ακόμη δηλώνοντας ως master τον 10.2.16.130 να αρχίσουμε να τους χρησιμοποιούμε να δούμε τι προβλήματα θα βγάλει..

Υ.Γ. @nettraptor, δες το τελευταίο σχόλιο στο wiki. Είναι ακριβώς για αυτό ακριβώς που λες.

----------


## NetTraptor

Καλο είναι το routing αυτού του μηχανήματος να είναι δυναμικό και όχι με static από τον router έτσι ώστε αν σκάσει το μηχάνημα να σταματήσουμε να ανακοινώνουμε το IP και να μην προσπαθούν όλοι να κάνουν resolve από εκεί. 
Αρα εγκαθηστουμε μια quagga στο μηχάνημα and off you go.

----------


## Mick Flemm

Πάντως για τα 512bytes υπάρχει λύση...
http://en.wikipedia.org/wiki/EDNS

@Acinonyx:
Δεν έχεις άδικο σε αυτό που λες ότι επειδή εσύ παραμένεις στη θέση σου, η απάντηση θα φτάσει σε εσένα κάποια στιγμή, το θέμα είναι ότι κατά πάσα πιθανότητα σε μια τέτοια περίπτωση θα φας timeout (θα κάνει μερικούς κύκλους μέχρι να σε φτάσει όσο αλλάζει δυναμικά η δρομολόγηση), οπότε δώρο άδωρο, άσε που αν πέσει ο DNS ή αλλάξει το routing είναι πολύ πιθανό η απάντηση να μη σταλεί καν. Απλά δεν πιστεύω ότι πρέπει να σκεφτόμαστε μόνο το πώς να φτάσουμε στον DNS (ακόμα κι αν αυτό είναι το όλο σκεπτικό με το anycast), πρέπει να δούμε και το ανάποδο το οποίο δεν πιστεύω ότι είναι τόσο προφανές. Διαφωνώ δηλαδή να θεωρείς τη μια διαδρομή ευκολότερη απ' την ανάποδη, όπως επίσης ότι ο αριθμός των πακέτων δεν είναι τόσο κρίσιμο (γιατί συνήθως φεύγουν ως bursts). Γενικότερα εμένα με απασχολεί περισσότερο το πόσο ευέλικτο θα είναι και πόσο γρήγορα θα αποκρίνεται το όλο setup, εκεί κολλάω.

Τεσπα, ας το δούμε στη πράξη και βλέπουμε στη συνέχεια τι θα προκύψει. Well done για το How To  ::

----------


## Mick Flemm

> Καλο είναι το routing αυτού του μηχανήματος να είναι δυναμικό και όχι με static από τον router έτσι ώστε αν σκάσει το μηχάνημα να σταματήσουμε να ανακοινώνουμε το IP και να μην προσπαθούν όλοι να κάνουν resolve από εκεί. 
> Αρα εγκαθηστουμε μια quagga στο μηχάνημα and off you go.


Static είναι απ' τον router στον DNS server (εκτός αν τα δύο αυτά ταυτίζονται οπότε μπορούμε να το κάνουμε και αλλιώς).

----------


## NetTraptor

bgp ospf whatever

----------


## Acinonyx

Χμ.. Έχω την εντύπωση πάντως ότι επειδή το prefix θα υπάρχει και από άλλα paths, το BGP convergence είναι πιθανό να είναι συντομότερο. Μία περίπτωση π.χ. όπου η μετάβαση από server σε server έχει πολύ μικρή διάρκεια είναι όταν υπάρχουν ήδη στο routing table του BGP πάνω από 1 path για το 10.0.0.1/32 με μη κοινά ASes. Όταν φύγει το best, θα επιλεγεί σχεδόν ακαριαία το επόμενο best το οποίο θα είναι λειτουργικό αφού χρησιμοποιεί άλλα links...

Πάντως, το πρόβλημα με το χρόνο που χρειάζεται για να ισορροπίσει το BGP μετά από αλλαγές δεν επηρεάζει μόνο το anycast. Ακόμη και σε unicast αν πέσει ένα link μεταξύ client και server θα χρειαστεί κάποιος χρόνος για να υπολογιστεί νέο path και να ενημερωθούν οι BGP router.

Θέλω να καταλήξω ότι ο χρόνος απόκρισης του setup δε θα είναι μεγαλύτερος από αυτό που έχουμε σήμερα. Αντιθέτως, σε κάποιες περιπτώσεις μπορεί να είναι και μικρότερος.

----------


## NetTraptor

Αν διαφημίζεις κάτι το οποίο έχει σκάσει από πίσω... ότι χρόνους να έχεις σε bgp κτλ ... Είναι σκασμένο... και επειδή το διαφημίζεις όλοι αυτοί που σε έχουν επιλέξει για κοντινό θα σε βρίσκουν σκασμένο. Έτσι αν έχουν μόνο εσένα δηλωμένο στο DNS δεν πρόκειται να παίξει resolution. 
Δεν ξέρω εχω κάπου λάθος?

----------


## Acinonyx

> Αν διαφημίζεις κάτι το οποίο έχει σκάσει από πίσω... ότι χρόνους να έχεις σε bgp κτλ ... Είναι σκασμένο... και επειδή το διαφημίζεις όλοι αυτοί που σε έχουν επιλέξει για κοντινό θα σε βρίσκουν σκασμένο. Έτσι αν έχουν μόνο εσένα δηλωμένο στο DNS δεν πρόκειται να παίξει resolution. 
> Δεν ξέρω εχω κάπου λάθος?


Στον mickflemm πήγαινε το post.  :: 

Ναι, δε διαφωνώ! Ας παίξουμε με quagga για να γίνει πιο σωστό. Θα προσαρμόσω τις οδηγίες αν είναι στο wiki. Απλά με static είναι πιο εύκολο το setup. Σε κοινά AS π.χ. θα γίνει αρκετά περίπλοκο γιατί θα πρέπει να τρέχουμε και IGP. Πιστεύετε ότι αξίζει τον κόπο όμως;

----------


## Mick Flemm

> Αρχική Δημοσίευση από paravoid
> 
> Multicasting; Δεν έχεις ιδέα για τι πράγμα μιλάς, καμμία σχέση!
> 
> 
> Πως φτάσαμε στο multicasting? φοβάμαι πως απλά έχεις όρεξη να παίξεις με το multicasting ή να δεις άλλους να παίζουν με αυτό όπως παλιότερα με το Xen. αυτό που προτείνεις δεν έχει να κάνει με υλοποίηση root DNS και απόδοση C-Class για το awmn που εδώ είναι και το ζητούμενο αλλά με το routing κλπ. το multicast το είχε ζητήσει και ο ysam παλιότερα για τους ίδιους λόγους πιστεύω. 
> 
> ένα απλό root DNS schema προσπαθούμε να συζητήσουμε και ένα καλύτερο και πιο αυτοματοποιημένο τρόπο διαχείρισης με το μικρότερο δυνατό διαχειριστικό κόστος για απόδοση C-Class σε Ax/Bx κόμβους που να δίνει την δυνατότητα στους τελευταίους να διαχειρίζονται και ανανεώνουν οι ίδιοι αυτόνομα αυτή την πληροφορία.
> 
> ...


Εγώ είπα ότι σκέφτομαι για multicasting, τον paravoid τι τον μπλέκεις ?  ::  Παιδιά μαζευτείτε με τα flames γιατί έτσι δε γίνεται δουλειά...  ::

----------


## Mick Flemm

> Χμ.. Έχω την εντύπωση πάντως ότι επειδή το prefix θα υπάρχει και από άλλα paths, το BGP convergence είναι πιθανό να είναι συντομότερο. Μία περίπτωση π.χ. όπου η μετάβαση από server σε server έχει πολύ μικρή διάρκεια είναι όταν υπάρχουν ήδη στο routing table του BGP πάνω από 1 path για το 10.0.0.1/32 με μη κοινά ASes. Όταν φύγει το best, θα επιλεγεί σχεδόν ακαριαία το επόμενο best το οποίο θα είναι λειτουργικό αφού χρησιμοποιεί άλλα links...
> 
> Πάντως, το πρόβλημα με το χρόνο που χρειάζεται για να ισορροπίσει το BGP μετά από αλλαγές δεν επηρεάζει μόνο το anycast. Ακόμη και σε unicast αν πέσει ένα link μεταξύ client και server θα χρειαστεί κάποιος χρόνος για να υπολογιστεί νέο path και να ενημερωθούν οι BGP router.
> 
> Θέλω να καταλήξω ότι ο χρόνος απόκρισης του setup δε θα είναι μεγαλύτερος από αυτό που έχουμε σήμερα. Αντιθέτως, σε κάποιες περιπτώσεις μπορεί να είναι και μικρότερος.


Εξαρτάται από το πλήθος των DNS servers και τη κατανομή τους στο δίκτυο κατά τη γνώμη μου. Και πάλι ως αρχή δεν έχεις άδικο, απλά έχω τις επιφυλάξεις μου. Όπως και να 'χει θα δείξει στη πράξη  ::

----------


## acoul

> Εγώ είπα ότι σκέφτομαι για multicasting, τον paravoid τι τον μπλέκεις ?  Παιδιά μαζευτείτε με τα flames γιατί έτσι δε γίνεται δουλειά...


άλς χάημερ

----------

