DNS въпрос

[qni]

Един въпрос към запознатитес днс техниките и магиите

Така ситуацията е следната:
Сървър за хостинг с два NIC-a съответно на всеки закачен по едно ISP. Пуснати са всякакви услуги свързани с хостинга.
Пуснат е днс ns.mydomain.com койт отговаря за всички хостинги, bind демона слуша на eth0 със съответното IP 10.10.10.1
Tака беше докато беше само един доставчик. Сега има вече втори и искам на eth1 със IP 10.10.10.3 за всички заявки да се грижи ns1.mydomain.com, който и трябва да конфигурирам.

Та въпроса ми е как точно ще стане това че вече много се омотах с тоя днс и или не мога да разбера или ми убягва просто начина.
Рутирането и балансинга през двете линии е оправено. Искам просто и ns.mydomain.com и ns1.mydomain.com да отговарят за едно и също. И ако единия нещо сгъне втория да се оправя с всички заявки. Имам предвид ако единия доставчик има проблем и остане втория ns1.mydomain.com да се грижи за всички заявки.
Втора инстанция на bind демона с отделни конф. файлове ли трябва да пусна да слуша на втория интерфейс, или просто трябва да донапиша нещо в зоновите файлове.
Четох за работа с изгледи но нещо не ми стана ясно дали ще мога да се оправя по тоя начин.
Мислех и да пробвам като донапиша в правата зона

NS ns.mydomain.com.
NS ns1.mydomain.com.

ns A 10.10.10.1
ns1 A 10.10.10.3

и съответно да си направя и един обратен резолв на 10.10.10.3 но не съм сигурен дали ще стане така, защото какво става като падне доставчика даващ ми IP 10.10.10.1 а зоновите файлове на всички хостове са написани да отговарят на него?
Знам че може да се реализира като едната линия остане бекъп и при срив /който се следи със някакъв скрипт който пуска пинг до gw примерно/ на първата да пуска втората като бърка в рутинг таблицата и рестартира bind демона с друг конфигурационен файл и с други зонове файлове. Обаче целтa и двете линии да си вървят постоянно.

Нека който има идеи да помага. Моята логика може и да е грешна, няма да се учудя след толкова изчетен матрял за тоя пуст BIND . Ако е така кажете ми, нищо чудно да съм тръгнал в грешна посока и да се опитвам прекалено сложно да го напрая.

Някакви неясноти ако има казвайте, или пък няккви файлове ако трябват да се гледат също казвайте. Мерси предварително на отзовалите се.

//edit
Забравих да спомена дистрибуцията е slackware-10.2 със bind-9.3.1

[MitkoS]

Вече два дена никой не иска да пише по тая тема.
Не съм разбирач, ама така да се каже, от моето писане тук, по-лошо няма да стане.

qni
от написаното много неща не стават ясни (говоря за мен конкретно)

От една страна се говори за ISP, което предполага, че това което се хоства е публично (видимо от Интернет). От друга страна съдейки по конфигурацията, оставам с впечатление, че това което се хоства е за вътрешни цели (видимо само от някаква частна мрежа зад или пред тоя сървър)

Нека предположим, че това което се хоства е публично. Ето аз сега си седя на моя компютър и искам да ползвам това което се хоства от твоя сървър (примерно). Т.е. аз правя DNS-заявка за <niakakvo_ime.mydomain.com>. Доколкото се досещам, тая заявка първо ще се обслужи от DNS-сървъра към който съм закачен. И ако при него няма нищо в DNS-кеша, то тая заявка ще стигне до публичния DNS-сървър за областта <.com>. И той ще отговори, че за <mydomain.com> отговаря някакво IP и заявката за <niakakvo_ime.mydomain.com> трябва да се дообслужи от това IP (DNS-сървър с това IP), като това IP има някакво съответствие с твоя eth0. Понеже на eth0 има вътрешен адрес, би трябвало това IP да е на тоя ISP на който е закачен eth0 и самия ISP да се грижи да прави прехвърлянето от това IP към eth0.
Работата е там, че DNS-сървъра за <.com>, няма как да знае, дали ти е паднал eth0 или eth1.

Има едно нещо, което се казва RIP
...
RIP routers can also communicate routing information through triggered updates. Triggered updates occur when the network topology changes and updated routing information is sent that reflects those changes. With triggered updates, the update is sent immediately rather than waiting for the next periodic announcement. For example, when a router detects a link or router failure, it updates its own routing table and sends updated routes. Each router that receives the triggered update modifies its own routing table and propagates the change.
...
Само че за да го ползваш, трябва да можеш да контролираш и двата ISP

[Ghost]

До момента, в който намесвеш Routing Information Protocol (RIP), всичко е вярно. Просто Domain Name System (DNS) и RIP нямат нищо общо. RIP се използва в Local Area Networks (LAN), докато DNS - в The Internet. RIP заедно с OSPF спадат към т.нар Interior Gateway Protocols и не се позлват в The Internet.
За същата цел (автоматично/динамично избиране на най-походящия маршрут за даден пакет) в The Internet се ползва Border Gateway Protocol, който е вид Extrernal Gateway Protocol.

Липсата на отговори си я обяснявам с това, че въпросът е зададен (поне за мен) много неясно . Аз лично не разбрах какво точно иска да постигне qni.

[MitkoS]

До момента, в който намесвеш Routing Information Protocol (RIP), ...

Много добре си го намесвам тоя RIP.
Хайде да си представим, че двата ISP са с общ "външен" канал с един рутер.
И IP-то, което връща DNS-сървъра за <.com>, така да се каже попада в адресното пространство, което се обслужва от тоя рутер

[etg]

qni, тия IP-та дето ги пишеш тука, действително ли са такива?
По отношение на конфигурацията на DNS-а този ред, дето си написал, е достатъчен, останалото е въпрос на loadbalancing/policyrouting, но ти пишеш, че с това си се преборил, така че не виждам какъв е проблема.

[etg]

Много добре си го намесвам тоя RIP.
Хайде да си представим, че двата ISP са с общ "външен" канал с един рутер.
И IP-то, което връща DNS-сървъра за <.com>, така да се каже попада в адресното пространство, което се обслужва от тоя рутер

Е да, остава да си представим, че двата доставчика са един, и проблемът е решен.

[MitkoS]

Е да, остава да си представим, че двата доставчика са един, и проблемът е решен.

Допреди няколко години, външните канали за България се брояха на пръстите на лявата ръка, а пък ISP-та - много, с лопата да ги ринеш. Формално различни, но практически еднакви по свързаност.

[etg]

То и сега не е много по-различно

[Ghost]

MitkoS, първо рутера за това е рутер - на един порт ще праща пакетите за адресното пространство на първия доставчик, на друг порт - пакетите за адресното пространство на втория доставчик. Ако имат едно и също адресно пространство...etg е отговорил ;-)
Второ, както писах по-горе, RIP не се ползва в The Internet. По технически причини. Един RIP пакет може да съдържа максимум 24 IP адреса. Представи си какъв флууд ще настане, ако се използва в The Internet. Просто RIP е измислен за и предвиден LAN, където има множество ВЪТРЕШНИ рутери. Това е. Не се ползва в Мрежата.
Ако не ми вярваш, ето ти RFC-то, чети: http://www.ietf.org/rfc/rfc1723.txt

[Ghost]

qni, ако приемем, че etg е разбрал правилно какво искаш да направиш и конфигурацията ти е правилна, тогава единствения проблем, за който се сещам е, че може да си забравил да пренасочиш пакетите за DNS query-та идващи отвън към 10.10.10.1:53 и 10.10.10.1:53.
Все пак това са адреси от десета клас "А" мрежа, която не се рутира в Интернет. Казано на жаргон "не са реални ИП-та".

[qni]

Здравейте,
извинявам се че не се включих толкова време, но бях се отказал да чакам отговор и се борих с проблема, който не успях да преборя
Първо да кажа че IP-тата са измислени и истинските са от различно адресно пространство, и че сървъра е публичен и не обслужва някаква вътрешна мрежа.

ето конф. файлове на главната зона и на една от хостваните, за малко повече яснота.

mydomain.com

$TTL 86400
@	IN	SOA	mydomain.com. root.mydomain.com. (
			200602155
			8H
			2H
			4W
			1D )

		NS 	ns.mydomain.com. 	
		MX 	10 mail.mydomain.com. 	


localhost 	A 	127.0.0.1

mydomain.com.	A 	10.10.10.1
ns		A	10.10.10.1
www 		A 	10.10.10.1
mail		A 	10.10.10.1

ftp		CNAME	mydomain.com.

host1.org

$TTL 86400
@	IN	SOA	mydomain.com. root.mydomain.com. (
			200602154
			8H
			2H
			4W
			1D )

host1.org.		NS 	ns.mydomain.com. 	

	
localhost.host1.org. 	A 	127.0.0.1
host1.org.		A 	10.10.10.1
ftp			A	10.10.10.1

www			CNAME	host1.org.

@MitkoS
всичко което си писал е така, и като се има предвид че dns-a има как да разбере кой ISP е паднал с някакъв скрипт както съм писал във въпроса си, аз искам като се разбере че има проблем с едната линия заявките да почнат да се обслужват през втората. Като идеята ми беше да не пренаписвам всички зонови файлове защото не са малко а по някаква друга схема да го направя. А за пренаписване говоря защото след като всички хостове са асоциирани с IP1 то при падане на доставчика това IP няма как да се достъпи. Със RIP не съм пробвал но малко ми е мътно там да си призная, трябва да почета първо.

@Ghost
Искам да постигна следното:
Да имам два напълно независими NS-a който да се грижат за домейните. При падане на единия заявките да се обслужват от другия. Нормална ситуация мисля, но въпроса е че аз исках да го реализирам на едно РС с два интерфейса, като имам два доставчика и IP-тa са от различно адресно пространство. И другото което ми се искаше е да не се налага да се пренаписват зоновите файлове, т.е. mydomain.com да е асоцииран с две различни IP-та, но ако може това да се опише в един зонов файл. Пробвах го не стана за жалост !??

@etg
тоя ред се оказа недостатъчен, аз също си мислех че ще стане но не стана. При падане на единия доставчик имам достъп до сървъра обаче само по IP, а като се опитам да отворя някой от хостваните адреси не става.
За сведение само двете линии наистина са от един доставчик едната е pppoe а другата наета линия, но втората е от мрежа която беше погълната от доставчика. Единия адрес е от 82.103.0.0 - 82.103.0.255 а другия от 212.50.0.0 - 212.50.0.255.
Та....
мерси на всички за отговорите. За момента се отказах да го правя по този начин. pppoe-то отпадна изцяло, втората линия ще е от БТК и ще е на друго РС. Като това друго РС като се наложи да се ползва нета през него ще се явява като рутер, а другото ще е зад него с някакъв частен адрес.
Все си мисля че има и по лесен начин, но не се сещам. Ако някои има идея за реализация от този тип нека да каже.

[MitkoS]

qni,
Това което съм писал за RIP, са глупости. Признал съм си вече че не съм разбирач, така че, простено ми е.

А сега да кажа какво мисля по твоя псевдо-проблем. С допълнителната информация която си дал е далеч по-лесно.
Ти всъщност искаш <niakakvo_ime.mydomain.com> да бъде разрешавано с две различни IP-та според това по кой интерфейс е дошла DNS-заявката за това име.

Вероятно логиката ти е такава:
"Някакъв клиент0 ползва ISP0 и е нормално да се предположи, че трафика му с моя сървър ще мине през ISP0, затова моя DNS-сървър трябва да отговори на неговата DNS-заявка за <niakakvo_ime.mydomain.com> с IP-адреса на eth0. Някакъв друг клиент1 ползва ISP1 и съответно е нормално да се предположи, че трафика му с моя сървър ще мине през ISP1, затова моя DNS-сървър трябва да отговори на неговата DNS-заявка за <niakakvo_ime.mydomain.com> с IP-адреса на eth1.
// Или ако падне eth0 (съответно eth1), то моя сървър да продължи да работи през eth1 (съответно през eth0)"

На пръв поглед разумно, но това е заблуда.
Защото DNS-заявките ВИНАГИ ще пристигат при теб само по единия интерфейс. Просто такъв е механизмът на работа на DNS. Всичко в случая тръгва от DNS-сървъра за <.com>. Ако случайно и по другия интерфейс вземе та дойде някоя DNS-заявка, то на тая заявка трябва да се отговори по същия начин (би трябвало да е така) (Не трябва да допускаш публичното <niakakvo_ime.mydomain.com> да бъде разрешавано по два различни начина с две различни IP-та). Това сигурно можеш да го направиш по-няколко различни начина. Аз лично щях да направя port-forwarding на eth1:53 към 127.0.0.1:53 или към eth0:53.

// Цитата е в подкрепа на думите ми, че DNS-заявките идват винаги и само по единия интерфейс. В случая е паднал този интерфейс който е известен на DNS-сървъра за <.com>

...
@etg
тоя ред се оказа недостатъчен, аз също си мислех че ще стане но не стана. При падане на единия доставчик имам достъп до сървъра обаче само по IP, а като се опитам да отворя някой от хостваните адреси не става.
...

Всъщност това което си намислил става за частни мрежи и непублични имена. Например централен офис и два регионални офиса, които са вързани с централния с някакъв VPN и два различни доставчика (примерно). Е, тогава може да се мисли за някакъв такъв вид оптимизация за непубличните имена.

[BAD_BOBIK]

Според мен решението на проблема е малко по просто :
1.Записите за DNS съвръите на domain.com би трябвало да са нещо от сорта : ns1.domain.com -> 10.10.10.1 ns2.domain.com -> 10.10.10.2
2. На втория итерфейс се вдига още едно копие на BIND и му се оказва, че е вторичен сървър за domain.com
3. Така при отпадане на първичния DNS би трябвало да работи без проблеми домейна.

Не гарантирам на 100 %, че е правилно но поне моята идея е такава .

[etg]

@BAD_BOBIK Разбрал си въпроса точно толкова, колкото и аз в началото, така че това не е решение.

Идеята (доколкото схващам) не е само да има работещ DNS при отпадане на някой от доставчиците, а и този DNS да дава различни отговори за хостваните домейни в зависимост от това през кой доставчик идва запитването, но това става ясно чак след допълнителните обяснения на qni.
Накратко - без втори DNS и най-вече без повторно описване на хостовете няма да стане, не знам за DNS, който да има вградено нещо от рода на regex, за да се автоматизират нещата. Особено пък ако входящият интерфейс е един от критериите за отговор.. Би могло да се ползва обаче нещо такова (sed, awk) за генериране на конфигурационните файлове за втория DNS, което да спести хамалогията.

[MitkoS]

Чак сега се сещам, че при регистрацията на домейна <mydomain.com> са посочени (поне) два DNS-сървъра. Което може да обърне обръща наопаки всичко което съм написал в предишния пост.

След кратка справка, установих, че при запитване на <.com>-DNS-сървъра за <niakakvo_ime.mydomain.com>, то в неговия отговор ще ги има IP-тата на всичките регистрирани при него DNS-сървъри за <mydomain.com> и е въпрос на софтуера при клиента към кой от тия сървъри да се обърне и как да постъпи, ако първия такъв не му отговори.