У меня есть веб-сайт, который я размещаю сам, и я использую bind9 в качестве своего DNS-сервера (размещаю собственные серверы имен и т. д.).
У меня возникла проблема с пропускной способностью трафика, и мой системный журнал полон следующих проблем:
error (unexpected RCODE REFUSED) resolving 'target-express.com/AAAA/IN': 193.95.142.60#53
error (unexpected RCODE REFUSED) resolving 'target-express.com/A/IN': 2001:7c8:3:2::5#53
В сегодняшнем системном журнале есть144258примеры этого, все связаны с target-express.com.
У меня есть вопросы:
- Могу ли я что-нибудь сделать с помощью брандмауэра или конфигурации привязки, чтобы остановить это?
- Почему моя настройка привязки пытается разрешить target-express.com (это не мой домен, я тут ни при чем).
Я проверил свои серверы пересылки в named.conf, и ни один из них не соответствует IP-адресам, отображаемым в журналах (это все по сути разные IP-адреса, а не просто 193.95.142.60).
Мой iptables гласит:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere loopback/8 reject-with icmp-port-unreachable
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT icmp -- anywhere anywhere icmp echo-request
LOG all -- anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: "
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ОБНОВЛЯТЬ:
Я попробовал следующее в named.conf.options, чтобы заблокировать рекурсию.
allow-transfer {"none";};
allow-recursion {"none";};
recursion no;
После того, как я это сделал, в системном журнале я вижу следующее:
Mar 4 00:02:21 mail named[29037]: client 127.0.0.1#42139: query (cache) '24.124.41.103.in-addr.arpa/PTR/IN' denied
Mar 4 00:02:22 mail named[29037]: client 127.0.0.1#58405: query (cache) '45.124.41.103.in-addr.arpa/PTR/IN' denied
Mar 4 00:02:24 mail named[29037]: client 127.0.0.1#48692: query (cache) '106.49.174.61.in-addr.arpa/PTR/IN' denied
Чтобы избавиться от вышесказанного, я добавил:
additional-from-cache no;
решение1
Могут ли ваши DNS-серверы пересылать запросы обратно на исходный сервер?
Если так, то это может быть похоже на проблему, с которой я столкнулся в прошлом году (см.DNS-серверы Windows неоднократно запрашивают записи в зоне, когда получают ответ SERVFAIL). Исправление заключается в том, чтобы не иметь циклов пересылки. Это проявляется как значительная проблема только с зонами, которые возвращают SERVFAIL, поскольку эти ответы не будут кэшироваться.
Что касается того, что инициировало первоначальный запрос (а он мог быть только один), то это могло быть что угодно — поиск в DNS для контроля веб-доступа или что-то в этом роде.
Чтобы избежать усиления (возможно, это лучшее описание, чем циклы), вам нужно убедиться, что DNS-сервер, на котором вы видите эти сообщения, не пересылает запросы на сервер, который может пересылать запросы обратно. Находятся ли серверы, которые вы настроили на локальном DNS-сервере, под вашим контролем или они внешние?
решение2
Скорее всего, ваш сервер пытается разрешить 'target-express.com' и терпит неудачу. Причина неудачи в том, что NS-серверы для 'target-express.com' не настроены должным образом. (Google 'lame servers'). Выполнение 'dig +trace' показывает две NS-записи для домена, но если вы запросите эти домены, ответа не будет.
Теперь вопрос в том, кто опрашивает ваш сервер -
1. Законные внутренние пользователи/приложения — я бы не беспокоился об этом.
2. Неавторизованные внешние пользователи - Ваши DNS-серверы должны разрешать разрешение только для доменов, для которых они являются авторитетными. Если вы не намерены иметь открытый DNS-сервер, то установите ограничение в вашей DNS-конфигурации, чтобы только разрешенные хосты могли использовать сервер для рекурсивных запросов.
root@svm1010:/var/tmp# dig @8.8.8.8 target-express.com NS +short root@svm1010:/var/tmp# dig +trace target-express.com NS ; > DiG 9.7.0-P1 > +trace target-express.com NS ;; глобальные параметры: +cmd . 16978 В NS d.root-servers.net. . 16978 В NS i.root-servers.net. . 16978 В NS f.root-servers.net. . 16978 В NS b.root-servers.net. . 16978 В NS a.root-servers.net. . 16978 В NS k.root-servers.net. . 16978 В NS l.root-servers.net. . 16978 В NS h.root-servers.net. . 16978 В NS e.root-servers.net. . 16978 В NS j.root-servers.net. . 16978 В NS m.root-servers.net. . 16978 В NS g.root-servers.net. . 16978 В NS c.root-servers.net. ;; Получено 228 байт от 8.8.8.8#53(8.8.8.8) за 9 мс com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. ;; Получено 496 байт от 199.7.91.13#53(d.root-servers.net) за 15 мс target-express.com. 172800 В NS sec02.ns.esat.net. target-express.com. 172800 В NS auth02.ns.esat.net. ;; Получено 120 байт от 192.48.79.30#53(j.gtld-servers.net) за 221 мс ;; Получено 36 байт от 192.111.39.112#53(sec02.ns.esat.net) за 111 мс root@svm1010:/var/tmp# dig @sec02.ns.esat.net. target-express.com. соа +короткий root@svm1010:/var/tmp# dig @auth02.ns.esat.net. target-express.com. соа +короткий root@svm1010:/var/tmp#