Мы наблюдаем высокие уровни (более 2000 запросов в секунду) DNS-запросов от наших кэширующих DNS-серверов на внешние серверы. Возможно, это происходило давно - это стало известно недавно из-за проблем с производительностью нашего брандмауэра. Из разговоров с коллегами из других учреждений становится ясно, что мы задаем больше вопросов, чем они.
Моя первоначальная мысль заключалась в том, что проблема заключалась в отсутствии кеширования ответов SERVFAIL. После проведения дополнительных исследований стало ясно, что проблема заключается в высоком уровне запросов на сбойную запись с DNS-серверов Windows. Кажется, что в нашей среде один запрос к одному из DNS-серверов Windows для записи из зоны, которая возвращает SERVFAIL, приводит к потоку запросов для этой записи из все DNS-серверов Windows. Поток запросов не прекращается, пока я не добавлю фальшивую пустую зону на одном из серверов Bind.
Завтра я планирую проверить конфигурацию DNS-серверов Windows - они должны просто пересылать на кэширующие серверы Bind. Я полагаю, что у нас должно быть что-то не так, потому что я не могу поверить, что никто другой не ударил это, если это не неправильная конфигурация. Я обновлю этот вопрос после этого (возможно, закрыв этот и открою новый, более понятный).
Наша установка представляет собой пару кэширующих серверов с Bind 9.3.6, которые используются либо напрямую клиентами, либо через наши контроллеры домена Windows. Кэширующие серверы передают запросы нашим основным DNS-серверам, на которых работает 9.8.4-P2 - эти серверы являются полномочными для наших доменов и передают запросы для других доменов на внешние серверы.
Мы наблюдаем такое поведение, что запросы, подобные приведенному ниже, не кэшируются. Я проверил это, просмотрев сетевой трафик с DNS-серверов с помощью tcpdump.
[root@dns1 named]# dig ptr 119.49.194.173.in-addr.arpa.
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> ptr 119.49.194.173.in-addr.arpa.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8680
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;119.49.194.173.in-addr.arpa. IN PTR
;; Query time: 950 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Mar 9 13:34:20 2014
;; MSG SIZE rcvd: 45
Запросы к серверу Google напрямую показывают, что мы получаем ОТКАЗАННЫЙ ответ.
[root@dns1 named]# dig ptr 119.49.194.173.in-addr.arpa. @ns4.google.com.
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> ptr 119.49.194.173.in-addr.arpa. @ns4.google.com.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 38825
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;119.49.194.173.in-addr.arpa. IN PTR
;; Query time: 91 msec
;; SERVER: 216.239.38.10#53(216.239.38.10)
;; WHEN: Sun Mar 9 13:36:38 2014
;; MSG SIZE rcvd: 45
Это происходит не только с адресами Google или обратным поиском, но большая часть запросов относится к этим диапазонам (я подозреваю, что из-за функции отчетов Sophos).
Должны ли наши DNS-серверы кэшировать эти отрицательные ответы? Я читаю http://tools.ietf.org/rfcmarkup?doc=2308 но ничего не видел в REFUSED. Мы не указываем lame-ttl в файле конфигурации, поэтому я ожидаю, что по умолчанию будет 10 минут.
Я считаю, что это (отсутствие кеширования) ожидаемое поведение. Я не понимаю, почему другие сайты, с которыми я разговаривал, не видят то же самое. Я пробовал тестовый сервер с последней стабильной версией Bind, и он показывает такое же поведение. Я также пробовал Unbound, и он тоже не кешировал SERVFAIL. Есть некоторое обсуждение того, как сделать это в djbdns Вот но вывод, что функциональность удалена.
Есть ли в конфигурации Bind настройки, которые мы можем изменить, чтобы повлиять на это поведение? lame-ttl не помог (и мы все равно работали по умолчанию).
В рамках расследования я добавил несколько поддельных пустых зон на наших кэширующих DNS-серверах, чтобы охватить диапазоны, ведущие к большинству запросов. Это снизило количество запросов к внешним серверам, но это не является устойчивым (и тоже кажется неправильным). Параллельно с этим я попросил коллегу получить журналы с DNS-серверов Windows, чтобы мы могли идентифицировать клиентов, отправляющих исходные запросы.
Соответствующая часть RFC2308 §7.1 Отказ сервера (НЕОБЯЗАТЕЛЬНО).
В любом случае распознаватель МОЖЕТ кэшировать ответ о сбое сервера. Если это так, он НЕ ДОЛЖЕН кэшировать его дольше пяти (5) минут, и он ДОЛЖЕН быть кэширован для определенного кортежа запроса.
Я не знаю простой директивы конфигурации, которая могла бы переопределить это, хотя, если бы вы были так склонны, вы могли бы перенаправить эту зону в другое место или обслужить ее напрямую.
Если это напрямую вызывает проблемы с брандмауэром, вам следует проверить тайм-ауты псевдосоединения UDP, кеширование DNS UDP может заполнить таблицу состояний, если оно велико. Запросы DNS имеют тенденцию блокироваться, поэтому я надеюсь, что вы не выполняете (м) какие-либо из них на брандмауэре.
Некоторые из обратных зон для 173.194 / 16 кажутся пробитыми. Oни должен в худшем случае возвращает кэшируемые NXDOMAIN, а не SERVFAIL или REFUSED.
$ dig 194.173.in-addr.arpa. ns +short
NS4.GOOGLE.COM.
NS3.GOOGLE.COM.
NS2.GOOGLE.COM.
NS1.GOOGLE.COM.
$ dig @ns4.google.com 119.49.194.173.in-addr.arpa. ns
; <<>> DiG 9.8.4-P4 <<>> @ns4.google.com 119.49.194.173.in-addr.arpa. ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 63925
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
194.173.in-addr.arpa делегирован ARIN в Google:
$ dig @z.arin.net 194.173.in-addr.arpa. ns +auth
;; AUTHORITY SECTION:
194.173.in-addr.arpa. 86400 IN NS NS4.GOOGLE.COM.
194.173.in-addr.arpa. 86400 IN NS NS1.GOOGLE.COM.
194.173.in-addr.arpa. 86400 IN NS NS2.GOOGLE.COM.
194.173.in-addr.arpa. 86400 IN NS NS3.GOOGLE.COM.
Но эти серверы имен не играют в мяч, все четыре возвращают SERVFAIL для
$ dig @ns4.google.com 194.173.in-addr.arpa. soa
Помимо "грубости", раньше это нарушало политику ARIN, но больше не делает. Но другие зоны работают, попробуйте 46.194.173.in-addr.arpa. или 65.194.173.in-addr.arpa. так что это кажется преднамеренным и избирательным.
Причина стала очевидной, когда я посмотрел на конфигурацию DNS-серверов Windows (что-то потерялось в устном отчете).
Каждый контроллер домена был настроен для пересылки запросов не только к двум кэширующим серверам привязки, но и ко всем другим DNS-серверам Windows. Для запросов, которые были успешными (включая NXDOMAIN), которые будут работать нормально, поскольку серверы Bind будут отвечать, и мы никогда не перейдем к другому DNS Windows. Однако для вещей, которые вернули SERVFAIL, один сервер будет запрашивать все остальные, которые, в свою очередь, запрашивают серверы привязки. Я действительно удивлен, что это не причинило больше боли.
Мы уберем лишнюю пересылку, и я полностью ожидаю, что количество запросов резко сократится.