The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [ Отслеживать ]

"DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от sk email(??) on 26-Май-08, 10:38 
ОС FreeBSD 7.0, DNS BIND 9.4.2
Есть "заготовка" DNS сервера, который в будущем будет авторизованным DNS-сервером для доменов компании, также будет выполнять функцию DNS-ретранслятора (forwards). При тестировании столунулся со следующей ситуацией:

существует следующие полключение
[INTERNET]----[IP1|GW+DNAT|IP2.0]----[IP2.1|DNS-сервер]
                              

IP2.0 и IP2.1 - ip адреса приватной сети. IP1 реальный ip адрес. Доступ к DNS-серверу происходить с помощью "портмапинга". На днс развернуты прямые зоны для нескольких доменов и включена функция forwards(ретранслятор). ВОПРОС в следующем: попытаться запросить у DNS сервера "отрезольвить" имя например ya.ru то: если запрос выполняется из сети IP2.X то DNS сервер отлично все "резольвит", если запрос выолнятеся из сети ИНТЕРНЕТ то получаем ошибку "*** [IP1] can't find ya.ru: Query refused" хотя если отрезольвить имя хоста для зоны где мой DNS-сервер является авторизованным, то все отлично резольвиться.

При подключении DNS сервера на прямую к сети интернет (без портмапинга) ситуация не менятеся. Возможно ли, что ISP режет неавторизованные ответы моего DNS сервера? если да, то зачем это нужно? или это всеже мои кривые ручки?


Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от Fagor (ok) on 26-Май-08, 12:57 
>[оверквотинг удален]
>попытаться запросить у DNS сервера "отрезольвить" имя например ya.ru то: если
>запрос выполняется из сети IP2.X то DNS сервер отлично все "резольвит",
>если запрос выолнятеся из сети ИНТЕРНЕТ то получаем ошибку "*** [IP1]
>can't find ya.ru: Query refused" хотя если отрезольвить имя хоста для
>зоны где мой DNS-сервер является авторизованным, то все отлично резольвиться.
>
>При подключении DNS сервера на прямую к сети интернет (без портмапинга) ситуация
>не менятеся. Возможно ли, что ISP режет неавторизованные ответы моего DNS
>сервера? если да, то зачем это нужно? или это всеже мои
>кривые ручки?

ISP тут не причем однозначно. А вот если покажете named.conf, тогда можно будет сказать где что неправильно (это будет быстрее чем догадываться и предлагать различные варианты).

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от sk email(??) on 26-Май-08, 13:19 
>ISP тут не причем однозначно. А вот если покажете named.conf, тогда можно
>будет сказать где что неправильно (это будет быстрее чем догадываться и
>предлагать различные варианты).

Вот пжл: cat named.conf
------------------------
options {
        // Relative to the chroot directory, if any
        directory       "/etc/namedb";
        pid-file        "/var/run/named/pid";
        dump-file       "/var/dump/named_dump.db";
        statistics-file "/var/stats/named.stats";
        query-source address * port 53;

        // These zones are already covered by the empty zones listed below.
        // If you remove the related empty zones below, comment these lines out.
        disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
        disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
        disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";

        forwarders {
            213.248.1.6;
            213.248.0.6;
        };
};
zone "." { type hint; file "named.root"; };

//////////////////////////
// мои зоны              //
//////////////////////////
zone "domen-1.ru"           { type master; file "master/domen-1.ru"; };
zone "domen-2.ru"              { type master; file "master/domen-2.ru"; };
zone "domen-3.ru"          { type master; file "master/domen-3.ru"; };
zone "domen-4.ru"             { type master; file "master/domen-4.ru"; };
zone "domen-5.ru"          { type master; file "master/domen-5.ru"; };
zone "domen-6.ru"             { type master; file "master/domen-6.ru"; };
zone "domen-7.ru"           { type master; file "master/domen-7.ru"; };
zone "domen-8.ru"          { type master; file "master/domen-8.ru"; };


/*      Slaving the following zones from the root name servers has some
        significant advantages:
        1. Faster local resolution for your users
        2. No spurious traffic will be sent from your network to the roots
        3. Greater resilience to any potential root server failure/DDoS

        On the other hand, this method requires more monitoring than the
        hints file to be sure that an unexpected failure mode has not
        incapacitated your server.  Name servers that are serving a lot
        of clients will benefit more from this approach than individual
        hosts.  Use with caution.

        To use this mechanism, uncomment the entries below, and comment
        the hint zone above.
*/
/*
zone "." {
        type slave;
        file "slave/root.slave";
        masters {
                192.5.5.241;    // F.ROOT-SERVERS.NET.
        };
        notify no;
};
zone "arpa" {
        type slave;
        file "slave/arpa.slave";
        masters {
                192.5.5.241;    // F.ROOT-SERVERS.NET.
        };
        notify no;
};
zone "in-addr.arpa" {
        type slave;
        file "slave/in-addr.arpa.slave";
        masters {
                192.5.5.241;    // F.ROOT-SERVERS.NET.
        };
        notify no;
};
*/

/*      Serving the following zones locally will prevent any queries
        for these zones leaving your network and going to the root
        name servers.  This has two significant advantages:
        1. Faster local resolution for your users
        2. No spurious traffic will be sent from your network to the roots
*/
// RFC 1912
zone "localhost"        { type master; file "master/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file "master/localhost-reverse.db"; };
zone "255.in-addr.arpa" { type master; file "master/empty.db"; };

// RFC 1912-style zone for IPv6 localhost address
zone "0.ip6.arpa"       { type master; file "master/localhost-reverse.db"; };

// "This" Network (RFCs 1912 and 3330)
zone "0.in-addr.arpa"           { type master; file "master/empty.db"; };

// Private Use Networks (RFC 1918)
zone "10.in-addr.arpa"          { type master; file "master/empty.db"; };
zone "16.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "17.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "18.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "19.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "20.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "21.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "22.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "23.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "24.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "25.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "26.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "27.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "28.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "29.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "30.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "31.172.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "168.192.in-addr.arpa"     { type master; file "master/empty.db"; };

// Link-local/APIPA (RFCs 3330 and 3927)
zone "254.169.in-addr.arpa"     { type master; file "master/empty.db"; };

// TEST-NET for Documentation (RFC 3330)
zone "2.0.192.in-addr.arpa"     { type master; file "master/empty.db"; };

// Router Benchmark Testing (RFC 3330)
zone "18.198.in-addr.arpa"      { type master; file "master/empty.db"; };
zone "19.198.in-addr.arpa"      { type master; file "master/empty.db"; };

// IANA Reserved - Old Class E Space
zone "240.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "241.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "242.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "243.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "244.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "245.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "246.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "247.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "248.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "249.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "250.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "251.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "252.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "253.in-addr.arpa"         { type master; file "master/empty.db"; };
zone "254.in-addr.arpa"         { type master; file "master/empty.db"; };

// IPv6 Unassigned Addresses (RFC 4291)
zone "1.ip6.arpa"               { type master; file "master/empty.db"; };
zone "3.ip6.arpa"               { type master; file "master/empty.db"; };
zone "4.ip6.arpa"               { type master; file "master/empty.db"; };
zone "5.ip6.arpa"               { type master; file "master/empty.db"; };
zone "6.ip6.arpa"               { type master; file "master/empty.db"; };
zone "7.ip6.arpa"               { type master; file "master/empty.db"; };
zone "8.ip6.arpa"               { type master; file "master/empty.db"; };
zone "9.ip6.arpa"               { type master; file "master/empty.db"; };
zone "a.ip6.arpa"               { type master; file "master/empty.db"; };
zone "b.ip6.arpa"               { type master; file "master/empty.db"; };
zone "c.ip6.arpa"               { type master; file "master/empty.db"; };
zone "d.ip6.arpa"               { type master; file "master/empty.db"; };
zone "e.ip6.arpa"               { type master; file "master/empty.db"; };
zone "0.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "1.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "2.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "3.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "4.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "5.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "6.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "7.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "8.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "9.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "a.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "b.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "0.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "1.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "2.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "3.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "4.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "5.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "6.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "7.e.f.ip6.arpa"           { type master; file "master/empty.db"; };

// IPv6 ULA (RFC 4193)
zone "c.f.ip6.arpa"             { type master; file "master/empty.db"; };
zone "d.f.ip6.arpa"             { type master; file "master/empty.db"; };

// IPv6 Link Local (RFC 4291)
zone "8.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "9.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "a.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "b.e.f.ip6.arpa"           { type master; file "master/empty.db"; };

// IPv6 Deprecated Site-Local Addresses (RFC 3879)
zone "c.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "d.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "e.e.f.ip6.arpa"           { type master; file "master/empty.db"; };
zone "f.e.f.ip6.arpa"           { type master; file "master/empty.db"; };

// IP6.INT is Deprecated (RFC 4159)
zone "ip6.int"                  { type master; file "master/empty.db"; };

-------------------------
Опции запуска:
named_enable="YES"
named_flags="-4"
named_chrootdir="/var/chroot/named"
named_chroot_autoupdate="YES"
named_symlink_enable="YES"

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от ALex_hha (??) on 26-Май-08, 17:43 
>если запрос выолнятеся из сети ИНТЕРНЕТ то получаем ошибку "*** [IP1]
>can't find ya.ru: Query refused"

так и должно быть или вы хотите сделать публичный ДНС сервер?

>хотя если отрезольвить имя хоста для
>зоны где мой DNS-сервер является авторизованным, то все отлично резольвиться.

ну так и должно быть

>или это всеже мои кривые ручки?

именно они

Вот вам яркий пример

# nslookup www.mail.ru ns1.mail.ru
Server:         ns1.mail.ru
Address:        194.67.57.103#53

Name:   www.mail.ru
Address: 194.67.57.126
Name:   www.mail.ru
Address: 194.67.57.226
Name:   www.mail.ru
Address: 194.67.57.26

# nslookup www.ukr.net ns1.mail.ru
Server:         ns1.mail.ru
Address:        194.67.57.103#53

** server can't find www.ukr.net: REFUSED

Ибо ns1.mail.ru является авторитативным для зоны mail.ru. Поэтому и ответил на www.mail.ru. А во втором случае отказал, т.к. он не является авторитативным для домена ukr.net и на нем закрыты рекурсивные запросы для мира.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от sk email(??) on 27-Май-08, 00:13 
>так и должно быть или вы хотите сделать публичный ДНС сервер?

Угу именно так, хочу чтоб сервер был публичный :). Как я понимаю нужно скачать файлик с корневыми серверами и указать его в "." зоне?
>
>>или это всеже мои кривые ручки?
>
>именно они
>

Большое вам спасибо за подробный ответ

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от sk email(??) on 27-Май-08, 00:28 
Еще вопрос.
Почему BIND разрешает делать рекурсивные запросы хостам которые находятся в тойже IP-сети что и он сам, а хостам из других сетей запрещает?
На какие параметры мне обратить внимание в конфигурационном файле для управления данным поведением сервера?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от Pahanivo email(ok) on 27-Май-08, 10:23 
>Еще вопрос.
>Почему BIND разрешает делать рекурсивные запросы хостам которые находятся в тойже IP-сети
>что и он сам, а хостам из других сетей запрещает?
>На какие параметры мне обратить внимание в конфигурационном файле для управления данным
>поведением сервера?

По дефолту рекурсия в бинде включена. Сервак вообще не должен разграничивать клиентов и разрешать всем рекурсию судю по твоему конфигу. Но это не есть гут. Ибо рекурсия должна быть открыта только для своих клиентов и запрещена для всех остальных.
Скорей всего у тебя какойто касяк с забросом запросов внутрь сетки.
А вообще качни мануал с isc.org и внимательно читай чо и как.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от sk email(??) on 27-Май-08, 11:03 
>Скорей всего у тебя какойто касяк с забросом запросов внутрь сетки.

Подключал DNS на прямую к интернет (без портмапинга) ситуация не изменилась :(

>А вообще качни мануал с isc.org и внимательно читай чо и как

Уже курю. Но хотелось чтоб пальцем указали в нужный параграф чтобы не обкурится по невнимательности :)


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от ALex_hha (??) on 27-Май-08, 11:16 
>>так и должно быть или вы хотите сделать публичный ДНС сервер?
>
>Угу именно так, хочу чтоб сервер был публичный :). Как я понимаю
>нужно скачать файлик с корневыми серверами и указать его в "."
>зоне?

нет, что то типа этого

allow-recursion { 0.0.0.0/0.0.0.0; };

Но только опасно так делать, тогда надо ограничивать количество запросов в единицу времени

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от sk email(??) on 27-Май-08, 12:05 
>allow-recursion { 0.0.0.0/0.0.0.0; };
>
>Но только опасно так делать, тогда надо ограничивать количество запросов в единицу
>времени

Прописал allow-recursion { any; }; и все заработало. Теперь последую вашему совету и ограничу рекурсию с помощью acl, разрешу только дружеским сетями. Большое Вам спасибо.

P.S странно наверно раньше allow-recursion был в BIND по умолчанию включен для всех сетей, поэтому я не натыкался на такое поведение.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от Pahanivo email(ok) on 27-Май-08, 13:48 
>[оверквотинг удален]
>>
>>Но только опасно так делать, тогда надо ограничивать количество запросов в единицу
>>времени
>
>Прописал allow-recursion { any; }; и все заработало. Теперь последую вашему совету
>и ограничу рекурсию с помощью acl, разрешу только дружеским сетями. Большое
>Вам спасибо.
>
>P.S странно наверно раньше allow-recursion был в BIND по умолчанию включен для
>всех сетей, поэтому я не натыкался на такое поведение.

Хм я в мануале посмотрел. Может там старые данные хотя смотрел для 9.4.
Вообще КРАЙНЕ рекомендую почитать мануал - там много чо можно настроить.
Вообще в плане конфига бинд весь имхо довольно грамотная.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от sk email(??) on 27-Май-08, 20:22 
>Хм я в мануале посмотрел. Может там старые данные хотя смотрел для
>9.4.

Мне тоже всегда казалось что рекурсионные запросы по умолчанию разрешены :(
>Вообще КРАЙНЕ рекомендую почитать мануал - там много чо можно настроить.
>Вообще в плане конфига бинд весь имхо довольно грамотная.

Обязательно как же без этого :). Еще раз большое спасибо за участие в решении вопроса


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от ALex_hha (??) on 27-Май-08, 14:02 
>[оверквотинг удален]
>>
>>Но только опасно так делать, тогда надо ограничивать количество запросов в единицу
>>времени
>
>Прописал allow-recursion { any; }; и все заработало. Теперь последую вашему совету
>и ограничу рекурсию с помощью acl, разрешу только дружеским сетями. Большое
>Вам спасибо.
>
>P.S странно наверно раньше allow-recursion был в BIND по умолчанию включен для
>всех сетей, поэтому я не натыкался на такое поведение.

Так а что мешает сразу прописать эти сети в allow-recursion?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "DNS. Может ли ISP резать неавторизованные ответы DNS-сервера..."  
Сообщение от sk email(??) on 27-Май-08, 20:18 
>Так а что мешает сразу прописать эти сети в allow-recursion?

пока "политически" не решено каким сетям можно каким нет :)


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




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

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