This is a nice question.

As a matter of fact, tcpdump is the first software found after the wire (and the NIC, if you will) on the way IN, and the last one on the way OUT.

Wire -> NIC -> tcpdump -> netfilter/iptables

iptables -> tcpdump -> NIC -> Wire

Thus it sees all packets reaching your interface, and all packets leaving your interface. Since packets to port 53 do not get a reply, as seen by tcpdump, you have successfully verified that your iptables rules have been correctly configured.

EDIT

Perhaps I should add a few details. tcpdump is based on libpcap, a library which creates a packet socket. When a regular packet is received in the network stack, the kernel first checks to see whether there is a raw socket interested in the newly arrived packet and, if there is one, it forwards the packet to that packet socket. If the option ETH_P_ALL is chosen, then all protocols go thru the packet socket.

libpcap implements one such packet socket with the option activated, keeps a copy for its own use, and duplicates the packet back onto the network stack, where it is processed by the kernel in the usual way, including passing it first to netfilter, the kernel-space counterpart of iptables. Same thing, in reverse order (i.e., first netfilter then last the passage thru the packet socket), on the way out.

Is this prone to hacking? But of course. There are certainly proof-of-concept rootkits using libpcap to intercept communications destined to the rootkit before the firewall can lay its hand on them. But even this pales in comparison with the fact that a simple Google query unearths working code hiding traffic even from libpcap. Still, most professionals think the advantages vastly outweigh the disadvantages, in debugging network packet filters.

This is a nice question.

As a matter of fact, tcpdump is the first software found after the wire (and the NIC, if you will) on the way IN, and the last one on the way OUT.

Wire -> NIC -> tcpdump -> netfilter/iptables

iptables -> tcpdump -> NIC -> Wire

Thus it sees all packets reaching your interface, and all packets leaving your interface. Since packets to port 53 do not get a reply, as seen by tcpdump, you have successfully verified that your iptables rules have been correctly configured.

EDIT

Perhaps I should add a few details. tcpdump is based on libpcap, a library which creates a packet socket. When a regular packet is received in the network stack, the kernel first checks to see whether there is a packet socket interested in the newly arrived packet and, if there is one, it forwards the packet to that packet socket. If the option ETH_P_ALL is chosen, then all protocols go thru the packet socket.

libpcap implements one such packet socket with the option activated, keeps a copy for its own use, and duplicates the packet back onto the network stack, where it is processed by the kernel in the usual way, including passing it first to netfilter, the kernel-space counterpart of iptables. Same thing, in reverse order (i.e., first netfilter then last the passage thru the packet socket), on the way out.

Is this prone to hacking? But of course. There are certainly proof-of-concept rootkits using libpcap to intercept communications destined to the rootkit before the firewall can lay its hand on them. But even this pales in comparison with the fact that a simple Google query unearths working code hiding traffic even from libpcap. Still, most professionals think the advantages vastly outweigh the disadvantages, in debugging network packet filters.

This is a nice question.

As a matter of fact, tcpdump is the first software found after the wire (and the NIC, if you will) on the way IN, and the last one on the way OUT.

Wire -> NIC -> tcpdump -> netfilter/iptables

iptables -> tcpdump -> NIC -> Wire

Thus it sees all packets reaching your interface, and all packets leaving your interface. Since packets to port 53 do not get a reply, as seen by tcpdump, you have successfully verified that your iptables rules have been correctly configured.

This is a nice question.

As a matter of fact, tcpdump is the first software found after the wire (and the NIC, if you will) on the way IN, and the last one on the way OUT.

Wire -> NIC -> tcpdump -> netfilter/iptables

iptables -> tcpdump -> NIC -> Wire

Thus it sees all packets reaching your interface, and all packets leaving your interface. Since packets to port 53 do not get a reply, as seen by tcpdump, you have successfully verified that your iptables rules have been correctly configured.

EDIT

Perhaps I should add a few details. tcpdump is based on libpcap, a library which creates a packet socket. When a regular packet is received in the network stack, the kernel first checks to see whether there is a raw socket interested in the newly arrived packet and, if there is one, it forwards the packet to that packet socket. If the option ETH_P_ALL is chosen, then all protocols go thru the packet socket.

libpcap implements one such packet socket with the option activated, keeps a copy for its own use, and duplicates the packet back onto the network stack, where it is processed by the kernel in the usual way, including passing it first to netfilter, the kernel-space counterpart of iptables. Same thing, in reverse order (i.e., first netfilter then last the passage thru the packet socket), on the way out.

Is this prone to hacking? But of course. There are certainly proof-of-concept rootkits using libpcap to intercept communications destined to the rootkit before the firewall can lay its hand on them. But even this pales in comparison with the fact that a simple Google query unearths working code hiding traffic even from libpcap. Still, most professionals think the advantages vastly outweigh the disadvantages, in debugging network packet filters.