Изпечатай

[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   . Ако е така кажете ми, нищо чудно да съм тръгнал в грешна посока и да се опитвам прекалено сложно да го напрая.

Някакви неясноти ако има казвайте, или пък някaкви файлове ако трябват да се гледат също казвайте. Мерси предварително на отзовалите се.
Дистрибуцията е slackware-10.2 със  bind-9.3.1, IP адресите са измислени .

ето конф. файлове на главната зона и на една от хостваните.

mydomain.com

Примерен код

$TTL 86400 @   IN   SOA   mydomain.com. root.mydomain.com. (          199802155          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. (          199802154          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.

Цитат (qni @ Сеп. 01 2006,10:39)

Здрасти !
Ако правилно съм разбрал, ако укажеш на демона да слуша и на двата интерфейса, като прави и обратни зони при доставчиците са препратени към теб, ще си решиш проблема.
Добра идея е в отделните файлове за зоните, да пишеш като сириен номер текуща година: например 2006090101, а не да оставяш старите от 1999.
Успех !

Не е ли listen-on това, което ти трябва?

С него ще пуснеш демона да слуша на двата интерфейса, съответно ще си описал двата адреса като NS записи и мисля че схемата ще стане.

Само нещо малко ме притесняват тия адреси - 10.10.10.1, 10.10.10.3...

[Bogo]

Той bind така или иначе ще си слуша и на двата интерфейса. Искаш да кажеш на регистрара че имаш два нейм сървъра? И това да рабити така.

пп: Анестава ли така?
ns1 CNAME ns

[VladSun]

NS записите не трябваше ли НИКОГА да не са CNAME ?

[toxigen]

Здравей,

BIND ще слуша по подразбиране на всички интерфейси, освен ако не си му казал друго.
За да отговаря и на втория адрес, най-първото нещо, което трябва да направиш е да регистрираш адреса и съответното име (10.10.10.3 в твоя хипотетичен случай, и съответстващото име ns1.mydomain.com) като DNS сървъри за домейна mydomain.com. Това става при регистратора, при който си регистрирал домейна. От тук нататък във всички регистрирани домейни, които се обслужват от ns.mydomain.com, трябва да добавиш втори NS запис (според RFC трябва винаги да имаш поне два), сочещ към ns1.mydomain.com. Последното отново става през регистратора - не от зоновия файл на самия домейн (който ти така или иначе имаш, но ако промениш само него root dns сървърите никога няма да върнат, че и ns1.mydomain.com е name сървър за съответния домейн, когато ns.mydomain.com е down по някаква причина - провайдер например).
P.S. Понеже предусещам, че отново съм се изразил не достатъчно ясно - ако нещо не ти е ясно не се притеснявай да питаш, и то не на ЛС, а тук, за да може и друг да види ако му трябва.
Е такива объркани изречения не бях писал от доста време.
Със здраве!

[gat3way]

Не мисля, че това което правиш е разумно..
Имаш ТТЛ за зоната доста голямо време...което ще рече че толкова време един клиент, който е резолв-нал вече хост-а, ще си го пази в днс кеша и няма да ти допитва днс сървъра.

Което означава, че такъв клиент при падане на едната ти линия все пак ще търси хоста на стария адрес, който вече е кеширан при него. И като не го намери, няма да се свърже с него.

Като изход от тази ситуация, предлагам следното: много нисък ТТЛ. 2 authoritative сървъра - съответно на двете айпита на двата интерфейса. 2 instances на bind, слухтящи съответно на единия и другия интерфейс, със съответните зонови файлове съобразени с адресите на интерфейсите им.

Като резултат, при падане на единия интерфейс, проблемите ще бъдат сведени до минимум...с едно огромно "НО":

Предполагам имаш apache. Ако имаш vhosts, би следвало да знаеш, че няма да сработят автоматично при падане на единия интерфейс. Апача прави един път резолвинг на всеки виртуален хост в конфигурацията си по време на стартиране и повече не се грижи за това. Тоест, ако по време на работа адреса на един виртуален хост (A record-a) бъде сменен, то апач-а няма да знае за това, съответно ще си имаш грижи. За това, трябва да се напише и един скрипт, който се изпълнява всяка минута в крон-а и проверява дали не е паднал интерфейс-а. Ако е паднал, тогава се прави един reload на апач-а, за да си нямаш грижи с виртуалните хостове.

За други "уточнения" не мога да се сетя в момента..

[toxigen]

Относно Apache:
Дали за vhost не гледа параметъра Host: от HTTP 1.1 заявката - ако е така мисля, че проблем няма. Общо взето така като мисля виртуалните хостове в apache не би трябвало да се резолват въобще - нали ги използваме основно за да може сървъра да обслужва повече домейни и поддомейни от един и същи адрес. Ако бъркам някой да ме поправи моля.

[Hapkoc]

Бъркаш, бъркаш :)

Естествено, че трябва да се resolv-ват, нали все пак като напишеш google.com трябва отнякъде да се разбере към кой IP адрес да се прати заявката.

Въпроса е такъв - няма проблем да се сложи apache-а да слуша и на двата IP адреса и да се конфигурират Name-based virtual hosts (т.е. да се определя за кой сайт е заявката по Host header-а). Проблема е точно в resolv-а. Когато си конфигурирал в DNS-а единия адрес и линията към съответния доставчик падне трябва да се смени DNS записа, за да може клиентите да започнат да го търсят на другия адрес.

gat3way, не мисля, че си прав относно apache, именно ако се ползват Name-based virtual hosts. В този случай apache може да си слуша на двата интерфейса.

[toxigen]

Какво пречи да регистрираш първичен и вторичен DNS? Защо трябва да сменям записи? Две инстанции на BIND или още по-лесно - една инстанция с конфигурирани views. По едно view за заявки идващи на всеки интерфейс - едното връща записите с адресите от пространството на първия провайдер, другото с адресите на втория. Ако при регистрацията на домейна всичко е направено както трябва при отдпадане на първия DNS (т.е. мрежата на първия провайдер) всеки юзър на земята ще пита втория DNS, който ще му връща адресите, асоциирани с втория интерфейс. Относно apache -- то web сървър и въобще не се сещам за какво би му потрябвало да резолва google.com или каквото и да е друго, особено ако изрично му кажеш да се закачи на двата интерфейса. Обикновено клиента, който иска да види съдържанието, предоставяно от apache прави резолвинга и след това връзка към адреса. От host хедъра се разбира кой virtual host ще отговори. Apacheto въобще не го интересува на какъв адрес отговаря реално всеки vhost -- това е работа на DNS.

[Hapkoc]

Цитат

Ако при регистрацията на домейна всичко е направено както трябва при отдпадане на първия DNS (т.е. мрежата на първия провайдер) всеки юзър на земята ще пита втория DNS, който ще му връща адресите, асоциирани с втория интерфейс.

Тук не си съвсем прав. Ако имаш два NS записа за дадения домейн, клиентите винаги ще питат и двата DNS сървъра (смисъл не едновременно всеки клиент да пита и двата, а ще се редуват общо взето). Ето:

Цитат

$ host -t ns abv.bg abv.bg name server ns.netinfo.bg. abv.bg name server ns2.mobikom.com. abv.bg name server ns.mobikom.com. $ host -t ns abv.bg abv.bg name server ns.mobikom.com. abv.bg name server ns.netinfo.bg. abv.bg name server ns2.mobikom.com.

Цитат

Apacheto въобще не го интересува на какъв адрес отговаря реално всеки vhost -- това е работа на DNS.

Само в случай на name-based virtual hosts. Ако са IP-based се използва именно адреса, към който е пратена заявката за да се определи към кой хост е тя. Това обаче не е от особено значение, т.к. в случая май няма проблем да се ползват name-based vhosts.

За останалите неща съм абсолютно съгласен. Схемата, която предлагаш комай ще сработи, но май пак със забележката на gat3way, че TTL е добре да е с някаква ниска стойност.

А относно resolving-а и google.com - явно нещо съм разбрал какво имаш предвид точно. :)

[gat3way]

Не съм казал че трябва да има няколко апача или че не могат да слухтят на няколко интерфейса, това се отнасяше за bind и за това че трябва да се връща различна информация в зависимост от това към кой интерфейс идва DNS запитването. Малко тъпо би било да ти дойде запитване за А записа на домейна и да му върнеш айпи адреса на другия интерфейс, който  в момента е паднал....и така.

Но всъщност, не се замислих че има views в bind, откъдето може и да се реши проблема без пускането на 2 копия на демона с различни зонови файлове. Обаче не съм много запознат с тези нововъведения де, който им разбира повече да си каже..

[Hapkoc]

Еми става с views. Зоновите файлове пак са си различни и source и destination адреса на DNS заявката се определя кой изглед ще я обслужи.

[toxigen]

За views имаше май хубава статия тук - лесно става.
@Hapkoc: За DNS-те си прав - всеки, който иска NS запис му се връщат всички (последователност в подреждането изглеждя няма) NS-и за домейна. Проблем ще се окаже, когато юзъра се опита да докопа този, който е долу в момента (понеже му е върнат той като запис), но пък от друга страна ако използва културен браузър (например) би трябвало да се допита и до втория NS.
Относно apache - именно name based virtual hosts съм имал предвид във всички постове по-нагоре.

*PS: Сега видях статията къде е:
Работа с изгледи в BIND
Кажете голямо благодаря на колегата Hapkoc за документа.

[growchie]

Пачвайте bind-а. Инфото е Gentoo specific ама сигурно ще се отнася и за други дистрибуции.

Цитат

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Gentoo Linux Security Advisory                           GLSA 200609-11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -                                             http://security.gentoo.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -   Severity: Normal      Title: BIND: Denial of Service       Date: September 15, 2006       Bugs: #146486         ID: 200609-11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Synopsis ======== ISC BIND contains two vulnerabilities allowing a Denial of Service under certain conditions. Background ========== ISC BIND is the Internet Systems Consortium implementation of the Domain Name System (DNS) protocol. Affected packages =================     -------------------------------------------------------------------      Package       /  Vulnerable  /                         Unaffected     -------------------------------------------------------------------   1  net-dns/bind     < 9.3.2-r4                           >= 9.3.2-r4                                                           *>= 9.2.6-r4 Description =========== Queries for SIG records will cause an assertion error if more than one SIG RRset is returned. Additionally, an INSIST failure can be triggered by sending multiple recursive queries if the response to the query arrives after all the clients looking for the response have left the recursion queue. Impact ====== An attacker having access to a recursive server can crash the server by querying the SIG records where there are multiple SIG RRsets, or by sending many recursive queries in a short time. The exposure can be lowered by restricting the clients that can ask for recursion. An attacker can also crash an authoritative server serving a DNSSEC zone in which there are multiple SIG RRsets. Workaround ========== There are no known workarounds at this time. Resolution ========== All BIND 9.3 users should update to the latest version:     # emerge --sync     # emerge --ask --oneshot --verbose ">=net-dns/bind-9.3.2-r4" All BIND 9.2 users should update to the latest version:     # emerge --sync     # emerge --ask --oneshot --verbose ">=net-dns/bind-9.2.6-r4" References ==========   [ 1 ] CVE-2006-4095         http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4095   [ 2 ] CVE-2006-4096         http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4096 Availability ============ This GLSA and any updates to it are available for viewing at the Gentoo Security Website:   http://security.gentoo.org/glsa/glsa-200609-11.xml Concerns? ========= Security is a primary focus of Gentoo Linux and ensuring the confidentiality and security of our users machines is of utmost importance to us. Any security concerns should be addressed to security@gentoo.org or alternatively, you may file a bug at http://bugs.gentoo.org. License ======= Copyright 2006 Gentoo Foundation, Inc; referenced text belongs to its owner(s). The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license. [URL=http://creativecommons.org/licenses/by-sa/2.5

Получи се в 11:24 БГ време.