1.1, A1ek (?), 23:09, 23/02/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
стопицотое подтверждение того, что актуальная версия ПО - лучшая защита.
| |
|
2.2, bircoph (ok), 23:32, 23/02/2011 [^] [^^] [^^^] [ответить]
| –6 +/– |
Скорее, подтверждение того, что следует использовать адекватную замену bind.
| |
|
3.3, Hety (??), 23:34, 23/02/2011 [^] [^^] [^^^] [ответить]
| –7 +/– |
+1. Уж мыши кололись-кололись, кололись-кололись. У бинда, вероятно, есть своя ниша, но использовать его в ситуациях, когда нет отряда обслуживающих его товаришей, я бы не стал.
| |
|
4.4, pavlinux (ok), 01:06, 24/02/2011 [^] [^^] [^^^] [ответить]
| +3 +/– |
Гляжу тут одни провайдеры тусуются... Аль на DNS запросах трафик экономите? :)
| |
|
5.5, pavlinux (ok), 01:07, 24/02/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Гляжу тут одни провайдеры тусуются... Аль на DNS запросах трафик экономите? :)
# echo -ne "nameserver 8.8.4.4\nnameserver 8.8.8.8\n" > /etc/resolv.conf
в /etc/dhcpd.conf
option domain-name-servers 8.8.4.4, 8.8.8.8;
И весь офис щастлив!
| |
|
6.8, Hety (??), 08:31, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
Как раз совершенно не провайдеры. Именно поэтому трахаться с биндом смысла нет никакого.
| |
6.10, sHaggY_caT (ok), 10:22, 24/02/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
>И весь офис щастлив!
Не подойдет, если часть сервисов находится в офисной локале, под DNAT на локальный IP, и нужен локальный DNS, который резолвит DNS по корпоративным доменам по-другому, в отличие от внешних, которые резолвят на один из публичных IP офиса.
Кроме того, частенько бывают сервисы, которые вообще извне недоступны, а находятся только внутри офисной локалки, и извне, или другого офиса конторы к ним доступ через VPN (или на сервере в датацентре, но все равно всем подряд не видны)
| |
|
7.15, Bx (ok), 12:02, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
>>И весь офис щастлив!
> Не подойдет, если часть сервисов находится в офисной локале, под DNAT на
> локальный IP, и нужен локальный DNS, который резолвит DNS по корпоративным
> доменам по-другому, в отличие от внешних, которые резолвят на один из
> публичных IP офиса.
> Кроме того, частенько бывают сервисы, которые вообще извне недоступны, а находятся только
> внутри офисной локалки, и извне, или другого офиса конторы к ним
> доступ через VPN (или на сервере в датацентре, но все равно
> всем подряд не видны)
etc/hosts вроде вроде как даже и в seven есть :)
но осчастливливать гуглу внутренними именами я бы тоже не стал. А выпускать резолвинг из внутренней сетки - вообще немного странно на мой взгляд
| |
7.18, pavlinux (ok), 13:44, 24/02/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>И весь офис щастлив!
> Не подойдет, если часть сервисов находится в офисной локале, под DNAT
Ну тогда им на...рать на "интенсивный поток IXFR-пересылок или DDNS-обновлений..."
| |
|
6.16, mr_gfd (?), 13:36, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Гляжу тут одни провайдеры тусуются... Аль на DNS запросах трафик экономите? :)
> # echo -ne "nameserver 8.8.4.4\nnameserver 8.8.8.8\n" > /etc/resolv.conf
> в /etc/dhcpd.conf
> option domain-name-servers 8.8.4.4, 8.8.8.8;
> И весь офис щастлив!
Ой-вей и таки ой! А как же таймауты или длительное ожидание ответа?
| |
|
|
|
3.12, Аноним (-), 10:43, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
Ага, видели мы эти замены: MaraDNS, PowerDNS и Dnsmasq.
В открытом DNS-сервере MaraDNS найдена критическая уязвимость, позволяющая выполнить код на сервере через отправку специально сформированного DNS-запроса (резолвинг имени домена длиннее 254 символов). Статус устранения уязвимости пока неизвестен; http://www.opennet.me/opennews/art.shtml?num=29402
В открытом высокопроизводительном DNS-сервере PowerDNS Recursor найдены две критические уязвимости, позволяющие удаленному злоумышленнику через отправку специально оформленного пакета выполнить свой код на сервере и осуществить подстановку данных злоумышленника в кэш DNS сервера.
http://www.opennet.me/opennews/art.shtml?num=24921
В пакете Dnsmasq, объединяющем в себе кэширующий DNS прокси и DHCP сервер, обнаружено две уязвимости, позволяющие удаленному злоумышленнику добиться выполнения своего кода.
http://www.opennet.me/opennews/art.shtml?num=23245
В кеширующем резолвере dnscache из состава пакета djbdns подтверждено наличие проблемы безопасности, связанной с некорректной обработкой SOA (Start of Authority) полей, что может быть использовано для увеличение вероятности успешного совершения атаки, направленной на подстановку данных в DNS кеш.
http://www.opennet.me/opennews/art.shtml?num=20633
Особенно комично в этом контексте выглядят такие заявления:
"MaraDNS has a strong security history. For example, MaraDNS has always randomized, using a secure random number generator, the Query ID and source port of DNS queries; and was never vulnerable to the "new" cache poisoning attack."
| |
|
4.13, bircoph (ok), 11:26, 24/02/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Посмотри Unbound и NSD, детка. Там и безопасность выше, и скорость. А функциональность та же.
| |
|
|
6.22, bircoph (ok), 19:54, 24/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Также дырявы, но в отличие от Bind аудит кода в них никто толком еще не проводил.
Эти дыры давно закрыли. Конечно, незакрытые дыры есть везде. Но лучше тем, что кода меньше и он проще => безопаснее.
| |
|
|
|
|
|
1.6, Аноним (-), 02:02, 24/02/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вот интересно, а что же тогда адекватная замена бинду? Книжки и толковые руководства пока только под него и написаны. Теряюсь в дагадках.
Конечно заметно что с каждым годом оно всё хуже и хуже...
| |
|
|
3.24, анонимоус (?), 11:45, 25/02/2011 [^] [^^] [^^^] [ответить]
| +/– |
А завтра когда популярность его хоть чуть чуть повысится в нем будут находить
по 1 дырке в день.
Спасибо кушайте сами, а я лучше погрызу "кактус"(bind)
| |
|
|
|