Jim C wrote on Tue, Oct 22, 2002 at 01:43:06PM -0700 : > > udp 0 0 192.168.1.254:53 0.0.0.0:* > udp 0 0 208.152.4.88:53 0.0.0.0:* > udp 0 0 127.0.0.1:53 0.0.0.0:*
Good, this means it is listening on localhost and both ethernet cards.
> The results of 'service named status' are:
> number of zones: 6
> debug level: 0
> xfers running: 0
> xfers deferred: 0
> soa queries in progress: 0
> query logging is OFF
> server is up and running
Very good.
> The results of 'host enigma.microverse.net' are:
> ;; connection timed out; no servers could be reached
If you have in /etc/resolv.conf "nameserver 127.0.0.1" it should be
asking itself what the hostname "enigma.microversenet" has for an IP
address.
> The results of 'iptables --list -n' are:
I thought you said you weren't running a firewall? Maybe I dreamed that
up.
> Chain INPUT (policy DROP)
> target prot opt source destination
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
> eth0_in all -- 0.0.0.0/0 0.0.0.0/0
> eth1_in all -- 0.0.0.0/0 0.0.0.0/0
> common all -- 0.0.0.0/0 0.0.0.0/0
> LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0
> level 6 prefix `Shorewall:INPUT:REJECT:'
> reject all -- 0.0.0.0/0 0.0.0.0/0
This means it goes through each of the targets from top to bottom only
stopping when it matches one. In your case, it's getting all the way
down to the LOG and reject chain, so we have to modify one of the
targets to allow those udp port 53 packets through. However, look at
the first rule. The ACCEPT target is saying accept everything (that is
not a very good first rule to have :-/ ) however, I would like to see
the exact rule to see exactly what it should be seeing. So at this
point, I'm fairly confident saying that the firewall is allowing port 53
requests in. That can be verified by looking in your /var/log/messages
for any line that starts with "Shorewall:INPUT:REJECT:" and lists udp
port 53.
> Chain OUTPUT (policy DROP)
> target prot opt source destination
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
> ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 state
> NEW,RELATED,ESTABLISHED
> fw2net all -- 0.0.0.0/0 0.0.0.0/0
> fw2masq all -- 0.0.0.0/0 0.0.0.0/0
> common all -- 0.0.0.0/0 0.0.0.0/0
> LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0
> level 6 prefix `Shorewall:OUTPUT:REJECT:'
> reject all -- 0.0.0.0/0 0.0.0.0/0
The reply packet will be coming from port 53. It's likely that your
reply packet be blocked if the targets in this chain don't explicitly
allow it. Again, look for "Shorewall:OUTPUT:REJECT:" in the log file
saying that it blocked udp port 53.
> Chain common (5 references)
> target prot opt source destination
> ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
> icmpdef icmp -- 0.0.0.0/0 0.0.0.0/0
> DROP tcp -- 0.0.0.0/0 0.0.0.0/0 state INVALID
> REJECT udp -- 0.0.0.0/0 0.0.0.0/0 udp
> dpts:137:139 reject-with icmp-port-unreachable
> REJECT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:445
> reject-with icmp-port-unreachable
> reject tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:135
> DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:1900
> DROP all -- 0.0.0.0/0 255.255.255.255
> DROP all -- 0.0.0.0/0 224.0.0.0/4
> reject tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:113
> DROP all -- 0.0.0.0/0 255.255.255.255
> DROP all -- 0.0.0.0/0 192.168.1.255
In this chain would be a possible place to be to allow udp port 53, but
don't do it there. Look further down.
> Chain loc2fw (0 references)
> target prot opt source destination
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
> RELATED,ESTABLISHED
> newnotsyn tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
> tcp flags:!0x16/0x02
> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW
> udp dpt:53
> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
> tcp dpt:80
> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
> tcp dpt:443
> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
> tcp dpt:53
> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
> tcp dpt:22
> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
> tcp dpt:20
> ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
> tcp dpt:21
> all2all all -- 0.0.0.0/0 0.0.0.0/0
See there? That's supposed to be enabling port 53. The problem is the
first line says that there are zero references to it. If you make the
INPUT chain use target loc2fw, then your problems should be solved.
> Chain masq2fw (1 references)
> target prot opt source destination
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
> RELATED,ESTABLISHED
> newnotsyn tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
> tcp flags:!0x16/0x02
> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW
> udp dpt:53
<snip>
This rule seems to let it work from outside to the firewall. If you
check from some remote site, you'll probably see that your firewall does
indeed return info from a name lookup, but unfortunately, you want it
the other way. You only want the nameserver to work for inside machines
and NOT outside machines (because you said it yourself, you have a
made-up name and you should not be answering queries from outside if you
are not in fact authoritative for it).
> Chain net2fw (1 references)
> target prot opt source destination
> ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state
> RELATED,ESTABLISHED
> newnotsyn tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW
> tcp flags:!0x16/0x02
> ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW
> udp dpt:53
<snip>
This kind of seems to be doing the same thing. I'd have to stare at it
longer.
I would say make it use the loc2fw target in the INPUT chain and
possibly the OUTPUT chain and you should be good to go.
Blue skies... Todd
--
...and I will strike down upon thee with great vengeance and furious
anger, those who attempt to poison and destroy my binaries, and you
will know my name is root, when I lay my vengeance upon thee.
Cooker Version mandrake-release-9.1-0.1mdk Kernel 2.4.19-16mdk
msg59814/pgp00000.pgp
Description: PGP signature
