[boco]

Вообщем, после очередной жалобы юзера: мол, такой-то сайт не резолвится, а если гугл днс прописать - все ок,

решил таки я уйти от bind9 на unbound.

 

На unbound внезапно нормально резолвится проблемный сайтик.

я бы скрестил ежа с ужом. в конфиге бинда укажите свой unbound forwarder-ом =)

[man781]

Вообщем, после очередной жалобы юзера: мол, такой-то сайт не резолвится, а если гугл днс прописать - все ок,

решил таки я уйти от bind9 на unbound.

 

На unbound внезапно нормально резолвится проблемный сайтик.

я бы скрестил ежа с ужом. в конфиге бинда укажите свой unbound forwarder-ом =)

Спасибо!

Так и сделаю.

[Alekxxandrus]

Как костыльный но рабочий вариант можете завести себе эту зону с типом forward и как forwarders указать "рабочие" NS-серверы.

Да наверное именно так...

[Ivan_83]

Вообщем, после очередной жалобы юзера: мол, такой-то сайт не резолвится, а если гугл днс прописать - все ок,

решил таки я уйти от bind9 на unbound.

 

На unbound внезапно нормально резолвится проблемный сайтик.

 

Но вот столкнулся я с тем, что в unbound не работает запись для retracker.local в частности

и вообще CNAME запись из "чужого" домена.

Как я не крутил варианты полдня.

 

Может кто показать кусок примера конфига unbound для вышеописанных случаев?

 

CNAME пока увы не работает / не сделан.

Только обычные записи типа А, АААА, ТХТ и пр.

[MATPOC]

На unbound внезапно нормально резолвится проблемный сайтик.

я бы скрестил ежа с ужом. в конфиге бинда укажите свой unbound forwarder-ом =)

Мы сделали наоборот - named для локальных зон, основной DNS сервер для клиентов - unbound.

[Telesis]

Но вот столкнулся я с тем, что в unbound не работает запись для retracker.local в частности

unbound-control local_data retracker.local A BLA.BLA.BLA.BLA

[man781]

у меня не A запись для retracker.local, а

 

CNAME на региональный ретрекер

[Telesis]

Не вижу разницы для клиента A или CNAME.

[man781]

unbound-control local_data retracker.local CNAME retracker.ofzn.ru

 

не кушает.

 

Вы предлагаете все равно прописать для клиентов A запись, разрезолвив один раз вручную retracker.ofzn.ru ?

А если retracker.ofzn.ru сменит IP - просто иногда следить за этим ?

 

P.S. Все примеры доменов являются вымышленными. Любое совпадение - это случайность....

[man781]

короче для юзеров в качестве днс заюзал unbound

bind9 держит зоны.

Все ок

[Megas]

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

 

so-rcvbuf: 8m
so-sndbuf: 8m
max-udp-size: 3072
msg-cache-size: 32m
msg-cache-slabs: 4
num-queries-per-thread: 1024
rrset-cache-size: 64m
rrset-cache-slabs: 4
cache-min-ttl: 30
cache-max-ttl: 240
infra-host-ttl: 360
infra-cache-slabs: 8
infra-cache-numhosts: 200000

 

 

[1421788751] unbound[28570:0] notice: Start of unbound 1.4.22.

 

Понимаю что это старая и в новых версиях там простыни фиксов, но на CentOS придется вручную собирать новую версию

Изменено 20 января, 2015 пользователем Megas

[GrandPr1de]

у меня на фре 1.4.21\22 работали нормально.

становился невменяемым когда линк падал на аплинк (т.е. отсутсвтует интернет). наверное из-за колва юзерских запросов..

[Telesis]

А если retracker.ofzn.ru сменит IP - просто иногда следить за этим ?

Все зависит от вашей лени. Можно скрипт сделать, который будет обновлять на то что тебе надо.

[man781]

я просто раз в месяц буду проверять вручную.

(Добавил себе в планировщик ежемесячную напоминашку)

[hsvt]

короче для юзеров в качестве днс заюзал unbound

bind9 держит зоны.

Все ок

 

Как настроили связку в итоге ? Unbound форвардит на bind9 если клиенты запрашивают свои зоны и записи? Или клиенты хостеры отдельно прописывают себе IP bind-a ? Сколько в итоге ns серверов в сети ?

[man781]

юзеры резолвятся через unbound.

Unbound форвардит на bind9 если клиенты запрашивают записи из нашей зоны (разные левые и локальные записи леплю прямо в unbound).

NS сервер один.

(на самом деле все еще сложнее - в качестве днс сервера юзерам выдается адрес скайд днс прокси - занимается фильтрацией и уже переспрашивает unbound, если запись не подпадает под фильтрацию.

А еще реальные NS и зона находятся на внешнем днс хостинге (авторитетно держит зону для мира и для клиентов - которые руками себе прописали 8.8.8.8 и прочее)

 

Вот такой вот винигрет сложился исторически.

Но таки все работает )

[hsvt]

юзеры резолвятся через unbound.

Unbound форвардит на bind9 если клиенты запрашивают записис из нашей зону (разные левые и локальные записи леплю прямо в unbound).

NS сервер один.

(на самом деле все еще сложнее - в качестве днс сервера юзерам выдается адрес скайд днс прокси - занимается фильтрацией и уже переспаршивает unbound, если запись не подпадает под фильтрацию.

А еще реальные NS и зона находятся на внешнем днс хостинге (авторитетно держит зону для мира и для клиентов - которые руками себе прописали 8.8.8.8 и прочее)

 

Вот такой вот винигрет сложился исторически.

Но таки все работает )

 

Спасибо, буду думать.

[man781]

что тут думать, unbound - лучше чем bind рекурсор в 1000 раз.

А зоны держать - гораздо лучше в bind, чем unbound.

[hsvt]

что тут думать, unbound - лучше чем bind рекурсор в 1000 раз.

А зоны держать - гораздо лучше в bind, чем unbound.

 

Response rate limiting is designed for authoritative name servers. It does not

work well for recursive servers, because most recursive clients are cacheless

so it is normal for them to repeat queries in a way that would be unreasonable

for cacheing iterative clients. Response rate limiting is not just a per client

query limit.

 

The way to secure a recursive server is to answer queries only from your

network's IP addresses.

 

А rate-limit нету на Unbound чтоли? Как там бороться с открытыми резолверами у клиентов ? Тут куча тем подобных мелькала. Можете конфигом в лс поделиться если не трудно, затерев важные адрес\зоны.

[man781]

Рейт лимит даже если и есть на уровне днс демона - это вам не поможет.

Рейт лимит легко рулится с помошью iptables.

Но и это вам не поможет - завалить ваш сервак все равно смогут.

 

Как там бороться с открытыми резолверами у клиентов ?

Закрыть их )

 

Закрывайте однозначно трафик из мира на адреса ваших юзеров udp dst 53.

Я закрыл на бордере и горя не знаю (более 20-ти тысяч хомяков с роутерами и белыми ипами).

(заодно телнет/смтп/снмп/фтп/тфтп/сислог/ссш/веб).

Чтобы из мира не трогали вот эти все прелести открытые на некоторых роутерах.

Ессно - изнутри наружу эти протоколы спокойно работают.

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

 

п.с. конфиг unbound простой как грабли:

server:
verbosity: 1
num-threads: 4
interface: а.б.с.д
port: 53
outgoing-range: 4096
so-rcvbuf: 4m
msg-cache-size: 16m
num-queries-per-thread: 1024
rrset-cache-size: 32m
cache-max-ttl: 86400
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: no
access-control: 0.0.0.0/0 refuse
         access-control: 127.0.0.1/32 allow
         access-control: ::0/0 refuse
chroot: ""
use-syslog: yes 
log-time-ascii: yes

#всякая лабуда
local-data: "retracker.local. 300 IN A x.y.z.111"
local-data: "synet.local. 300 IN A 192.168.10.33"
local-data: "torrent.to. 300 IN A 172.16.0.100"

python:
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 953
server-key-file: "/etc/unbound/unbound_server.key"
server-cert-file: "/etc/unbound/unbound_server.pem"
сontrol-key-file: "/etc/unbound/unbound_control.key"
control-cert-file: "/etc/unbound/unbound_control.pem"

stub-zone:
      name: "моя_зона.ком."
      stub-addr: 111.111.111.111  #address of my server with bind9 который держит зону моя_зона.ком.

 

Конфиг вряд ли идеальный.

Но работает без нареканий.

(для наглядности вырезал тут много полезных комментов и закоменченных доп.опций (которые идут в дефолтном конфиге из дистра))

[hsvt]

Большущие вам спасибо. Я уже сам начал раскуривать потихоньку какой конфиг мне будет нужен. Будем закрывать, но тут много кому нужно зайти снаружи на свои IP по разным сервисам.

 

Вот что еще нашёл из полезного для unbound:

 

http://pgl.yoyo.org/adservers/serverlist.php?hostformat=unbound;showintro=0 - блокировка рекламы, хотя может быть вредно и не желательно.

https://github.com/smurfmonitor/dns-iptables-rules

https://github.com/jodrell/unbound-block-hosts/

 

stub-zone:
      name: "моя_зона.ком."
      stub-addr: 111.111.111.111  #address of my server with bind9 который держит зону моя_зона.ком

 

У меня таких зон около сотни в binde, это сюда все вписывать получается ? :)

Изменено 1 декабря, 2015 пользователем hsvt

[Ivan_83]

local-zone: "101com.com" redirect local-data: "101com.com A 127.0.0.1"

Дуратская рекомендация/конфиг.

1. две строчки

2. лучше 0.0.0.0 отдавать, вроде это значит фейл резолва

3. а как же АААА?

 

[man781]

У меня таких зон около сотни в binde, это сюда все вписывать получается ? :) 

Интересно, зачем столько зон...

 

Может что-то достаточно будет в анбаунд напихать записи типа так:

 

local-data: "retracker.local. 300 IN A x.y.z.111"

local-data: "synet.local. 300 IN A 192.168.10.33"

local-data: "torrent.to. 300 IN A 172.16.0.100"

 

Или если ваш байнд авторитетно держит зоны в мире, то можно и не прописывать stub-zone - анбаунд спросит у корневых, а те - все равно у ваших авторитетных.

 

Вот что еще нашёл из полезного для unbound:

Боком вылезит в самых неожиданных местах.

Чем проще - тем лучше.

[hsvt]

Ответ на то, что в stub-zone приходит не авторитетный. Вот здесь обсуждалось -> http://forum.nag.ru/forum/index.php?showtopic=98379&st=0 от unboundа нельзя добиться авторитетных ответов которые он форвардит на bind ? Тогда какой смысл в stub zones.

 

There is a difference between forward zones and stub zones - stub zones will only work when connected to an authoritative DNS server directly. This would work for lookups from a BIND DNS server if it is providing authoritative DNS - but if you are referring queries to an unbound server in which internal lookups are forwarded on to another DNS server, then defining the referral as a stub zone in the machine here will not work. In that case it is necessary to define a forward zone as above, since forward zones can have daisy chain lookups onward to other DNS servers. i.e. forward zones can refer queries to recursive DNS servers. This distinction is important as you do not get any error messages indicating what the problem is if you use a stub zone inappropriately.

Изменено 2 декабря, 2015 пользователем hsvt

[man781]

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

(домашние серверы не в счет - пусть пропишут себе не провайдерский днс, или поднимут свой, или идут в дата центр хостится за соответвующие деньги)