Это странно
Я установил это давным-давно, на centos5. Из того, что я помню, раньше работало. В течение некоторого времени это не так. Мне только что сообщили, так что понятия не имею, что изменилось, когда это сделало это не работает.
Пока что: локально работает нормально (udp и tcp) (dig @localhost) Отлично работает с внешнего интерфейса, через tcp (dig @YYYY +tcp), но не отвечает с внешнего через udp (dig @YYYY)
Для этого домена был опробован dig как из внешнего источника linux, так и из онлайн-инструмента. Онлайн-инструмент был проверен для работы с другим доменом и 8.8.8.8 в качестве сервера. Кроме того, чтобы исключить удаление UDP от провайдера, я проверил dig в другом домене с @ 8.8.8.8, и это сработало.
Я не думаю, что брандмауэр является проблемой, потому что tcpdump говорит:
[root@localhost etc]# tcpdump -n udp "dst port 53 or src port 53"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
02:26:43.871668 IP X.46044 > 192.168.0.101.domain: 42303+ A? <<MY_DOMAIN>>. (32)
02:26:43.874388 IP 192.168.0.101.domain > XXXX.46044: 42303*- 1/1/1 A YYYY (83)
02:26:48.874140 IP X.46044 > 192.168.0.101.domain: 42303+ A? <<MY_DOMAIN>>. (32)
02:26:48.876168 IP 192.168.0.101.domain > XXXX.46044: 42303*- 1/1/1 A YYYY (83)
02:26:53.876772 IP X.46044 > 192.168.0.101.domain: 42303+ A? <<MY_DOMAIN>>. (32)
02:26:53.878231 IP 192.168.0.101.domain > XXXX.46044: 42303*- 1/1/1 A YYYY (83)
3 packets captured
3 packets received by filter
0 packets dropped by kernel
и, включение rndc querylog показывает в сообщениях:
Feb 5 02:14:48 localhost named[15570]: starting BIND 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 -u named -t /var/named/chroot
Feb 5 02:14:48 localhost named[15570]: adjusted limit on open files from 1024 to 1048576
Feb 5 02:14:48 localhost named[15570]: found 1 CPU, using 1 worker thread
Feb 5 02:14:48 localhost named[15570]: using up to 4096 sockets
Feb 5 02:14:48 localhost named[15570]: loading configuration from '/etc/named.conf'
Feb 5 02:14:48 localhost named[15570]: using default UDP/IPv4 port range: [1024, 65535]
Feb 5 02:14:48 localhost named[15570]: using default UDP/IPv6 port range: [1024, 65535]
Feb 5 02:14:48 localhost named[15570]: no IPv6 interfaces found
Feb 5 02:14:48 localhost named[15570]: listening on IPv4 interface lo, 127.0.0.1#53
Feb 5 02:14:48 localhost named[15570]: listening on IPv4 interface eth0, 192.168.0.101#53
Feb 5 02:14:48 localhost named[15570]: command channel listening on 127.0.0.1#953
Feb 5 02:14:48 localhost named[15570]: zone <<MY_DOMAIN>>/IN: loaded serial 107
Feb 5 02:14:48 localhost named[15570]: running
Feb 5 02:15:06 localhost named[15570]: isc_log_open 'named.run' failed: permission denied
Feb 5 02:15:06 localhost named[15570]: query logging is now on
Feb 5 02:15:16 localhost named[15570]: client XXXX#43793: query: <<MY_DOMAIN>> IN A +
Таким образом, он получает запрос. Кажется, что он также отвечает, но, насколько я могу судить, пакеты не сбрасываются. iptables настроен с OUTPUT ACCEPT, и для выходной цепочки нет правил. Я также попытался с отключенным брандмауэром и не сделал разницы, так что я снова сомневаюсь, что это от iptables.
Так почему же хак не проходит через udp?
любые указатели приветствуются. У меня нет идей.
физическая настройка: INET <-> маршрутизатор <-> сервер
маршрутизатор Trendnet TW100-94w1CA, если это имеет значение.