dns round robin

UNIX kezdő

Sziasztok!

Van a következő konfigom:
1 linux szerver
2 internet kapcsolat 2 isp-tol

Hosztolásra használom a szervert és azt szeretném hogy ha az egyik szolgáltató kiesik akkor menjen a másik. Az egyik vonalat backup-nak használom és csak akkor szeretném igénybe venni ha a másik kiesett. A kérdésem az lenne, hogy hogy oldom meg ezt dns szempontból? Ha pont az a szolgáltató esik ki amelyiken van a dns szerver konfigurálva, akkor mi történik?

  • 1674 megtekintés

( uid_16401 | 2010. 03. 03., sze – 21:24 )

Mi köze ennek a round robin -hoz?

Felveszed mindkét IP címmel a zónába? Egyébként meg a round robinnal sem leszel kisegítve, mert a dns szerverek közül pl. a bind egyszer az egyik IP-t fogja visszaadni, egyszer a másikat. Szóval a látogatók azt fogják látni, hogy egyszer megy, egyszer nem megy, megy, nem megy. Egészen addig, míg a másik netkapcsolatod helyre nem áll.
DNS szervert meg annyit teszel egy domain mögé, amennyi jól esik. .hu esetén a 2 független DNS minimális követelmény, de ettől több lehet. Nekem a leírtakból egyébként az sem világos, hogy akkor itt most 2 vagy 4 DNS-ről van szó és ezek hol is futnak. A szerveren és egy ahhoz tartozó ns2-n, az ISP-nél vagy hogy.

de persze olyan, elméletileg. és ha megáll a gépen a dns, akkor mi van? Ugrik a névfeloldásod, mert egy gépen van az egész és nem lesz ami feloldjon. akkor meg hiába a redundáns netkapcsolat, ha a végén nincs aki válaszol. ;)
Két külön dns fut, vagy fel van húzva a gépen mindkét IP és a dns szerver egy példányban fut és *-on hallgatózik?

Ha szigorúan vesszük a szabályzatot, akkor ez nem felel meg. Az más kérdés, hogy nem nagyon lehet kideríteni ezt.

Ha az a terved, hogy amíg az egyik vonal működik, addig a másik nem, csak backup, akkor viszont szabálytalan, mert a két dns szervert nagyjából egy pillanatban ellenőrzik le és mindkettőnek válaszolnia kell. Ha a másik vonalad épp pihizik, akkor ezen bukni fogsz.

Ok, kezd összeállni a kép.

A domainek regisztrálásakor meg kell adni két dns szervert (legalábbis .hu domain esetében.)
Ez esetben valóban lehet az, amit fent írtál, vagyis az ns1-nek az egyik, az ns2 pedig a másik IP cím van a zónákhoz rendelve.

A DNS round robinnak ehez semmi köze ehez.

Minden zónádhoz tartozik két NS rekord, az elsődleges dns szervere minden zónának pedig a SOA-ban megjelölt authorativ dns szervered lesz.
Ez idáig teljesen normális eset.

Az egyik IP-t kinevezed elsődlegesnek, és minden A rekordod arra mutat.
Ha az elsődleges IP megpusztul, egy scripttel átírod az A rekordokat a másik IP-re. (Ne felejtsd el a zónák serial-ját is updatelni.:) )

A TTL-t ne felejtsd el alacsonyan tartani, mert ha nem teszed az egész nem ér semmit, mert a cache DNS-ek ha egyszer benyalják a domainjeidhez tartozó rekordot, addig azt fogják visszaadni, amíg a TTL le nem jár, és hiába matatsz a szerveren, nem fog menni. Cache DNS-t meg szinte minden ISP használ, az ügyfeleik meg azokat használják.

Erre gondoltam én is, de ez elég szopó ág.

Ha módosul a konfig, akkor mindkét verziót módosítani kell, illetve a backup konfigban a zónákban magasabb serial érték kell hogy legyen.
Visszaálláskor pedig az eredeti konfigban is frissíteni kell a serial értékeket.

Gyakorlatilag így is kell zónafájlokat buherálni, csak éppen dupla annyit.

Elméletileg:
- alacsony TTL, mindkét szolgáltatónál multimaster DNS
vagy
Alacsony TTL, DNS harmadik szolgáltatónál

Gyakorlatilag:
- szopás a köbön.

szerk: dns round-robin nem kell, egy vonal kiesésekor módosítani kell a DNS zónákat.

Harmadik megoldás: saját IP tartomány, megfelelő eszközök, és szerződések, dinamikus routing.

( suckit | 2010. 03. 03., sze – 22:28 )

Ha a backup nem létszükséglet, és jó a round robin (ez van a címben is), akkor egyszerű, mint a Kiszel Tünde.
A gépeden felhúzod a két kapcsolatot, biztosítod a megfelelő routingot (ha A-n jön be, A-n válaszol, ugyanez B-vel), és indítasz két NS-t mindkét IP-n.
Az egyik NS-ben a géped nevéhez az A kapcsolat IP-jét írod 0 TTL-lel, a másikba a B kapcsolatét.

A gép nevét mindkét NS-re delegálod. Ha mindkét kapcsolat él, a forrás névszerver dönti el, hogy melyik felé küldi a klienst. Ha csak az egyik kapcsolat, a névfeloldás is csak az élő linken mehet.

Egy kis scripteléssel a backup témát is megoldhatod (csak akkor cserélsz B NS-ben konfigot a B-s IP-re, ha A link elsorvadt).

suckIT szopás minden nap! Solaris Itaniumon

Nem a kliens oldal lassú, hanem a szerver oldal van a szükségesnél jobban terhelve.
Ha sok a domain, és sokan látogatják a szervert, akkor kurvasok DNS kérésre kell a szervernek válaszolnia a 0 TTL miatt.
Nem azt mondom, hogy nem bírja, mert valószínűleg nem lesz gond vele, de már pár száz domain esetén jelentősebb lehet ez a terhelés.
A TTL-t pont azért találták ki, hogy legyen egy cache mechanizmus, és ne legyen annyi DNS kérés az authorativ szerverre.

Egyébként a megoldásod tetszik, csak az a 0 TTL b*ssza a szépérzékemet. :)

Csak, hogy tovább kötözködjek: 0 TTL esetén, ha bármi miatt áll a dns szervíz (pl. elcseszett konfigmódosítás miatt), attól a pillanattól kezdve nem érhető el semmilyen más szervíz sem kívülről, név alapján. :)

Dah, whatever... mint mondtam egyébként tetszik ez a megoldás, még jobb is mint amit én írtam.
Mostmár le lehet szálni rólam. :)

Ja, van egy C64-em, de a bind az istennek se akar lefordulni rajta. :(

( PunishR v | 2010. 03. 03., sze – 22:31 )

Ha a redundancia a cel es nem a terheles elosztasa akkor szerintem irsz egy scriptet ami nezi el e az elsodleges vonalad, ha nem el akkor egy nsupdate el frissited a domainek zonait /nem kell hozza bind restart semmi/ a backup vonal ipcimere. Persze ehez ajanlott mondjuk egy 60as ttl.