» Кеширующий DNS сервер для локальной сети на основе BIND 9

смотрю Вы далеко не ... поэтому о нагрузке в канале поймёте.

в этом я разобрался. Только (у меня squid) написано везде разноречиво. Одни пишут что ДНС запросы кеширует другие нет, также насчёт FTP запросов. Вот отсюда у меня и возникла идея создать связку кешируещего ДНС сервера + кешируйщий прокси сервер.

дык блин целые статьи пишут по поводу именно кешируещего нейм сервера. Делят на две части 1.кешируйщий ДНС сервер. 2.Собственый домен. Проверил да оть 1000 доменов создавай всёравно он запросы кеширует. Дык зачем людей в оману вводить.
Написали бы одну статью и не разделяли на две.

Всё высказался.
Если хочеш пообщаться 317410068-ICQ по поводу всего этого стучись, чтоб флейм не разводить.
И прошу прощения за свои блины.

Цитата:

Вы если  блин такие умные дак раскажите плиз как можно обьединить на клиентах работу Кеширующего прокси с портом 3128 и Кеширующего ДНС с портом 53 и ЙП одинаковым.

В resolv.conf прописать:
127.0.0.1

Все классно, но есть вопрос.
Ставил я все это дело на FreeBSD 5.2.1-RELEASE-p11.
после установки нового пользователя "bind" или "named" я не обнаружил.
Работать о работает, но только если запустить его под рутом, а из /etc/rc.d он почему-то не запускается
Подскажите пожалуйста, что нужно сделать, чтобы он стартовал при запуске системы и желательно не с правами рута.
Заранее спасибо.

Дак создай пользователя неймед.
После установки он автоматически не создаёться

И он сразу же начнет запускатся из /etc/rc.d?

Люди, помогите с запуском named!!!
При старте системы, named не стартует,
когда запускаю /etc/rc.d/named start
выдает :
Usage: named [-d #] [-q] [-r] [-v] [-f] [-p port] [[-b|-c] configfile]
[-u (username|uid)] [-g (groupname|gid)]
[-t directory]

Пришлось переустановить мир и с ним преждний bind, кстати в FreeBSD 5.2.1 он таки 8.Х

Люди, помогите с запуском named!!! [q][/q]

Попробуй в /etc/rc.conf
строчку named_flags="-u bind"
вместо той что у тебя сейчас..

У меня там всего одна строчка:

named_enable="YES"

Спасибо, это помогло

SimbioS

Цитата:

А так: в свойствах сети вписываем ЙП ДНС сервера., а в свойсвах IE выбрать "автоматическое определение настроек" это на тот случай если клиенты ходят через допустим прокси-сервер.
Теперь понятно о чём я говорил.

прежде чем что-то говорить надо сначала подумать, то ты доказывал что ДНС прописывается в броузере, теперь что автоматические настройки нужны ...
ДНС прямого отношения к приложению не имеет. Это разные уровни модели ОСИ.

Спасибо за статью.

Все поднял, все работает, но есть один глюк: некоторые mx записи разрешаются неправильно. Например - без кэширующего DNS:

Non-authoritative answer:
gh.ru nameserver = ns2.den.ru
gh.ru nameserver = ve.nu

Authoritative answers can be found from:
gh.ru nameserver = ns2.den.ru
gh.ru nameserver = ve.nu
ns2.den.ru internet address = 194.186.94.183
ve.nu internet address = 193.124.133.188

с кэширующим сервером:

Non-authoritative answer:
Name: gh.ru
Address: 194.186.94.11
gh.ru nameserver = ns2.den.ru.
gh.ru nameserver = ve.nu.
gh.ru mail exchanger = 1 192.168.0.222.

Authoritative answers can be found from:
gh.ru nameserver = ns2.den.ru.
gh.ru nameserver = ve.nu.
ve.nu internet address = 193.124.133.188
ns2.den.ru internet address = 194.186.94.183

Соответственно, почта никуда не уходит, т.к. по адресу 192.168.0.222 никакого почтаря нет.

Подскажите - что и как лечить?

Yoshi_Stan
что значит
Цитата:

некоторые mx записи

? в примере я нашел только одну... а снаружи - там вообще MX нету
и вообще... конфиг для зоны gh.ru в студию...

Так нету конфига для зоны gh - у меня поднят простой кэширующий сервер, настроен согласно рекомендаций в исходной статье, ну, с учетом того что у меня rh9, а не bsd.

Никаких специфических настроек нет.

Yoshi_Stan
но 192.168.0.222 он ведь от куда-то взял???? то есть где-то на локальном сервере это прописано...
К тому же наверняка с ошибкой, MX запись дается хосту, а не айпишнику...

Откуда-то взял. Но, как я уже сказал, настройки у меня стандартные, и никаких дополнительных зон не прописано.

И, кстати:

> set q=any
> server ve.nu
Default server: ve.nu
Address: 193.124.133.188#53
> gh.ru
Server: ve.nu
Address: 193.124.133.188#53

Name: gh.ru
Address: 194.186.94.11
gh.ru mail exchanger = 1 192.168.0.222.
gh.ru nameserver = ve.nu.
gh.ru nameserver = ns2.den.ru.
gh.ru
origin = ve.nu
mail addr = hostmaster.gledenov.ru
serial = 2003121810
refresh = 10800
retry = 3600
expire = 3600000
minimum = 86400

Т.е. на самом ve.nu какие-то проблемы?

Yoshi_Stan

Цитата:

Т.е. на самом ve.nu какие-то проблемы?

Да, причем большие :))) он сейчас вообще зону gh.ru не знает :))

а с другого сервера:

Код: > gh.ru
Server: ns2.den.ru
Address: 194.186.94.183

Non-authoritative answer:
gh.ru internet address = 194.186.94.11
gh.ru MX preference = 1, mail exchanger = 192.168.0.222
gh.ru nameserver = ns2.den.ru
gh.ru nameserver = ve.nu

Надеюсь меня простят за то что подниму все же тему песочницы в BIND 9.
В BIND 9 изменились некоторые параметры командной строки например
-g это уже не задание группы, а запуск сервера имен не как демона, а как обычную программу с выводом всех сообщений на экран (что очень удобно при отладке).
Поэтому старая команда из BIND 8 в BIND 9 уже выдаст сообщение об ошибке.

Моя командная строка BIND 8, задаваемая в rc.conf параметром

named_flags="-u bind -g bind -t /etc/namedb/s /etc/namedb/s/named.conf"

в BIND 9 долго отказывалась работать.

после того как пришлось убрать опцию "-g bind" BIND 9 удалось запустиь в командной строке в следующем виде

named -u bind -t /etc/namedb/s -с /etc/namedb/s/named.conf

а вот при загрузке самой FreBSD 5.3 грузиться с этой коммандной строкой (заданой в rc.conf опцией named_flags )категорически отказывался.
Опция -с /etc/namedb/s/named.conf просто игнорировалась

запустилось все это только со следующими строчками в rc.conf

named_enable="YES"
named_flags="-u bind -t /etc/namedb/s"

и переписыванием файла named.conf из /etc/namedb/s/ в /etc/namedb/ естественно относительно песочницы.

Можно ли настроить сервер Bind и как первичный для домена локалки и как кеширующий, я пытался настроить вроде как домен внутри локалки работает
но с кеширование и вообще резолвингом внешних доменов какие то постоянные проблемы, хосты резолвятся не с первого раза, а раза с третьего.
Сервер DNS стоит в локалке за NAT мож в этом какие проблемы? хотя с машины на которой NAT все вроде как работает нормально.

pANK

Цитата:

хосты резолвятся не с первого раза, а раза с третьего

Как это проявляется?
Может проблемы именно с сетью? с маршрутизацией?
У меня в локалке два сервака стоит один за натом второй на реальном IP, так вот на обоих есть записи и master и slave. Так что - возможно всё ;)

ну так зайди на днс свой и дай запрос на какой-нибудь домен , которого точно нет в кеше.

$ dig gu.net @127.0.0.1 soa

например

вот и посмотри что будет

Система построена таким образом, стоит линукс внутри локалки с DNS сервером,
стоит NAT на шлюзе, так же в этом нате настроено все запросы по порту UDP 53 переправлять на DNS провайдера. В конфиге DNS указано
auth-nxdomain no; # conform to RFC1035
forward first;
forwarders {
192.168.1.96;
};
может надо было указать DNS прова? а не NAT шлюз который только перенаправляет запросы на DNS прова?
а вообще получаю такой ответ
gw1:/home/pank# dig opsb.ru @127.0.0.1 soa

; <<>> DiG 9.2.4 <<>> opsb.ru @127.0.0.1 soa
;; global options: printcmd
;; connection timed out; no servers could be reached
если несколько раз пингануть хост то все окей, иначе так и не отвечает.

Да у меня попутно ещё возник вопрос, кеширование происходит только в памяти?
то есть переодически оно теряется? а нельзя ли использовать для этого какой то файл? или может MySQL ?

Зачем народ так хочет кэш сохранить? Ведь TTL у многих зон - час, два. После этого - уже устаревание происходит - и надо выкинуть эти данные из кэша. Для чего писать это в файл или есчо куда-то? Что бы поиметь проблемы с резольвингом?

BigHarry

Цитата:

Зачем народ так хочет кэш сохранить? Ведь TTL у многих зон - час, два.

а ттл у многих зон - сутки, и рекомендовано сутки. Это у ненормальных час. Смысла нет , а поток будет хороший создаваться.


Цитата:

После этого - уже устаревание происходит - и надо выкинуть эти данные из кэша

а затем , что кеш не просто так обновляется, а бинд смотрит на нс-ы по хоне и сравнивает сериал, если сериал не обновился - значит и обновлять нечего


Цитата:

Для чего писать это в файл или есчо куда-то? Что бы поиметь проблемы с резольвингом?

pANK

Цитата:

Да у меня попутно ещё возник вопрос, кеширование происходит только в памяти?
то есть переодически оно теряется? а нельзя ли использовать для этого какой то файл? или может MySQL ?

кеш сохраняется до тех пор, пока бинд не рестартуешь.

Цитата:

а нельзя ли использовать для этого какой то файл? или может MySQL ?

а какая разница в чем он его хранит ? у него своя какая-то база.

Можно попробовать так кэш сохранить после рестарта:
rndc dump (он скинет кэш в файл db.cache)

В конфиге:
zone "." in {
type hint;
file "db.cache";
};

Может - и получится...

Статья отличная, как новичок все быстро настроил, все работает ок. Но когда начал проверять зоны с dnsreport.com он мне все время выкидывал только одно предупреждение:
Your domain does not have an SPF record. This means that spammers can easily send out E-mail that looks like it came from your domain, which can make your domain look bad (if the recipient thinks you really sent it), and can cost you money (when people complain to you, rather than the spammer). You may want to add an SPF record ASAP, as 01 Oct 2004 was the target date for domains to have SPF records in place (Hotmail, for example, started checking SPF records on 01 Oct 2004).

Что это вообще такое и где можно почитать как настроить это все, желательно на русском, или объясните плз.

pANK

Цитата:

Да у меня попутно ещё возник вопрос, кеширование происходит только в памяти?
то есть переодически оно теряется? а нельзя ли использовать для этого какой то файл? или может MySQL ?

Чтобы хранить кэш в файле, нужны права на запись в этот файл, а зачем открывать потенциальную лазейку для хакера?

Цитата:

начал проверять зоны с dnsreport.com он мне все время выкидывал только одно предупреждение:
Your domain does not have an SPF record.

Это не ошибка, а только предупреждение. В ДНС можно прописать так называемые SPF записи - для дополнительной защиты от спама, только эта защита будет защищать тебя косвенно, что бы спамеры не слали спам якобы от твоего имени.
Пока SPF запись делается через TXT, вроде хотят отдельную область под это дело завести. Как прописывается SPF - можно подглядеть у других:
dig subscribe.ru txt

Цитата:

Как прописывается SPF - можно подглядеть у других:
dig subscribe.ru txt

"v=spf1 +ip4:81.9.34.128/25 +ip4:195.14.58.8/29 +ip4:81.222.129.0/24 +ip4:81.222.64.160/27 -all"

Прописывается под ip4 должны все сети, что у меня ходят, т.е. локальные, или только те, кому предназначен данный домен?

Route
http://www.opennet.ru/search.shtml?words=spf&config=&restrict=&exclude=
http://spf.pobox.com/wizard.html