Назад | Перейти на главную страницу

Рекурсивные запросы Bind9 имеют периодическое очень долгое время ответа

Я запускаю кэширующий сервер BIND 9.8.1-P1 в Ubuntu 12.04 LTS с ядром 3.2.0-86-generic-pae.

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

Что происходит, так это то, что при загрузке страницы, такой как www.msn.com в Firefox с открытым сетевым монитором Firefox, я иногда вижу несколько запросов, которые имеют часть времени разрешения DNS от 8000 мс до 37000 мс. Конечно, как только я перезагружаю страницу, она кэшируется, а затем работает нормально, но даже если я очищаю кеш как на сервере, так и на клиенте, этот домен перестает быть проблемой. Мне не удалось увидеть какой-либо шаблон, в котором возникают проблемы с доменами. Я просто не знаю, как это исправить, потому что это очень сложно повторить для одного и того же домена дважды.

Вот все, что у меня есть в named.conf.options

options {
        directory "/var/cache/bind";

        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113

        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.

        forwarders {
                //OpenDNS
                208.67.222.222;
                208.67.220.220;
        };

        auth-nxdomain no;    # conform to RFC1035
        //listen-on-v6 { any; };
};

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

В соответствии с запросом, здесь представлены записи журнала, созданные при включении журнала запросов и последующей загрузке www.wsj.com. Только 4 запроса имеют медленные ответы DNS

tags.bluekai.com    11986ms

Jul 30 17:50:14 fs named[23539]: client 192.168.16.24#55215: query: tags.bluekai.com IN A + (192.168.16.3)
Jul 30 17:50:15 fs named[23539]: client 192.168.16.24#55215: query: tags.bluekai.com IN A + (192.168.16.3)
Jul 30 17:50:16 fs named[23539]: client 192.168.16.24#55215: query: tags.bluekai.com IN A + (192.168.16.3)
Jul 30 17:50:18 fs named[23539]: client 192.168.16.24#55215: query: tags.bluekai.com IN A + (192.168.16.3)
Jul 30 17:50:22 fs named[23539]: client 192.168.16.24#55215: query: tags.bluekai.com IN A + (192.168.16.3)

comcluster.cxense.com   24004ms

Jul 30 17:38:32 fs named[23539]: client 192.168.16.24#52469: query: comcluster.cxense.com IN A + (192.168.16.3)
Jul 30 17:50:14 fs named[23539]: client 192.168.16.24#56490: query: comcluster.cxense.com IN A + (192.168.16.3)
Jul 30 17:50:14 fs named[23539]: client 192.168.16.24#54692: query: comcluster.cxense.com IN A + (192.168.16.3)
Jul 30 17:50:15 fs named[23539]: client 192.168.16.24#54692: query: comcluster.cxense.com IN A + (192.168.16.3)    
Jul 30 17:50:15 fs named[23539]: client 192.168.16.24#56490: query: comcluster.cxense.com IN A + (192.168.16.3)
Jul 30 17:50:16 fs named[23539]: client 192.168.16.24#54692: query: comcluster.cxense.com IN A + (192.168.16.3)    
Jul 30 17:50:16 fs named[23539]: client 192.168.16.24#56490: query: comcluster.cxense.com IN A + (192.168.16.3)
Jul 30 17:50:18 fs named[23539]: client 192.168.16.24#54692: query: comcluster.cxense.com IN A + (192.168.16.3)    
Jul 30 17:50:18 fs named[23539]: client 192.168.16.24#56490: query: comcluster.cxense.com IN A + (192.168.16.3)
Jul 30 17:50:22 fs named[23539]: client 192.168.16.24#56490: query: comcluster.cxense.com IN A + (192.168.16.3)    
Jul 30 17:50:22 fs named[23539]: client 192.168.16.24#54692: query: comcluster.cxense.com IN A + (192.168.16.3)
Jul 30 17:50:26 fs named[23539]: client 192.168.16.24#56963: query: comcluster.cxense.com IN A + (192.168.16.3)
Jul 30 17:50:27 fs named[23539]: client 192.168.16.24#56963: query: comcluster.cxense.com IN A + (192.168.16.3)
Jul 30 17:50:28 fs named[23539]: client 192.168.16.24#56963: query: comcluster.cxense.com IN A + (192.168.16.3)
Jul 30 17:50:28 fs named[23539]: client 192.168.16.24#56963: query: comcluster.cxense.com IN A + (192.168.16.3)
Jul 30 17:50:30 fs named[23539]: client 192.168.16.24#56963: query: comcluster.cxense.com IN A + (192.168.16.3)
Jul 30 17:50:34 fs named[23539]: client 192.168.16.24#56963: query: comcluster.cxense.com IN A + (192.168.16.3)

cdn.cxpublic.com    23509ms

Jul 30 17:50:26 fs named[23539]: client 192.168.16.24#57469: query: cdn.cxpublic.com IN A + (192.168.16.3)
Jul 30 17:50:27 fs named[23539]: client 192.168.16.24#57469: query: cdn.cxpublic.com IN A + (192.168.16.3)
Jul 30 17:50:28 fs named[23539]: client 192.168.16.24#57469: query: cdn.cxpublic.com IN A + (192.168.16.3)
Jul 30 17:50:30 fs named[23539]: client 192.168.16.24#57469: query: cdn.cxpublic.com IN A + (192.168.16.3)
Jul 30 17:50:34 fs named[23539]: client 192.168.16.24#57469: query: cdn.cxpublic.com IN A + (192.168.16.3)

www.facebook.com    33666ms

Jul 30 17:39:37 fs named[23539]: client 192.168.16.24#54063: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:26 fs named[23539]: client 192.168.16.24#63809: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:26 fs named[23539]: client 192.168.16.24#61280: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:27 fs named[23539]: client 192.168.16.24#63809: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:27 fs named[23539]: client 192.168.16.24#61280: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:28 fs named[23539]: client 192.168.16.24#63809: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:28 fs named[23539]: client 192.168.16.24#61280: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:30 fs named[23539]: client 192.168.16.24#63809: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:30 fs named[23539]: client 192.168.16.24#61280: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:34 fs named[23539]: client 192.168.16.24#63809: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:34 fs named[23539]: client 192.168.16.24#61280: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:38 fs named[23539]: client 192.168.16.24#64685: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:39 fs named[23539]: client 192.168.16.24#64685: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:40 fs named[23539]: client 192.168.16.24#64685: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:42 fs named[23539]: client 192.168.16.24#64685: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:46 fs named[23539]: client 192.168.16.24#64685: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:50 fs named[23539]: client 192.168.16.24#57121: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:51 fs named[23539]: client 192.168.16.24#57121: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:52 fs named[23539]: client 192.168.16.24#57121: query: www.facebook.com IN A + (192.168.16.3)
Jul 30 17:50:54 fs named[23539]: client 192.168.16.24#57121: query: www.facebook.com IN A + (192.168.16.3)

Спасибо всем, кто помог мне решить эту проблему, но, похоже, я решил проблему случайно. Замена маршрутизатора, похоже, полностью устранила проблему. Я провел обширное тестирование, загружая различные страницы из Alexa 500 в Firefox, и я больше не могу воссоздать проблему. Маршрутизатор, который я заменил, был очень старым, и я не заменял его, пытаясь решить эту проблему, но похоже, что старый маршрутизатор был источником проблемы, с которой я столкнулся.

Для справки, старый маршрутизатор был Netgear WGR614v5, и я заменил его на TP-LINK Archer C7.