The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Настройка DNS сервера на базе пакета BIND с хранением зон в MySQL

14.12.2007 10:43

В статье "Setting up a BIND DLZ Nameserver with MySQL Replication" представлен пример настройки DNS сервера, распределенного для повышения надежности на несколько серверов, через хранение данных в MySQL с применением репликации данных.

Для хранения данных в БД используется патч bind-dlz, обеспечивающий поддержку БД Berkeley DB, PostgreSQL, MySQL ODBC (thus Firebird, DB2, Oracle, Sybase, SAPDB) или LDAP. Следует заметить, что при использовании bind-dlz сильно понижается производительность, по сравнению с оригинальным bind.

  1. Главная ссылка к новости (http://www.zazzybob.com/bind_d...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/13254-dns
Ключевые слова: dns, bind, domain, sql, replication, cluster
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (33) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, rxx_void (??), 11:08, 14/12/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    нуу и зачем оно нужно ? надёжность ?
     
     
  • 2.3, sauron (??), 11:19, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Для руления очень большими зонами. А то знаете BIND их в памяти хранит. Хотя лучше для этого заюзать PowerDNS. Он лучше с базами работает.
     
  • 2.4, GR (??), 11:34, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Например для хостингов, позволить через веб фигачить клиентам свои зонны. Вообще кашерней  в базе инфу хранить.
     

  • 1.2, amix (??), 11:18, 14/12/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    при большом кол-ве зон, на мощном железе можно уступить производительность в обмен на управляемость.
     
  • 1.5, dawnshade (?), 11:37, 14/12/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    кстати в FreeBSD 6.3-PRE уже из коробки этот функционал, не в курсе либо в 9,4 бинд это втянули, либо патчат руками.

    в любом случае, на хомяке авторов dlz данные о производительности неубедительны, хотя может уже поправили.

     
     
  • 2.6, reaper (??), 12:34, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >кстати в FreeBSD 6.3-PRE уже из коробки этот функционал, не в курсе
    >либо в 9,4 бинд это втянули, либо патчат руками.

    шо, серьезно? пошел обновляться :)

     

  • 1.7, vbv (ok), 13:36, 14/12/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На мой взгляд вещь без смыла :(
    rndc с ключами для руления ни кто не отменял.
    Память дешевая. Не могу представить размера базы, что бы надо было это хранить в СУБД.
     
     
  • 2.10, dawnshade (?), 14:25, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >На мой взгляд вещь без смыла :(
    >rndc с ключами для руления ни кто не отменял.
    >Память дешевая. Не могу представить размера базы, что бы надо было это
    >хранить в СУБД.

    а зря.
    mysql> select count(*) from records;
    +----------+
    | count(*) |
    +----------+
    |  5790753 |
    +----------+
    1 row in set (3 min 19.16 sec)

     
     
  • 3.11, dawnshade (?), 14:26, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >>хранить в СУБД.
    >
    >а зря.
    >mysql> select count(*) from records;
    >+----------+
    >| count(*) |
    >+----------+
    >|  5790753 |
    >+----------+
    >1 row in set (3 min 19.16 sec)

    а еще на этой базе ваш любимый rndc тупо валится по таймауту.

     
     
  • 4.31, vbv (ok), 14:27, 18/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >>mysql> select count(*) from records;
    >>+----------+
    >>| count(*) |
    >>+----------+
    >>|  5790753 |
    >>+----------+
    >>1 row in set (3 min 19.16 sec)
    >
    >а еще на этой базе ваш любимый rndc тупо валится по таймауту.
    >

    Если Вы ведете корневой DNS это другой разговор.
    Но иначе, если у Вас в зарегистрировано 5790753 записей в DNS, надо понять для чего такой номер может вообще понадобиться.
    Извините но представить вменяемую конфигурация для которой может понадобиться такое кол-во записей - мягко говоря сложно :(

     
     
  • 5.32, dawnshade (?), 14:33, 18/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Извините но представить вменяемую конфигурация для которой может понадобиться такое кол-во записей
    >- мягко говоря сложно :(

    развивайте воображение :)
    локальный RBL некрупного релея.

     
     
  • 6.33, vbv (ok), 15:15, 18/02/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Извините но представить вменяемую конфигурация для которой может понадобиться такое кол-во записей
    >>- мягко говоря сложно :(
    >
    >развивайте воображение :)
    >локальный RBL некрупного релея.

    Ну хорошо, если для локального - то зачем пихать это хозяйство в DNS....
    Есть более простые и более производительные способы. Как вариант складывать в файл и блокировать (выборка grep'ом):)

    Если же мы делаем открытый RBL там возможно такое и нужно,
    хотя если я делал бы - наверно выбрал другой путь (надо подумать но в базу пихать бы не стал).

    По поводу спама вообще - RBL для меня не применимо, и (мое личное мнение!) это баловство.
    т.к. машины к-е рассылают спам, как правило являются зараженными и т.о. в блокировку попадают целые организации.
    Мне лично по душе пришелся SPF работает достаточно надежно, да не все его сейчас поддерживают но я думаю это вопрос времени.
    И не мешало бы провайдерам всяких ADSL отказаться от прописывания реверсной зоны, а по RFC почтовик обязан иметь реверсную зону, как вариант проверять и это.
    А вот в случае больших пулов и возникают громадные базы адресов.

    А как только человек поймал вируса - его в топку, ну на мой взгляд это не совсем правильно. А если он вылечился. :)

    PS: Если делать по уму глупостей можно и избежать. (Это мое личное мнение не претендующее на истину в последней инстанции.)

     
  • 3.16, Аноним (-), 15:32, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    т.е. 3минуты 19секунд база лежала? :)
     
     
  • 4.17, dawnshade (?), 15:33, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >т.е. 3минуты 19секунд база лежала? :)

    это откуда вывод что mysql на select count(*) ложит базу??

     
     
  • 5.18, reaper (??), 16:08, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>т.е. 3минуты 19секунд база лежала? :)
    >
    >это откуда вывод что mysql на select count(*) ложит базу??

    от незнания

     
     
  • 6.23, Аноним (23), 18:53, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    count(*) по несчасным 5 лимонам строк шел ____ТРИ____ минуты! В топку мыскль!
     
  • 3.29, replicant (?), 13:19, 15/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Простите, а у вас mysql не на pentium 133 mhz 32 ram работает?

    select count(*) from tables;

    Запрос занял 0.0003 сек

    count(*)  
    23519676

     

  • 1.8, chip (ok), 13:36, 14/12/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >> представлен пример настройки DNS сервера, распределенного для повышения надежности на несколько серверов, через хранение данных в MySQL с применением репликации данных.

    Звучит достаточно идиотично в свете наличия в DNS своей AXFR/IXFR. bind в своей нише замечательно справляется с возложенными на него задачами, если требуется что-то большее то powerdns вполне подойдет.

     
  • 1.9, Николай (??), 14:05, 14/12/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ерунда полная
    Да, данные надо хранить в базе, и управлять ими в базе
    Но ещё и работать напрямую с базой - увольте
    Никакой секурности, надежности, и производительности.
    Может апачу сразу виртхосты из базы брать, и sshd в mysql лезть за паролем акка?
    У каждого приложения свой формат данных, обезспечивающий нужную функциональность и прозводительность, надо всего-навсего писать фильтры, который из данных в базе будут генерить конфиги для приложений.
     
     
  • 2.12, reaper (??), 14:29, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Может апачу сразу виртхосты из базы брать, и sshd в mysql лезть
    >за паролем акка?

    за этим к libnss-mysql :)

     
  • 2.25, GR (??), 20:18, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Ерунда полная
    >Да, данные надо хранить в базе, и управлять ими в базе
    >Но ещё и работать напрямую с базой - увольте
    >Никакой секурности, надежности, и производительности.

    Это вы разработчикам ldap скажите.

     
     
  • 3.27, fi (?), 21:11, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Это вы разработчикам ldap скажите.

    Не поверите, это они и говорят :) - не используйте SQL backend для праймори.

     
  • 2.28, GroundBeat (??), 21:30, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Ерунда полная
    >Да, данные надо хранить в базе, и управлять ими в базе
    >Но ещё и работать напрямую с базой - увольте
    >Никакой секурности, надежности, и производительности.
    >Может апачу сразу виртхосты из базы брать, и sshd в mysql лезть
    >за паролем акка?

    PAM хорошая штука, уважаемый, и тоже имеет право на жизнь.
    Не надо вешать ярлыки.
    Пока не нашли устраивающего всех баланса секурности, надёжности, производительности и удобства. Если бы не пидорги-параноики поломавшие SMTP, может он так Simple и остался бы всем на радость.

     

  • 1.13, Sampan (?), 14:31, 14/12/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Типичное юношеское увлечение. Чего только не хранят в mysql! Два десятка учетных записей, файл hosts, а теперь и зоны DNS.

    Бред это! База данных типа mysql прежде всего заточена под оптимальное обслуживание интенсивных запросов чтения - записи в равных пропорциях. У любого DNS сервера соотношение запросов чтения к транзакциям записи, наверное, 999 к 1. Именно по этому BIND хранит зоны в памяти, а обновляет их пинком rndc. Люди, писавшие сей патч - может они и программисты (в смысле, знают С), но это очень ГЛУПЫЕ программисты.

     
     
  • 2.14, dawnshade (?), 14:37, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Типичное юношеское увлечение. Чего только не хранят в mysql! Два десятка учетных
    >записей, файл hosts, а теперь и зоны DNS.
    >
    >Бред это! База данных типа mysql прежде всего заточена под оптимальное обслуживание
    >интенсивных запросов чтения - записи в равных пропорциях.

    Это кто вам такую глупость сказал?
    Покажите мне, например, где на http://dev.mysql.com/doc/refman/5.1/en/introduction.html это написано?

    для сравнения кэши запросов:

    Cache hitrate, 1, 5, 10 minute averages: 4.2%, 7.5%, 9.1%
    Backend query cache hitrate, 1, 5, 10 minute averages: 57%, 57%, 57%

     
  • 2.15, uldus (ok), 14:52, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Бред это! База данных типа mysql прежде всего заточена под оптимальное обслуживание
    >интенсивных запросов чтения - записи в равных пропорциях.

    MySQL как раз на чтение заточена и очень редкую запись :-) При интенсивной записи, табличные блокировки в MyISAM убивают производительность.

    Bind-dlz оправданная штука, только кэширования нормального не хватает, типа интегрированного memcached с возможностью задания таймаута для записей в базе.

     

  • 1.19, Аноним (23), 17:26, 14/12/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мне PowerDNS очень уж нравится, сейчас зона на 3000 записей - хавает 6 метров оперативы и не грузит камень.
    База юзается - sqlite...
     
  • 1.20, SunTech (?), 17:38, 14/12/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Можно бинд спрятать за кешируюищим сервером, чтобы основную нагрузку по отдаче воспринимал последний, а бинд будет просто из базы брать и отдавать при cache miss.
     
  • 1.21, SubGun (ok), 18:08, 14/12/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Честно говоря, с трудом себе представляю эту картину. Особенно если учитывать, что BIND грузится гораздо раньше MySQL.
     
     
  • 2.22, reaper (??), 18:12, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Честно говоря, с трудом себе представляю эту картину.

    а чего там представлять? поставь и посмотри в действии, благо времени отнимает немного

    >Особенно если учитывать, что
    >BIND грузится гораздо раньше MySQL.

    это тут каким боком?

     

  • 1.24, shutdown now (?), 18:58, 14/12/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    во фряшных портах этот патч давно
    использование вполне конкретное - для авторитетного сервера с кучей зон
    понятия первичный и вторичный неуместно, синхронизация зон происходит за счёт репликации mysql
    такой сервер очень удобно использовать с какой-либо хостинговой панелью, можно легко отдать контроль за доменом пользователю
     
     
  • 2.26, GR (??), 20:23, 14/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    +1

     
     
  • 3.30, Vladimir (??), 10:08, 20/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще хорошая штука но я так и не понял поддерживает ли он отсылку уведомлений об изменениях зоны другим серверам, на которых не стоит bind-dlz
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру