bind 9.2.1 dig problems

I have a domain www.opalfire.net which seems to resolve fine on my
local box. I've got the primary dns (ns1.opalfire.net) pointing here.
I must have some strange config problem going on because I can no
longer (from the outside) resolve www.opalfire.net. On the local box
things work fine. I had another linux server which worked just fine
from behind my firewall previously. That box had a hardware failure
and I can't seem to figure out what's wrong now with a new install of
redhat. I'm running bind 9.2.1

dig www.opalfire.net returns this on the local box:

]# dig www.opalfire.net

; <<>> DiG 9.2.1 <<>> www.opalfire.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49380
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL:
0

;; QUESTION SECTION:
;www.opalfire.net. IN A

;; ANSWER SECTION:
www.opalfire.net. 259200 IN CNAME ns.opalfire.net.
ns.opalfire.net. 259200 IN A 66.47.111.31

;; AUTHORITY SECTION:
opalfire.net. 259200 IN NS ns1.opalfire.net.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 20 12:01:20 2003
;; MSG SIZE rcvd: 85

On 20 Oct 2003 09:01:12 -0700, mark stephens <(E-Mail Removed)> wrote:
> I have a domain www.opalfire.net which seems to resolve fine on my
> local box. I've got the primary dns (ns1.opalfire.net) pointing here.
> I must have some strange config problem going on because I can no
> longer (from the outside) resolve www.opalfire.net. On the local box
> things work fine. I had another linux server which worked just fine
> from behind my firewall previously. That box had a hardware failure
> and I can't seem to figure out what's wrong now with a new install of
> redhat. I'm running bind 9.2.1
>
> dig www.opalfire.net returns this on the local box:
>
> ]# dig www.opalfire.net
>
> ; <<>> DiG 9.2.1 <<>> www.opalfire.net
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49380
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL:
> 0
>
> ;; QUESTION SECTION:
> ;www.opalfire.net. IN A
>
> ;; ANSWER SECTION:
> www.opalfire.net. 259200 IN CNAME ns.opalfire.net.
> ns.opalfire.net. 259200 IN A 66.47.111.31
>
> ;; AUTHORITY SECTION:
> opalfire.net. 259200 IN NS ns1.opalfire.net.
>
> ;; Query time: 1 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Mon Oct 20 12:01:20 2003
> ;; MSG SIZE rcvd: 85

Apparently your DNS is not responding to outside queries. Your firewall
may be dropping port 53, because it times out instead of being refused.
Your alternate DNS does not resolve and likewise times out for any
queries. Even 'dig opalfire.net ns' times out, so you effectively have no
DNS at the moment.

> dig @66.47.111.31 opalfire.net any

; <<>> DiG 8.3 <<>> @66.47.111.31 opalfire.net any
; (1 server found)
;; res options: init recurs defnam dnsrch
;; res_nsend to server 66.47.111.31: Connection timed out

--
David Efflandt - All spam ignored http://www.de-srv.com/

(E-Mail Removed) (David Efflandt) writes:

> On 20 Oct 2003 09:01:12 -0700, mark stephens <(E-Mail Removed)> wrote:
> > I have a domain www.opalfire.net which seems to resolve fine on my
> > local box. I've got the primary dns (ns1.opalfire.net) pointing here.
> > I must have some strange config problem going on because I can no
> > longer (from the outside) resolve www.opalfire.net. On the local box
> > things work fine. I had another linux server which worked just fine
> > from behind my firewall previously. That box had a hardware failure
> > and I can't seem to figure out what's wrong now with a new install of
> > redhat. I'm running bind 9.2.1

[snip]

> Apparently your DNS is not responding to outside queries. Your firewall
> may be dropping port 53, because it times out instead of being refused.
> Your alternate DNS does not resolve and likewise times out for any
> queries. Even 'dig opalfire.net ns' times out, so you effectively have no
> DNS at the moment.

Opalfire.net has two registered DNS servers:

opalfire.net. 2D IN NS pinky.worldnic.com.
opalfire.net. 2D IN NS ns1.opalfire.net.

pinky.worldnic.com. 2D IN A 198.41.1.13
ns1.opalfire.net. 2D IN A 66.47.111.31

When I send queries to pinky.worldnic.com, I get the following:

X.X.X.X.21412 > 198.41.1.13.53: 979+ A? www.opalfire.net. (34)
198.41.1.213 > X.X.X.X: icmp: host 198.41.1.13 unreachable - admin prohibited filter

Pinky.worldnic.com appears to be behind a packet filter or firewall
that doesn't permit inbound DNS queries, so either you shouldn't
have that listed as a DNS server or VeriSign (worldnic.com) has
something misconfigured.

When I send queries to ns1.opalfire.net, I get the following:

X.X.X.X.21414 > 66.47.111.31.53: 15878+ A? www.opalfire.net. (34)
66.47.111.31 > X.X.X.X: icmp: 192.168.1.101 udp port 53 unreachable [tos 0xc0]

There appears to be address translation going on here, presumably
by a firewall. Check that 192.168.1.101 is the correct address to
which DNS queries should be sent, that the host at that address is
listening for DNS queries on the correct interface(s), and that any
packet filters are configured to allow DNS queries from the outside.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

The strange thing is that my previous linux box worked just fine
behine my NAT router. I simply swapped ips when doing the translation
and bam opalfire would resolve. I route the webserver just fine to
this same linux box. I guess what I was wondering if there was
something special I had to do to get outside queries working. It
almost seems like it doesn't get those.


(E-Mail Removed) (Michael Fuhr) wrote in message news:<3f94bddb$(E-Mail Removed)>...
> (E-Mail Removed) (David Efflandt) writes:
> > Apparently your DNS is not responding to outside queries. Your firewall
> > may be dropping port 53, because it times out instead of being refused.
> > Your alternate DNS does not resolve and likewise times out for any
> > queries. Even 'dig opalfire.net ns' times out, so you effectively have no
> > DNS at the moment.
>
> Opalfire.net has two registered DNS servers:
>
> opalfire.net. 2D IN NS pinky.worldnic.com.
> opalfire.net. 2D IN NS ns1.opalfire.net.
>
> pinky.worldnic.com. 2D IN A 198.41.1.13
> ns1.opalfire.net. 2D IN A 66.47.111.31
>
> When I send queries to pinky.worldnic.com, I get the following:
>
> X.X.X.X.21412 > 198.41.1.13.53: 979+ A? www.opalfire.net. (34)
> 198.41.1.213 > X.X.X.X: icmp: host 198.41.1.13 unreachable - admin prohibited filter
>
> Pinky.worldnic.com appears to be behind a packet filter or firewall
> that doesn't permit inbound DNS queries, so either you shouldn't
> have that listed as a DNS server or VeriSign (worldnic.com) has
> something misconfigured.
>
> When I send queries to ns1.opalfire.net, I get the following:
>
> X.X.X.X.21414 > 66.47.111.31.53: 15878+ A? www.opalfire.net. (34)
> 66.47.111.31 > X.X.X.X: icmp: 192.168.1.101 udp port 53 unreachable [tos 0xc0]
>
> There appears to be address translation going on here, presumably
> by a firewall. Check that 192.168.1.101 is the correct address to
> which DNS queries should be sent, that the host at that address is
> listening for DNS queries on the correct interface(s), and that any
> packet filters are configured to allow DNS queries from the outside.

On 21 Oct 2003 08:40:08 -0700, mark stephens <(E-Mail Removed)> wrote:
> The strange thing is that my previous linux box worked just fine
> behine my NAT router. I simply swapped ips when doing the translation
> and bam opalfire would resolve. I route the webserver just fine to
> this same linux box. I guess what I was wondering if there was
> something special I had to do to get outside queries working. It
> almost seems like it doesn't get those.

Check the output of 'iptables -L' on your nameserver. It could be running
a default firewall that only allows access from local IPs.

Or run tcpdump and do a query from outside (internet) to see if there is
any sign of a hit and/or lack of response.

--
David Efflandt - All spam ignored http://www.de-srv.com/

iptables -L returns this for domain:

ACCEPT udp -- opalfire anywhere udp
spt:domain dpts:1025:65535
ACCEPT udp -- ns1.mindspring.com anywhere udp
spt:domain dpts:1025:65535
ACCEPT udp -- ns2.mindspring.com anywhere udp
spt:domain dpts:1025:65535

I'm still playing with tcpdump to see what's coming through.

(E-Mail Removed) (David Efflandt) wrote in message news:<(E-Mail Removed)>...
> On 21 Oct 2003 08:40:08 -0700, mark stephens <(E-Mail Removed)> > Check the output of 'iptables -L' on your nameserver. It could be running
> a default firewall that only allows access from local IPs.
>
> Or run tcpdump and do a query from outside (internet) to see if there is
> any sign of a hit and/or lack of response.

Here are some domain requests which look like they are coming in:

11:25:09.188952 192.168.1.101 > percula.dns.atl.earthlink.net: icmp:
192.168.1.101 udp port domain unreachable [tos 0xc0]
11:25:09.189284 192.168.1.101.40246 > ns2.mindspring.com.domain:
37045+ PTR? 209.63.86.209.in-addr.arpa. (44) (DF)
11:25:09.219772 ns2.mindspring.com.domain > 192.168.1.101.40246:
37045 1/2/0 (141) (DF)
11:25:09.453197 atl190.turner.com.29872 > 192.168.1.101.domain: 41341
A? www.opalfire.net. (34) (DF)
11:25:09.453255 192.168.1.101 > atl190.turner.com: icmp: 192.168.1.101
udp port domain unreachable [tos 0xc0]
11:25:09.887325 cod.dns.atl.earthlink.net.domain >
192.168.1.101.domain: 51906 A6? ns1.opalfire.net. (34) (DF)
11:25:09.887377 192.168.1.101 > cod.dns.atl.earthlink.net: icmp:
192.168.1.101 udp port domain unreachable [tos 0xc0]
11:25:09.997326 atl190.turner.com.29848 > 192.168.1.101.domain: 7385
A? www.opalfire.net. (34) (DF)
11:25:09.997379 192.168.1.101 > atl190.turner.com: icmp: 192.168.1.101
udp port domain unreachable [tos 0xc0]
11:25:09.999107 h-64-236-221-6.turner.com.13142 >
192.168.1.101.domain: 13473 A? www.opalfire.net. (34) (DF)
11:25:09.999139 192.168.1.101 > h-64-236-221-6.turner.com: icmp:
192.168.1.101 udp port domain unreachable [tos 0xc0]


(E-Mail Removed) (David Efflandt) wrote in message news:<(E-Mail Removed)>...
> On 21 Oct 2003 08:40:08 -0700, mark stephens <(E-Mail Removed)> wrote:
> > Check the output of 'iptables -L' on your nameserver. It could be running
> a default firewall that only allows access from local IPs.
>
> Or run tcpdump and do a query from outside (internet) to see if there is
> any sign of a hit and/or lack of response.

On 22 Oct 2003 07:39:00 -0700, mark stephens <(E-Mail Removed)> wrote:
> iptables -L returns this for domain:
>
> ACCEPT udp -- opalfire anywhere udp
> spt:domain dpts:1025:65535
> ACCEPT udp -- ns1.mindspring.com anywhere udp
> spt:domain dpts:1025:65535
> ACCEPT udp -- ns2.mindspring.com anywhere udp
> spt:domain dpts:1025:65535

OK, which chain is that (OUTPUT?)? That appears to allow opalfire to
connect its port 53 (domain) to a limited range of ports anywhere, but
where is the rule to ACCEPT any port from anywhere to dpt:domain on
opalfire? Your tcpdump posted separately confirms that incoming domain
(port 53) requests are being refused as network unreachable.

> I'm still playing with tcpdump to see what's coming through.
>
> (E-Mail Removed) (David Efflandt) wrote in message news:<(E-Mail Removed)>...
>> On 21 Oct 2003 08:40:08 -0700, mark stephens <(E-Mail Removed)
>
> Check the output of 'iptables -L' on your nameserver. It could be running
>> a default firewall that only allows access from local IPs.
>>
>> Or run tcpdump and do a query from outside (internet) to see if there is
>> any sign of a hit and/or lack of response.


--
David Efflandt - All spam ignored http://www.de-srv.com/
http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
http://cgi-help.virtualave.net/ http://hammer.prohosting.com/~cgi-wiz/

Good question ... I'm not all that familiar with firewall rules on
linux. I'll play with them and see what I can do. So it looks like I
need to allow requests coming to port 53.

Thanks,
Mark


(E-Mail Removed) (David Efflandt) wrote in message
> OK, which chain is that (OUTPUT?)? That appears to allow opalfire to
> connect its port 53 (domain) to a limited range of ports anywhere, but
> where is the rule to ACCEPT any port from anywhere to dpt:domain on
> opalfire? Your tcpdump posted separately confirms that incoming domain
> (port 53) requests are being refused as network unreachable.
>
>