Why does TransparentProxy working with `nameserver 127.0.0.1` but doesn't working with iptables redirects?

Question

This my second question is a continuation of my first one.

Setup is default Kali 2 and configured anonymous user from TransparentProxy manual on it.

While I'm using nameserver 127.0.0.1 in /etc/resolv.conf - everything is fine. All console network-tools like dig, nslookup, host, etc, are working normally with resolving *.onion domains into IP addresses.

But, If dhclient rewriting /etc/resolv.conf with my local DNS-servers, this idyll disappearing...

As you can read from my first question, I'm catching DNS-requests with Wireshark on lo-interface. dig to *.onion domains - redirected to lo by iptablres well, but other network-tools - not.

Why does iptables redirect works with every other domains, but does not works with *.onion and requires nameserver 127.0.0.1?

Or

My question may sounds like: Why does nameserver 127.0.0.1 exists in TransparentProxy configuration, if iptables already configured to redirect every DNS-request to any IP-address to loop-back:53?

EDIT: Specially for @canonizing ironize:

$IPT -t nat -A OUTPUT ! -o lo -p tcp -m owner --uid-owner anonymous -m tcp -j REDIRECT --to-ports 9040
$IPT -t nat -A OUTPUT -p udp -m owner --uid-owner anonymous -m udp --dport 53 -j REDIRECT --to-ports 53
$IPT -t filter -A OUTPUT -p tcp -m owner --uid-owner anonymous -m tcp --dport 9040 -j ACCEPT
$IPT -t filter -A OUTPUT -p udp -m owner --uid-owner anonymous -m udp --dport 53 -j ACCEPT
$IPT -t filter -A OUTPUT ! -o lo -m owner --uid-owner anonymous -j REJECT

Anyway, I can not find difference between *.onion domains and other... And how does this difference depend on /etc/resolv.conf.

Answer 1

@canonizing ironize was right. It is my Setup. My mistake.

I've used suricata IDS in inline mode with default drop policy for almost every available rule.

So, rule number 2014939:

emerging-policy.rules:#drop udp $HOME_NET any -> any 53 (msg:"ET POLICY DNS Query
for TOR Hidden Domain .onion Accessible Via TOR"; content:"|01 00 00 01 00 00 00 
00 00 00|"; depth:10; offset:2; content:"|05|onion|00|"; fast_pattern; distance:0; 
reference:url,en.wikipedia.org/wiki/.onion; classtype:policy-violation; 
sid:2014939; rev:1;

Anyway, it is interesting, because dig's request was working:

<\331\1 \0\1\0\0\0\0\0\1\20facebookcorewwwi\5onion\0\0\1\0\1\0\0)\20\0\0\0\0\0\0\0

And host's request was not:

9\307\1\0\0\1\0\0\0\0\0\0\20facebookcorewwwi\5onion\0\0\1\0\1

It is this place in rule:

content:"|01 00 00 01 00 00 00 00 00 00|"; 
depth:10; 
offset:2; 
content:"|05|onion|00|"; 
fast_pattern; distance:0;

Probably, dig as a modern tool using more robust query 01000001 and it does not match old version of emerging-policy rules.

Thanx everybody. I dive. Ai ai, skipper!

Answer 2

My good advice to you - use local instance of Bind and route all DNS queries through it. I'm using it quite for a long time - no problems so far. And - dhclient will not vandalize resolv conf after this:

chattr +i /etc/resolv.conf