Bind9/iptables Seeking Enlightenment

I'm trying to get a better understanding of how bind9 works (and doesn't work) with iptables. I have done the following experiment and need a guru to help explain the results.

I have Bind9 up and running well on a standalone laptop. No recursion, no connection to the outside world. It responds properly when accessed as localhost or by IP or servername as well as finding a default server on its own. Works fine for both forward and reverse lookups.

Start iptables, flush everything, set all policies to accept. We're wide open here. Bind9 still looking good.

Now set the nat OUTPUT policy or the nat POSTROUTING policy to drop. Suddenly Bind9 can't find any servers, and within a minute or two the whole system freezes. Why? What is Bind9 doing in the nat tables? Why does whatever Bind9 is doing cause the entire system to freeze?

Any insight appreciated.

Cheers.

What does your IPTABLES rules look like for this machine?

When iptables looks like this:

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Chain PREROUTING (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 18 packets, 1080 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 18 packets, 1080 bytes)
pkts bytes target prot opt in out source destination

Bind9 works fine. But when I change the nat POSTROUTING policy to DROP like this:

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Chain PREROUTING (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Bind9 breaks and the system freezes.

Since Bind9 listens on port 53, then conducts ongoing communications on randomly selected unprivileged ports, does it use the nat tables to route that? I think I'll try opening nat postrouting on the unprivileged ports for established and related packets and just see if it makes a difference.

Cheers

OK, I think we're done here.

Watching the iptables listing, each time a DNS request is processed a udp packet transits the nat OUTPUT and nat POSTROUTING chains. I still don't know why Bind9 does this, but I can watch it happen. Thus, to have Bind9 work I have to keep the nat policies open or write some rules to let DNS packets through.

The freeze is not related to Bind9. If I turn Bind9 off and then set nat POSTROUTING policy to DROP, after a few minutes the system will freeze. It seems to be related to file manager or terminal activity where I am using root privileges (sudo). Because of this, the nat policies will have to be left open anyway, so the Bind9 problem becomes a non-issue.

Thanks for the help.

Bind is not doing this. This is the normal flow for all packets;

-> preroute -> rules -> postroute ->