BIND: DNS rekord súlyozás

Linux-haladó

hello

Van két szerver jó távol egymástól és az egyik a másiknak failovere (standalone). Mind a két telephelyen különböző IP van az SMTP és Proxy szolgáltatás. Valahogy így
Telephely 1
1.1.1.1
Telephely 2
2.2.2.2

A kérdésem az hogy meglehet-e oldani BIND-ban hogy az A rekordokat valahogy súlyozza. Olyasmire gondolok mint az MX rekordnál de az ugye csak a bejövő levelekre van proxy címre nem jó valamint mail relay-nek sem az igazi.

Van erre valakinek vlami ötlete vagy ez így lehetetlen?

  • 6297 megtekintés

( janoszen v | 2014. 10. 16., cs – 12:39 )

Tudtommal alapvetoen nem. Az MX es SRV rekordoknak van sulyozasa, a tobbinek nincs. Ezt jellemzoen ugy oldja meg az ember, hogy csinal egy DNS failovert. Az persze mas kerdes, hogy ha sajat magad epitesz DNS szervert, az megbizhatobb lesz-e mint a telephelyeid.

--
Pásztor János
Üzemeltető Macik

+1
ha az adott szolgáltatás kliense támogatja az SRV rekordok használatát (pl sok SIP klienst teszi, de NEM mind) akkor mehet a menet.
Nyilván érdemes a pri DNS-t valami über biztos, mindíg elérhető helyre tenni (pl cloud)

( Huncraft v | 2014. 10. 16., cs – 13:45 )

Ezt igy nem.. Ha azt akarod, hogy automatikusan ataljon 1-1 lekeres egy masik DNS szerverre, akkor a legjobb az, ha multi-master zonet definialsz/konfigolsz fel, es hagyod hogy a kliens automatikusan ataljon a kovetkezo DNS szerverre, ha az elsodleges epp nem elerheto.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Jogos.. Valamiert ugy remlett mintha bind9 tudna, de most utanajarva valoban ugy nez ki, hogy csak hulye trukkozessel megoldhato a dolog, mert nativan nem tamogatja..
Alternativa lehet akkor esetleg egy master-slave felallas, es a klienseknel felvenni ezt a 2 DNS szervert
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

( kallaics | 2014. 10. 16., cs – 15:13 )

Én olyanról hallottam földrajzi alapon lehet ugyanarra a domainre eltérő fájlokat használni bind-dal. Más megoldást nem nagyon tudok.

A helyedbe azt csinálnám,hogy mindkét DNS szerver címét kiküldeném a kliensnek, ha egyik nem elérhető, akkor elérhető a másik talán.

( Fisher v | 2014. 10. 16., cs – 15:48 )

Nekem nem 100% hogy mit szeretnél. Amit érteni vélek:

- van két hálózat
- mindkét hálózatban gépek, pl. a proxy és kliensek
- a proxy címe az egyik hálózatban pl. 1.1.1.1 a másikban 2.2.2.2
- azt szeretnéd, hogy ha az egyik meghal, akkor a kliensek a másikra kapcsolódjanak

Ha tényleg ez van, akkor én ezt úgy csinálnám meg, hogy:

- szervizcím, pl. 3.3.3.3 (nyilván nem ez, de na)
- mindkét helyen lokálisan megvan a szervizcím, arra csatlakoznak a kliensek, a név arra oldódik fel (proxy.local.net -> 3.3.3.3)
- ha az egyik meghal, akkor azt az IP címet a másik hálózatba átirányítani

Vagy amit még szoktak:

- szervizcímek 10.1.1.2 és 10.1.2.1
- ha az egyik meghal, akkor ma másik felveszi azt a címet is
- route a másik hálózatba az adott címre

Ez az utolsó lépés elég sokféleképp oldható meg, erősen függ pl. a tűzfalak, routerek miegyebektől. De ez így egy viszonylag bevált megoldás.

igen, ezt szeretnem.
ezt a szerviz cimet hogy?

van A.local1.domain proxy 1.1.1.1 cimmel
van B.local2.domain proxy 2.2.2.2 cimmel

mint a ket szerver elerheto mind a ket helyrol de ertelemszeruen a kozelebbit kell hasznalni.

na most hogy mondod meg a bind-nak hogy ha
A.local1.domain (1.1.1.1) nem elerheto akkor B.local2.domain (2.2.2.2) szolgaljon. A kliens nem tudja ezt feloldani. Azt kene, hogy vlami round-robin fele listat valaszolni de mindig ugyan abban a sorrendben, ami ugye nem round-robin de ez meg mindig nem orvosolja az eredeti problemat, hogy ha az elso cim nem elerheto iranyitsa a masikhoz.

ehhez basszus a szervernek csekkolnia kene a szolgaltatast ami mar load-balanc kategoria.

de pill:
lehet igy:

local1.domain----------local2.domain
A 1.1.1.1-----------------A 2.2.2.2
B 2.2.2.2-----------------B 1.1.1.1

de a baj ezzel az h a kliensen csak egy FQDN lehet felvenni :(
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Én még mindig nem teljesen értem mit akarsz.
Ha jól értem van két domain és 2 különböző szerveren és egyikből nem tudod feloldani másikat.

Ha így van,akkor

A.local1.domain.lan gép megkérdezi a saját DNS szerverét,hogy ki az a B.local2.domain.lan, ahol a local2.domain.lan SUBDOMAIN forwardolva van a megfelelő szerverre vagyis a B.local2.domain.lan-ra.

A.PC ----> A DNS ---> DNS Forward to ---> B DNS

másik irányból ugyanez.

B.PC ----> B DNS ---> DNS Forward to ---> A DNS

és ugyanez a másik oldalról.

Jó lenne tudni mit csináltál (értsd móricka ábra a hálóról és ,hogy vannak-e DC-k a hálón esetleg) és remélem az 1.1.1.1 és a 2.2.2.2 nem valódi címek a hálózaton, mert azok bizony publikus címek!

A BIND nem játszik, azt már ahogy láttam többen írták, hogy erre a problémára nem fog megoldást nyújtani.

"ezt a szerviz cimet hogy?"
Hát hogy jó legyen. Konkrét OS nélkül nem tudok konkrét segítséget adni, de fel kell venni egy plusz címet, és a szolgáltatás(ok)nak figyelni kell rajta.

de a baj ezzel az h a kliensen csak egy FQDN lehet felvenni

Ez nem baj, mert van egy név, proxy.local.net (vagy az ami), ami feloldódik a szervizcímre, ami mindkét hálózatban egyezik. Ha az egyik szerver elpusztul, akkor a forgalmat át kell irányítani a másikra. Se a neve, se a címe nem fog változni, csak a routerekben/tűzfalakban a route vagy egyéb bejegyzés, attól függően, hogy pontosan milyen eszközeid vannak.

CentOS 6

most már érdekel hogy hogy van ez a szerviz rekord

szóval lehet az hogy a
xzy.local.net SRV mutat elsődlegesen 1.1.1.1 a másodlagos 2.2.2.2 TELEPHELY 1
xzy.local.net SRV mutat elsődlegesen 2.2.2.2 a másodlagos 1.1.1.1 TELEPHELY 2

de a kliens honnan tudja majd hogy a másodikat használd h ha az első lehalt?
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Nem lehet.
Mindkét szerveren az interfészre felveszel egy plusz IP címet:

http://geekpeek.net/ip-alias-centos-6/

Ez a címet meg vagy átdobod a másik hálózatba vagy nem, attól függ. Szimplán DNS-sel ezt nem lehet megoldani. Legalábbis nekem nem jut eszembe semmi hasznos. Meg úgy se nagyon, hogy neked vagy egy monitoring eszköznek ne kéne ezt-azt módosítani valami konfigban nyomor esetén.

Jó, lehetne mókolni a view-kal, de ennek utána kéne olvasnom, hogy pontosan hogy (meg hogy tényleg-e), de az se lenne sokkal-sokkal vidámabb.

Ehhez az kellene, hogy a ket telephely egymas alhaloira ralasson, ez pl. ipsec-cel megoldhato, bar a routerekkel elegge kell trukkozni, hogy a masik telephely alhalojabol vehess fel ip-t.

Gyakorlatilag egyszerubb lenne, ha a DNS-ek egyike a ket telephelytol fuggetlen helyen lenne, es mindket szervernek a slave-ja lenne.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

A hétvégén idegességemben kb. 25 perc volt, a leírással, tesztekkel együtt :D

Jó, persze ez azért, mert tesztkörnyezetet csináltam. meg úgy, ahogy nekem a legegyszerűbb volt. Ezért írtam a legeslegeslegeslegelején, hogy a helyi hálózat paramétereitől, lehetőségeitől függ. Elsősorban.

Pedig megfogadtam, hogy nem fogom helyetted megoldani a problémát.
Najó, akkor lássuk a medvét. Leszimuláltam az itthoni és a rabszolgatelepi hálózat felhasználásával a helyzetet(*). Mindkét hálózatban felvettem egy szervizcímet, a 10.10.10.10-eset: 

ip addr add 10.10.10.10/24 dev eth0 label eth0:1

A routeren felvettem egy ebbe a hálózatba lógó címet, hogy ne kelljen külön bohóckodni a routinggal: 

ip addr add 10.10.10.1/24 dev br0 label br0:1

Így a kliensek látják a 10.10.10.10-es címet:

http://kepfeltoltes.hu/141018/trace-ok_www.kepfeltoltes.hu_.png

Ha leveszem a szervizcímet, akkor persze pozor van: 

ip addr del 10.10.10.10/24 dev eth0 label eth0:1

http://kepfeltoltes.hu/141018/trace-jajj_www.kepfeltoltes.hu_.png

Egyszerűség kedvéért az OpenVPN szerver oldalán felvettem a push route-t: 

; test route remove any time
push "route 10.10.10.0  255.255.255.0"

LE KELL VENNI a - beteg oldali - routerről is az ebbe tartományba tartozó címet (vagy route-t, attól függ) ip addr del blabla.

restart mindkét oldalon, és lám:

http://kepfeltoltes.hu/141018/trace-hopp_www.kepfeltoltes.hu_.png

A lomha csomagokból tippelhető, hogy ez bizony átkocog a vpn-en.

Ezek után fel kell venni a 10.10.10.10-es címet a dns-be a vágyott néven és bajság esetén elvégezni a módosításokat.

A másik lehetőség az a bind view-k használata (ha nagyon ragaszkodsz a DNS alapú megoldáshoz), ami kb. annyiból áll, hogy lesz két (három) view. A két belsőben felveszed a szerver nevét a helyi címekkel, és attól függően hogy melyik címről kérdezik, a neki megfelelőt adod vissza (a harmadik view az lesz, amiben ez a cím nem szerepel, és mindenki más azt látja). Nyomor esetén át kell írni a még élő címre a nevet és kész, TTL-től függően átállnak a kliensek.

Az, hogy melyiket választod sok mindentől függ, pl. hogy milyen routerek, egyebek vannak, illetve mennyire férsz hozzá a bind konfigjához.

*) Amit remélem hogy jól értelmeztem.

( dzsambo | 2014. 10. 16., cs – 21:00 )

ezt 2 db különdböző képpen beállított .pac fájlal nem lenne egyszerűbben megoldható?

( Sea-you | 2014. 10. 17., p – 15:10 )

Bind views-zal masneven split-horizonnal meg tudod oldani

( szollosiimre | 2014. 10. 18., szo – 15:47 )

Felveszed a dns nevet egy vps,re aztán ráhúzol egy loadbalancert.

Most már komolyan nem értem.

Szerintem nála így van: 


Net1
gépek, szerver, proxy, smtp -> tűzfal -> net
Net2
gépek, szerver, proxy, smtp -> tűzfal -> net

Azaz az elosztani kívánt szolgáltatások a tűzfalak mögött vannak.
Lehet hogy nem kéne foglalkoznom olyan kérdésekkel, amik alapvetően értelmetlenek, és csak találgatni lehet hogy mire gondolt a költő...

köszönöm a fentebb leírt megoldás mind vpn-el, mind bind view-al.

a hálózat leírásod pontos. Egyébként én azt hittem hogy érthető voltam már az elején. De köszönöm a megoldást.
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/