Bind 9.11 + iptables не отвечает на запросы

В iptables не силён, но для начала я бы попытался определить проблема в INPUT, OUTPUT или в обеих цепочках.

bind 127.0.0.1 прослушивает? Если с самого сервера сделать запрос?

Объединил бы похожие правила, например, зачем каждый протокол указывать явно?

Как определить в какой цепочке проблема? Методику подскажите пожалуйста.

На 127.0.0.1 и на интерфейсе смотрящем в локалку висит dnsmasq, он обслуживает внутреннюю зону и DHCP. Bind висит только на внешнем интерфейсе как первичный сервер зоны реального домена. Машина работает роутером. При чём вторичным серверам он зону отдаёт без проблем. Только на прямой запрос от клиента не отвечает.

Указал протоколы явно потому как -p all будет включать в себя ещё и icmp/sctp/.... Зачем, если можно ограничить всё по максимуму?

Как определить в какой цепочке проблема? Методику подскажите пожалуйста.

Сначала сделать iptables -P INPUT ACCEPT и посмотреть, если не поможет, то откатить конфиг и настроить iptables -P OUTPUT ACCEPT

Указал протоколы явно потому как -p all будет включать в себя ещё и icmp/sctp/.... Зачем, если можно ограничить всё по максимуму?

ИМХО, упростить чтение конфигурации. Для icmp --sport 53 всё равно смысла не имеет, зато число подобных строк вдвое сократится. Идея, конечно хорошая, разрешить только то что нужно, а остальное заблокировать. Только зачем такие строгие правила? ИМХО, полезнее было ограничить количество запросов в секунду, чтобы хоть немного защититься от DDOS.

Также, как вариант, настроить логирование. Тут в помощь man и гугл. Настроить логирование, чтобы убедиться, что правила работают и настроить логирование событие, которые не вписываются в твои требования.

А клиент то у тебя в какой сети находится? Похоже, что у тебя он только на WAN интерфейсе и отвечает.

Естессно если сервер смотрин только наружу, то и проверяю я клиентом снаружи. Уж это совсем элементарно.

От DDOS у бинда есть свои rate-limit, и они у меня настроены. Их думаю достаточно.

Про логирование из правила я как то забыл, щас попробую. Спасибо

Мало ли. :) Раз такие вопросы с иптаблесами возникают. :) Я ещё посмотрел, у тебя INPUT на dport 53 не разрешает. А когда коннектятся к тебе, то это как раз dport и есть. То есть dst address и dst port.

Вообще, source port у тебя рандомный для тебя будет на клиенте выбираться, а вот destination port как раз 53. Грубо говоря, у тебя там наоборот. И да, правила какие-то слишком замудрёные, можно постараться упростить.

1. Возможно какие-то еще правила iptables, покажите iptables-save
2. Возможно проблема в переменных $WAN_IF, $UNPRIV_PORTS, $WAN_IP - опять-таки смотрите iptables-save
3. запрос прилетает не на $WAN_IF && $WAN_IP - смотрите tcpdump

почему на разрешено на 53 INPUT:
iptables -A INPUT -i $WAN_IF -p tcp -m tcp --source 0/0 --sport $UNPRIV_PORTS --destination $WAN_IP --dport 53 -m conntrack --ctstate NEW -j ACCEPT;
iptables -A INPUT -i $WAN_IF -p udp -m udp --source 0/0 --sport $UNPRIV_PORTS --destination $WAN_IP --dport 53 -m conntrack --ctstate NEW -j ACCEPT;

тут же явно --destination $WAN_IP --dport 53 на обоих протоколах

или я вас неправильно понял?

С переменными всё в порядке, остальные правила с этими же переменными работают.

Упростил до безобразия:

INPUT
iptables -A INPUT -i $RED -p tcp -d $WAN_IP --dport 53 -j ACCEPT;
iptables -A INPUT -i $RED -p udp -d $WAN_IP --dport 53 -j ACCEPT;

OUTPUT
iptables -A OUTPUT -o $RED -p all -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT;

И всё равно не работает.

Так а с -P INPUT/OUTPUT ACCEPT работает или нет?

:INPUT DROP [2:112]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -p tcp -m multiport --dports 0:65535 -m set --match-set f2b-recidive src -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m multiport --dports 25,465,587,443,993,110,995 -m set --match-set f2b-postfix-bad-helo src -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m multiport --dports 80,443 -m set --match-set f2b-nginx-botsearch src -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m conntrack --ctstate INVALID -m comment --comment "Drop invalid packets" -j DROP
-A INPUT -p tcp -m conntrack --ctstate INVALID,NEW -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m comment --comment "Prevent SYN-Flood atack" -j REJECT --reject-with tcp-reset
-A INPUT -s 127.0.0.0/8 -i lo -m comment --comment "Grant all access for loppback input traffic" -j ACCEPT
-A INPUT -s 192.168.77.0/24 -i eth1 -m comment --comment "Grant all access for intranet input traffic" -j ACCEPT
-A INPUT -i eth1 -p udp -m multiport --dports 53,67,68 -m conntrack --ctstate NEW -m comment --comment "Accept DNS/DHCP UDP traffic for intranet" -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 53 -m conntrack --ctstate NEW -m comment --comment "Accept DNS TCP traffic for intranet" -j ACCEPT
-A INPUT -i eth0 -f -m comment --comment "Drop all fragmented packets" -j DROP
-A INPUT -i eth0 -m geoip --source-country CN,VN,TW,UA  -m comment --comment "Deny all traffic from restricted countries" -j DROP
-A INPUT -i eth0 -m psd --psd-weight-threshold 21 --psd-delay-threshold 300 --psd-lo-ports-weight 3 --psd-hi-ports-weight 1  -m comment --comment "Prevent port-scaning by legal method" -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,ACK FIN -m comment --comment "FIN-scan protection" -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -m comment --comment "X-scan protect" -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -m comment --comment "N-scan protect" -j DROP
-A INPUT -i eth0 -p tcp -m osf --genre NMAP -m comment --comment "NMAP OS detection protection" -j DROP
-A INPUT -s 10.0.0.0/8 -i eth0 -m comment --comment "Antispoofing Class A from internet" -j DROP
-A INPUT -s 172.16.0.0/12 -i eth0 -m comment --comment "Antispoffing Class B from internet" -j DROP
-A INPUT -s 192.168.0.0/16 -i eth0 -m comment --comment "Antispoofing Class C from internet" -j DROP
-A INPUT -s 224.0.0.0/8 -i eth0 -m comment --comment "Antispoffing Class D(multicast) from internet" -j DROP
-A INPUT -s 240.0.0.0/5 -i eth0 -m comment --comment "Antispoofing Class E from internet" -j DROP
-A INPUT -s 127.0.0.0/8 -i eth0 -m comment --comment "Antispoofing Loopback from internet" -j DROP
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 0 -m limit --limit 2/sec -m comment --comment "ICMP \'echo reply\' with some restricts" -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 8 -m limit --limit 2/sec -m comment --comment "ICMP \'echo request\' with some restricts" -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 3 -m comment --comment "ICMP \'Destination unreachable\'" -j ACCEPT
-A INPUT -i eth0 -p icmp -m icmp --icmp-type 12 -m comment --comment "ICMP \'IP Header bad\'" -j ACCEPT
-A INPUT -d 192.168.77.254/32 -i eth0 -p tcp -m tcp --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m recent --update --seconds 120 --hitcount 4 --name ssh_brutforce --mask 255.255.255.255 --rsource -m comment --comment "SSH brutforce prevent in gate.lan" -j DELUDE
-A INPUT -d 192.168.77.254/32 -i eth0 -p tcp -m tcp --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource -m comment --comment "SSH accept normal connect to gate.lan" -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m multiport --dports 80,443 -m connlimit --connlimit-above 20 --connlimit-mask 32 --connlimit-saddr -m comment --comment "Restric connects to WEB ports for 20 counts per one IP" -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m multiport --dports 80,443 -m connlimit --connlimit-above 150 --connlimit-mask 0 --connlimit-saddr -m comment --comment "Restrict all connects to WEB ports for 150 counts" -j DROP
-A INPUT -i eth0 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m multiport --dports 25,465,587,993 -m connlimit --connlimit-above 5 --connlimit-mask 32 --connlimit-saddr -m comment --comment "Restric connects to MAIL ports for 5 per one IP" -j DROP
-A INPUT -i eth0 -p udp -m udp --dport 53 -m string --hex-string "|0000ff0001|" --algo bm --to 65535 -m comment --comment "Restrict ANY request to our DNS" -j DROP
-A INPUT -i eth0 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -m recent --update --seconds 180 --hitcount 3 --name dns_any --mask 255.255.255.255 --rsource -m comment --comment "Restrict ANY request to our DNS" -j DROP
-A INPUT -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "Accept all established connection from WAN to router" -j ACCEPT
-A INPUT -i eth0 -p tcp -m conntrack --ctstate NEW -m multiport --dports 25,53,80,443,465,587,993 -m comment --comment "Accept allowed WAN TCP ports" -j ACCEPT
-A INPUT -i eth0 -p udp -m conntrack --ctstate NEW -m multiport --dports 53 -m comment --comment "Accept allowed WAN UDP ports" -j ACCEPT

-A OUTPUT -m conntrack --ctstate INVALID -j DROP
-A OUTPUT -p tcp -m conntrack --ctstate INVALID,NEW -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j REJECT --reject-with tcp-reset
-A OUTPUT -d 127.0.0.0/8 -o lo -j ACCEPT
-A OUTPUT -d 192.168.77.0/24 -o eth1 -j ACCEPT
-A OUTPUT -o eth0 -p icmp -m icmp --icmp-type 0 -m limit --limit 2/sec -m comment --comment "ICMP \'echo reply\' with some restricts" -j ACCEPT
-A OUTPUT -o eth0 -p icmp -m icmp --icmp-type 8 -m limit --limit 2/sec -m comment --comment "ICMP \'echo request\' with some restricts" -j ACCEPT
-A OUTPUT -o eth0 -p icmp -m icmp --icmp-type 3 -m comment --comment "ICMP \'destination unreachable\'" -j ACCEPT
-A OUTPUT -o eth0 -p icmp -m icmp --icmp-type 4 -m comment --comment "ICMP \'source quench\'" -j ACCEPT
-A OUTPUT -o eth0 -p icmp -m icmp --icmp-type 11 -m comment --comment "ICMP \'time-to-live exceeded\'" -j ACCEPT
-A OUTPUT -o eth0 -p icmp -m icmp --icmp-type 12 -m comment --comment "ICMP \'IP header bad\'" -j ACCEPT
-A OUTPUT -o eth0 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT

Всё не влезло, убрал цепочку FORWARD/PREROUTING и NAT. Eth0 это внешний, Eth1 внутренний

Так а с -P INPUT/OUTPUT ACCEPT работает или нет?

Да, как ни странно

Вот это не оно?

-A INPUT -i eth0 -p udp -m udp --dport 53 -m string --hex-string "|0000ff0001|" --algo bm --to 65535 -m comment --comment "Restrict ANY request to our DNS" -j DROP
-A INPUT -i eth0 -p udp -m udp --dport 53 -m conntrack --ctstate NEW -m recent --update --seconds 180 --hitcount 3 --name dns_any --mask 255.255.255.255 --rsource -m comment --comment "Restrict ANY request to our DNS" -j DROP

Вообще для наглядности тестировать лучше не так. Обнули счётчики iptables, потом попробуй сделать несколько проблемных запросов и потом посмотреть iptables -nvL --line-numbers

P.S. Запутанные у тебя настройки. Я бы порекомендовал или аккуратно всё разнести по цепочкам или, если лень вникать, взять хотя бы тот же самый ferm.

Запутанные у тебя настройки.

У меня всё по порядку, даже комментарии есть. Это вывод iptables-save. В скрипте всё более понятно и упорядочено. Два правила что вы указали откидывают запросы типа ANY. К нормальному клиентскому запросу это не относится. Для проверки я их даже отключал.

Вообще для наглядности тестировать лучше не так. Обнули счётчики iptables, потом попробуй сделать несколько проблемных запросов и потом посмотреть iptables -nvL --line-numbers

Уже делал так, ни один из счётчиков на правилах не меняется.

У меня всё по порядку, даже комментарии есть. Это вывод iptables-save.

iptables-save показывает правила в том порядке, в котором они у тебя в данный момент реально работают. Таким образом разрешающее правило для 53 udp у тебя в самом конце и под него пакет попадёт только в том случае, если не попал ни под одно вышестоящее.

Уже делал так, ни один из счётчиков на правилах не меняется.

Счётчики не растут вообще ни на каких правилах? Что будет, если эксперимента ради добавить -I INPUT -p udp -m udp --dport 53 -j ACCEPT руками на живую?

iptables-save показывает правила в том порядке, в котором они у тебя в данный момент реально работают. Таким образом разрешающее правило для 53 udp у тебя в самом конце и под него пакет попадёт только в том случае, если не попал ни под одно вышестоящее.

В курсе. Исходя из нужного мне порядка всё и стоит. Запрещающее правило жёстко описывает пакет содержащий HEX-последовательность, которой по определению быть не может в стандартном запросе. Исходя из этого пакеты нормального запроса доберутся до разрешающего правила. К тому же я у же написал вам, что ради эксперимента я уже отключал эти два правила. Бестолку.

Что будет, если эксперимента ради добавить

Щас попробую. Не помогло

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

Но вообще странно, раз при политике ACCEPT работает, а при явном первом разрешающем правиле - нет. Очень странно.

Была ещё идея, может что-то в таблице nat в PREROUTING'е мешает, но тогда бы оно при любых правилах filter не работало. У меня идеи кончились.

Выше я ответил: с политикой по умолчанию ACCEPT, всё нормально работает.

Логика подсказывает, что ни под одно запрещающее правило нормальный запрос к DNS не попадает. И он пролетает только по дефолтной политике. Значит просто ему не хватает какого то разрешающего правила при политике DROP. Логично же? Так вот какого правила то не хватает? Я уже всю башку сломал.

У меня идеи кончились

Вот по этому я здесь и спросил, потому как у меня тоже идеи кончились

Да. Именно по этому я и предложил попробовать поставить в начало максимально простое разрешающее правило. И вот это-то и странно, что на него ничего не попало.

В порядке предположения: UDP это стейтлесс протокол, а у тебя в цепочке output разрешаются только ответы с стейтами new, related, estab, возможно это мешает. Вполне вероятно, что я вру и с твоей стороны было бы проще поставить conntrack-tools и посмотреть на стейты «соедиенений».

Да и вообще — фильтровать OUTPUT это как-то некомильфо с моей точки зрения.

Если бы проблема была в OUTPUT при экспериментах росли бы счётчики INPUT.

Может, показалось. Когда смотрел, было по другому.

Ну так, по идее, должен работать, наверное. Что логи говорят?

Оставь только то, что DNS касается и играйся. Тут куча правил, надо понять проблема в них или в чём-то другом.

И все-таки если как написали выше в правиле -I INPUT -p udp -m udp --dport 53 -j ACCEPT не растут счетчики при запросе, то остается либо mangle у INPUT либо PREROUTING

В прероутинге (только у таблицы NAT) у меня только редирект на SSH и FTP снаружи на локальные сервера. В других таблицах prerouting пустой. Mangle вобще не трогал, девственно чиста по дефолту, тем более что в скрипте перед назначением политик по умолчанию я все таблицы сбрасываю, в том числе и mangle. Использую только таблицы filter и nat.

Вот мой PREROUTING(NAT)
iptables -t nat -A PREROUTING -i eth0 --dst $WAN_IP -p tcp -m tcp --dport $SSH_PORT -j DNAT --to-destination $LAN_IP:22 -m comment --comment «SSH redirect to lan»;
iptables -t nat -A PREROUTING -i eth0 --dst $WAN_IP -p tcp -m tcp --dport $SSH_PORT_S1 -j DNAT --to-destination $LOCAL_S1:22 -m comment --comment «SSH redirect to lan»;
iptables -t nat -A PREROUTING -i eth0 --dst $WAN_IP -p tcp -m tcp --dport $SSH_PORT_S2 -j DNAT --to-destination $LOCAL_S2:22 -m comment --comment «SSH redirect to lan»;

iptables -t nat -A PREROUTING -i eth0 --dst $WAN_IP -p tcp -m multiport --dports $FTP_PORTS -j DNAT --to-destination $LOCAL_S1 -m comment --comment «FTP redirect to lan»;

iptables -t nat -A PREROUTING -i eth0 --dst $WAN_IP -p tcp -m multiport --dport $PLEX_PORT -j DNAT --to-destination $LOCAL_S1 -m comment --comment «PLEX redirect to lan»;

Может, показалось. Когда смотрел, было по другому.

:-) Ну так я ж написал выше, что изменил/упростил правила. Так что не показалось.

Поставил действие LOG на строки правил NDS:

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j LOG
iptables -A INPUT -i eth0 -p udp -m udp --dport 53 -j LOG

iptables -A INPUT -i eth0 -p tcp -m tcp --sport 1024:65535 -j LOG
iptables -A INPUT -i eth0 -p udp -m udp --sport 1024:65535 -j LOG

Поставил их самыми первыми в таблице. В логе ТИШИНА. То есть получается запросы просто тупо не приходят на 53 порт! WHY!? Я понимаю провайдер может в своей подсети рубить весь трафик по udp на 53 порт. Но проваливаются без результата даже локальные запросы на внешний интерфейс.

Я в ступоре

P.S. Обнаружил на втором сервере ровно ту же ситуацию. Системы разные, на одной Debian 9 на второй Ubuntu 18. Это точно проблема iptables. Правила файервола на обеих машинах очень похожи.

Если поставить политику ACCEPT и на INPUT и на OUTPUT, то в логе вот что:

запрос
IN=enp5s2 OUT= SRC=XXX.XXX.XXX.XXX DST=XXX.XXX.XXX.XXX LEN=86 TOS=0x00 PREC=0x00 TTL=54 ID=19485 PROTO=UDP SPT=48516 DPT=53 LEN=66

ответ
IN= OUT=enp5s2 SRC=XXX.XXX.XXX.XXX DST=XXX.XXX.XXX.XXX LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=63583 DF PROTO=UDP SPT=13245 DPT=53 LEN=47

и запрос пролетает, и bind отвечает. Если выставить политику DROP то в логах вобще тихо.

С портами в правилах всё правильно, судя по тому какие в логе запрашиваются. Единственное что насторожило, это поле IN=. Оно пустое.

P.P.S.Понял строка лога от правила INPUT содержит пустое поле OUT. Строка лога от правила OUTPUT содержит пустое поле IN. Так что всё в порядке.

this

IN=enp5s2

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

Я просто лог привёл с другой машины

Замечательно. Давайте все-таки разбираться с той про которую уже что-то написали. Начнем сначала
iptables -I INPUT -i eth0 -p udp -m udp --dport 53 -j LOG Именно -I а не -A.
При политике INPUT DROP Ничего не пишет в лог? А при политеке INPUT ACCEPT пишет? Покажите плиз выхлоп.

И в обоих случаях tcpdump -ntpi eth0 udp port 53

политика ACCEPT, правила:

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j LOG;
iptables -A INPUT -i eth0 -p udp -m udp --dport 53 -j LOG;

в логах:
Jan 24 14:13:26 gate kernel: [252765.943564] IN=eth0 OUT= MAC=00:80:48:c1:f5:98:00:22:56:ba:47:3f:08:00 SRC=XXX.XXX.XXX.XXX DST=XXX.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=60 ID=35195 DF PROTO=TCP SPT=55427 DPT=53 WINDOW=260 RES=0x00 ACK URGP=0
Jan 24 14:13:58 gate kernel: [252797.849700] IN= OUT=eth0 SRC=XXX.XXX.XXX.XXX DST=XXX.XXX.XXX.XXX LEN=68 TOS=0x00 PREC=0x00 TTL=64 ID=3315 DF PROTO=UDP SPT=8207 DPT=53 LEN=48

странно но tcpdump никак не реагирует на посланный запрос, только разный левак, и ни строчки по моему запросу. Bind на запрос отвечает.

При политике DROP в логах тишина и tcpdump ведёт себя так же, ответа от binda нет.

Вру, tcpdump показывает запрос и ответ при политике ACCEPT. ПРи политике DROP ничего относительно моего запроса нет. Не хочу вываливать сюда выхлоп tcpdump, там основная инфа это адреса, кои светить нет желания.

если мне не изменяет память, то вот это:

iptables -P INPUT DROP;
iptables -P OUTPUT DROP;
iptables -P FORWARD DROP;

ставь в конце, а не в начале.

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j LOG;

Не -A а -I выполнить при уже загруженных ваших правилах

Разницы никакой, хоть в середине. Это не цепочки. Зачем это делают (прописывают в конце) к данной проблеме не имеет никакого отношения.

Не -A а -I выполнить при уже загруженных ваших правилах

Выше уже советовали и я делал. Без разницы, что в самом начале правила что в том месте где я их определил.

Вся петрушка в том, что все остальные сервисы (для которых есть правила в файерволе) работают нормально, smtp, urd, submission, imaps, ssh, ftp. Проблема точно не сети и маршрутизации. Тут похоже что бинду чего то не хватает. Причём именно в клиентском соединении, потому как слейвам он зону нормально передаёт, только что проверил.

Если все так как вы написали, то у меня мыслей нет.

Тут похоже что бинду чего то не хватает

Бинд тут не причем, у вас может вообще ничего не слушать порт, пакет все равно прилетит в INPUT т.е. при первом правиле в цепочке INPUT -i eth0 -p tcp -m tcp --dport 53 -j LOG в логе должна появиться запись.

Давайте все-таки разбираться с той про которую уже что-то написали. Начнем сначала

Что думаете об этом? https://kb.isc.org/docs/aa-01183 Может и не стоит conntrack на udp вешать?

Если бы дело было в conntrack то изменение полиси DROP->ACCEPT не влияло на не-работоспособность->работоспособность.

Если бы дело было в conntrack то изменение полиси DROP->ACCEPT не влияло на не-работоспособность->работоспособность.

Я до сих пор не понял в этом топике, был ли вообще от ТСа ответ на первые коменты: какие из input/output или только когда оба влияет на.

Ну исходя из того как пишет TC, если прописываем первыми правилами

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j LOG;
iptables -A INPUT -i eth0 -p udp -m udp --dport 53 -j LOG;

при полиси DROP в лог ничего не попадает
при изменении на ACCEPT в лог пишется

Jan 24 14:13:26 gate kernel: [252765.943564] IN=eth0 OUT= MAC=00:80:48:c1:f5:98:00:22:56:ba:47:3f:08:00 SRC=XXX.XXX.XXX.XXX DST=XXX.XXX.XXX.XXX LEN=52 TOS=0x00 PREC=0x00 TTL=60 ID=35195 DF PROTO=TCP SPT=55427 DPT=53 WINDOW=260 RES=0x00 ACK URGP=0
Jan 24 14:13:58 gate kernel: [252797.849700] IN= OUT=eth0 SRC=XXX.XXX.XXX.XXX DST=XXX.XXX.XXX.XXX LEN=68 TOS=0x00 PREC=0x00 TTL=64 ID=3315 DF PROTO=UDP SPT=8207 DPT=53 LEN=48

Я до сих пор не понял в этом топике, был ли вообще от ТСа ответ на первые коменты: какие из input/output или только когда оба влияет на.

Я ответил - только когда и INPUT и OUTPUT в ACCEPT. Если по одному то не работает.

Сейчас отметил закономерность. С внешнего хоста (географически далеко, терминалом) запрос от dig не получает ответа. Локально на серваке запрос dig на внешний IP сервера тоже остаётся без ответа. А вот если запустить dig с хоста из локалки (в той же подсети что и сервер) и тоже указать внешний IP сервера, то опа, получаю ответ.
Чёт я запутался. Ну допустим снаружи не достучаться до 53 порта можно по вине провайдера, который возможно бессовестно рубит UDP53 трафик на своих маршрутизаторах. Но почему локально запрос не прокатывает? Может я чего не знаю?

Я ответил - только когда и INPUT и OUTPUT в ACCEPT. Если по одному то не работает.

Когда всего две политики, то логика то простая — откройте вторую политику и чините пока первую.

Чёт я запутался. Ну допустим снаружи не достучаться до 53 порта

Но как это у ваших провайдеров по пути можно поменять вашей политикой? Тяжело вам что-то советовать, когда весь топик какая-то каша. Ну уберите в файрволе ВСЁ, добавляйте по двум строкам, одна с логированием, вторая с правилом и ищите где оно ломается. Я тут дал доку, где вполне разумные и законченные правила для DNS от авторов bind-а приведены. Они вполне достаточны.

Спасибо за доку. Попробую рекомендации