DNS

[flexibeast]

During the last couple of days i've been trying to set up a DNS server (specifically, BIND). And i'm completely stumped.

named(8) is running fine, as shown by the output of lsof -iUDP:53:

named   8842 named   20u  IPv4 7765318       UDP [host]:domain
named   8842 named   22u  IPv4 7765320       UDP [host]:domain
named   8842 named   24u  IPv4 7765322       UDP *:domain

and dig(1) seems to be working properly, since running dig -b 127.0.0.1 @127.0.0.1 localhost followed by tshark -i lo -f 'port 53' produces:

Capturing on lo
  0.000000    127.0.0.1 -> 127.0.0.1    DNS Standard query A localhost
  5.000241    127.0.0.1 -> 127.0.0.1    DNS Standard query A localhost
 10.001650    127.0.0.1 -> 127.0.0.1    DNS Standard query A localhost
3 packets captured

but the result returned by dig is:

; <<>> DiG 9.3.1 <<>> -b 127.0.0.1 @127.0.0.1 localhost
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

Now the obvious possible problem here is the firewall, but iptables -vL INPUT gives us:

 pkts bytes target     prot opt in     out     source               destination         
1819K  705M ACCEPT     all  --  lo     any     anywhere             anywhere

and anyway, Privoxy is communicating with Squid via loopback just fine.

What am i missing here? If anyone has any suggestions, i'd be most interested to hear them . . . .
 

Comments

[omnifarious.livejournal.com]

I still think the culprit is iptables.

Do iptables-save and look at the output for where the INPUT and OUTPUT tables are set up.

BTW, thanks for showing me the neat lsof command line. I didn't realize it could do that. I normally just use it to figure out who's keeping me from unmountnig something.

[flexibeast.livejournal.com]

Do iptables-save and look at the output for where the INPUT and OUTPUT tables are set up.

Not sure what you mean by this; my iptables setup is one i created myself and which is automatically loaded on boot. If you mean that i should thus examine the entries relating to the INPUT and OUTPUT chains, then the setup is:

*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT ACCEPT
:BLACKLIST
[snip to first line of INPUT table]
-A INPUT -i lo -j ACCEPT

and there are no rules defined for the OUTPUT chain . . . .
BTW, thanks for showing me the neat lsof command line. I didn't realize it could do that. I normally just use it to figure out who's keeping me from unmountnig something.

Heh, me too - i often use netstat for checking who's listenting where, but lsof was what came to mind first in this particular instance. :-)

[omnifarious.livejournal.com]

Interesting. My next step would be stracing the named process to see if it's really doing the 'send' or 'write' call to send the answer back.

[omnifarious.livejournal.com]

Not sure what you mean by this; my iptables setup is one i created myself and which is automatically loaded on boot. If you mean that i should thus examine the entries relating to the INPUT and OUTPUT chains, then the setup is:

I've sometimes noticed iptables rules can do things you aren't expecting, or there may be rules there you don't remember putting in. But, of course, the first rule in your INPUT table is quite clear and obviously makes sure that no other rules could possibly be causing you a problem.

[flexibeast.livejournal.com]

Good idea! Unfortunately, attaching strace to the named process and then running dig produced no output from strace, even without using the -e trace=[syscall] option . . . . :-(

[omnifarious.livejournal.com]

That tells you something mighty interesting right there. There should've at least been a call to 'recv' or 'read' or something. Hmmm... Two options, named is threaded and strace isn't capturing all the threads. Or named isn't actually getting the packets from dig.

[flexibeast.livejournal.com]

Hmm, well, i would guess that it's the latter, but i can't work out why that would be the case. i went through the various net.ipv4 sysctl options, but couldn't see anything relevant . . . .