bind/named not working on UDP from external

Question

This one is weird.

I've set this up a long while ago, on a centos5. From what I remember, it used to work. For some time now, it's not. I've just been informed so no clue what changed when that made it not work.

So far: It's working fine locally (udp and tcp) (dig @localhost) It's working fine from external, via tcp (dig @YYYY +tcp) But it's not responding from external via udp (dig @YYYY)

For this domain, dig was tried from both an external linux source and an online tool. The online tool was verified to work with another domain and 8.8.8.8 as server. Also, to rule out UDP dropping from ISP, I tested dig on another domain with @8.8.8.8 and it worked.

I don't think firewall is an issue because tcpdump says:

[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

and, enabling rndc querylog shows in messages:

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 +

So it gets the query. It appears to be answering as well, but as far as I can tell, no packets are being dropped. iptables is configured with OUTPUT ACCEPT and no rules are for the output chain. I also tried with the firewall disabled and made no difference, so again I doubt it's from iptables.

So why the hack isn't it getting through via udp?

any pointers welcome. I'm out of ideas.

physical setup is: INET <-> router <-> server

the router is a Trendnet TW100-94w1CA in case it matters.

Answer 1

This is not the first time an ISP has decided it didn't like it's users running a DNS server. Are you sure it is not also configured as an open-resolver? That's grounds to block it.

Since you implied it stopped working with no changes on your side, I would suspect a new firewall rule has been thrown in your face on the ISP side (out of your control) to block outgoing DNS /responses/. Firewalls these days can do that via deep packet inspection and leave your outbound /queries/ working fine.

Only way to verify that is to be able to see DNS response packets make it past your upstream (ADSL?) router.

Of course, there could be a number of other root causes, but seems unlikely at this point.