У меня есть веб-сайт, который я размещаю сам, и я использую 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.
Мои вопросы:
Я проверил свои серверы пересылки в 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;
Скорее всего, ваш сервер пытается разрешить "target-express.com", но не работает. Причина сбоя в том, что серверы NS для 'target-express.com' неправильно настроены. (Погуглите "хромые серверы"). Выполнение «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 ;; global options: +cmd . 16978 IN NS d.root-servers.net. . 16978 IN NS i.root-servers.net. . 16978 IN NS f.root-servers.net. . 16978 IN NS b.root-servers.net. . 16978 IN NS a.root-servers.net. . 16978 IN NS k.root-servers.net. . 16978 IN NS l.root-servers.net. . 16978 IN NS h.root-servers.net. . 16978 IN NS e.root-servers.net. . 16978 IN NS j.root-servers.net. . 16978 IN NS m.root-servers.net. . 16978 IN NS g.root-servers.net. . 16978 IN NS c.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 9 ms 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. ;; Received 496 bytes from 199.7.91.13#53(d.root-servers.net) in 15 ms target-express.com. 172800 IN NS sec02.ns.esat.net. target-express.com. 172800 IN NS auth02.ns.esat.net. ;; Received 120 bytes from 192.48.79.30#53(j.gtld-servers.net) in 221 ms ;; Received 36 bytes from 192.111.39.112#53(sec02.ns.esat.net) in 111 ms root@svm1010:/var/tmp# dig @sec02.ns.esat.net. target-express.com. soa +short root@svm1010:/var/tmp# dig @auth02.ns.esat.net. target-express.com. soa +short root@svm1010:/var/tmp#
Могут ли ваши серверы пересылки DNS пересылать запросы обратно на исходный сервер?
Если да, то это может быть что-то вроде проблемы, которая у меня была в прошлом году (см. DNS-серверы Windows неоднократно запрашивают записи в зоне при получении ответа SERVFAIL). Исправлено отсутствие петель пересылки. Это проявляется только как серьезная проблема с зонами, которые возвращают SERVFAIL, потому что эти ответы не будут кэшироваться.
Что касается того, что инициировало исходный запрос (а это могло быть только одно), может быть что угодно - поиск DNS для управления доступом в Интернет или что-то в этом роде.
Чтобы избежать амплификации (возможно, лучше, чем циклы), вам необходимо убедиться, что DNS-сервер, на котором вы видите эти сообщения, не пересылает запросы на сервер, который может пересылать запросы обратно. Под вашим контролем серверы, которые вы настроили на локальном DNS-сервере, или они внешние?