I'm having some trouble getting reverse zones right on 5.2. The zone files worked fine on a CentOS 4.6 machine, and the forward zones moved to the new server seem OK. But for some reason I can't get anything but servfail's on remote queries to the machine. But for some reason they will answer fine if I run "host ip.ad.dr.ess" on the local machine. I stopped the firewall to help debug this, but it still fails.
Bind is listening on all the machines ip addresses.
I'm having some trouble getting reverse zones right on 5.2. The zone files worked fine on a CentOS 4.6 machine, and the forward zones moved to the new server seem OK. But for some reason I can't get anything but servfail's on remote queries to the machine. But for some reason they will answer fine if I run "host ip.ad.dr.ess" on the local machine. I stopped the firewall to help debug this, but it still fails.
Bind is listening on all the machines ip addresses.
Anything at all in the logs when you stop and start bind, or otherwise ?
- rh
on 7-8-2008 9:58 AM Robert - elists spake the following:
I'm having some trouble getting reverse zones right on 5.2. The zone files worked fine on a CentOS 4.6 machine, and the forward zones moved to the new server seem OK. But for some reason I can't get anything but servfail's on remote queries to the machine. But for some reason they will answer fine if I run "host ip.ad.dr.ess" on the local machine. I stopped the firewall to help debug this, but it still fails.
Bind is listening on all the machines ip addresses.
Anything at all in the logs when you stop and start bind, or otherwise ?
- rh
Just a refused notify request on a different domain. Otherwise bind is listening on all interfaces.
on 7-8-2008 1:34 PM Scott Silva spake the following:
on 7-8-2008 9:58 AM Robert - elists spake the following:
I'm having some trouble getting reverse zones right on 5.2. The zone files worked fine on a CentOS 4.6 machine, and the forward zones moved to the new server seem OK. But for some reason I can't get anything but servfail's on remote queries to the machine. But for some reason they will answer fine if I run "host ip.ad.dr.ess" on the local machine. I stopped the firewall to help debug this, but it still fails.
Bind is listening on all the machines ip addresses.
Anything at all in the logs when you stop and start bind, or otherwise ?
- rh
Just a refused notify request on a different domain. Otherwise bind is listening on all interfaces.
This is strange, because if I run "host 208.252.226.196" on the local server it resolves fine, but the outside world can't see it. But I can run host on the domain name and it answers fine. I see new bind patches going to the mirrors, I'll see what happens. I'll also try a reboot in case something is stopping bind from actually passing traffic on that interface properly.
On Tue, July 8, 2008 12:48 pm, Scott Silva wrote:
I'm having some trouble getting reverse zones right on 5.2. The zone files worked fine on a CentOS 4.6 machine, and the forward zones moved to the new server seem OK. But for some reason I can't get anything but servfail's on remote queries to the machine. But for some reason they will answer fine if I run "host ip.ad.dr.ess" on the local machine. I stopped the firewall to help debug this, but it still fails.
Bind is listening on all the machines ip addresses.
--
You could also try
dig +trace -x 00.00.00.00
and see where it takes you.
Brian.
on 7-8-2008 11:27 AM Brian spake the following:
On Tue, July 8, 2008 12:48 pm, Scott Silva wrote:
I'm having some trouble getting reverse zones right on 5.2. The zone files worked fine on a CentOS 4.6 machine, and the forward zones moved to the new server seem OK. But for some reason I can't get anything but servfail's on remote queries to the machine. But for some reason they will answer fine if I run "host ip.ad.dr.ess" on the local machine. I stopped the firewall to help debug this, but it still fails.
Bind is listening on all the machines ip addresses.
--
You could also try
dig +trace -x 00.00.00.00
and see where it takes you.
Brian.
This is a server that seems to resolve ok. Done from my home server.
; <<>> DiG 9.2.4 <<>> +trace -x 63.110.242.66 ;; global options: printcmd <snip root server stuff> ;; Received 476 bytes from 127.0.0.1#53(127.0.0.1) in 263 ms
63.in-addr.arpa. 86400 IN NS epazote.ARIN.NET. 63.in-addr.arpa. 86400 IN NS chia.ARIN.NET. 63.in-addr.arpa. 86400 IN NS figwort.ARIN.NET. 63.in-addr.arpa. 86400 IN NS dill.ARIN.NET. 63.in-addr.arpa. 86400 IN NS henna.ARIN.NET. 63.in-addr.arpa. 86400 IN NS BASIL.ARIN.NET. 63.in-addr.arpa. 86400 IN NS indigo.ARIN.NET. ;; Received 195 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 26 ms
110.63.in-addr.arpa. 86400 IN NS AUTH03.NS.UU.NET. 110.63.in-addr.arpa. 86400 IN NS AUTH00.NS.UU.NET. ;; Received 95 bytes from 192.41.162.32#53(epazote.ARIN.NET) in 85 ms
242.110.63.in-addr.arpa. 21600 IN NS auth100.ns.uu.net. 242.110.63.in-addr.arpa. 21600 IN NS auth110.ns.uu.net. ;; Received 97 bytes from 198.6.1.83#53(AUTH03.NS.UU.NET) in 129 ms
66.242.110.63.in-addr.arpa. 21600 IN CNAME 66.64.242.110.63.in-addr.arpa. 64.242.110.63.in-addr.arpa. 21600 IN NS mail.sgvwater.com. 64.242.110.63.in-addr.arpa. 21600 IN NS mail.fontanawater.com. ;; Received 127 bytes from 198.6.1.202#53(auth100.ns.uu.net) in 73 ms
----------------------------------------------
This one doesn't, it seems that the server won't answer the request.
; <<>> DiG 9.2.4 <<>> +trace -x 208.252.226.196 ;; global options: printcmd <snip root server stuff> ;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 121 ms
208.in-addr.arpa. 86400 IN NS chia.arin.net. 208.in-addr.arpa. 86400 IN NS dill.arin.net. 208.in-addr.arpa. 86400 IN NS basil.arin.net. 208.in-addr.arpa. 86400 IN NS henna.arin.net. 208.in-addr.arpa. 86400 IN NS indigo.arin.net. 208.in-addr.arpa. 86400 IN NS epazote.arin.net. 208.in-addr.arpa. 86400 IN NS figwort.arin.net. ;; Received 197 bytes from 193.0.14.129#53(K.ROOT-SERVERS.NET) in 132 ms
252.208.in-addr.arpa. 86400 IN NS AUTH03.NS.UU.NET. 252.208.in-addr.arpa. 86400 IN NS AUTH00.NS.UU.NET. ;; Received 97 bytes from 192.5.6.32#53(chia.arin.net) in 94 ms
226.252.208.in-addr.arpa. 21600 IN NS auth02.ns.uu.net. 226.252.208.in-addr.arpa. 21600 IN NS auth20.ns.wcom.com. ;; Received 108 bytes from 198.6.1.83#53(AUTH03.NS.UU.NET) in 100 ms
196.226.252.208.in-addr.arpa. 21600 IN CNAME 196.192.226.252.208.in-addr.arpa. 192.226.252.208.in-addr.arpa. 21600 IN NS mail.sgvwater.com. ;; Received 99 bytes from 198.6.1.82#53(auth02.ns.uu.net) in 95 ms
I can get the A record fine, but it won't answer the PTR request. I'm thinking that bind just doesn't like the reverse zone file, but it doesn't toss up any errors about it.
On Tue, July 8, 2008 4:50 pm, Scott Silva wrote:
This is a server that seems to resolve ok. Done from my home server.
; <<>> DiG 9.2.4 <<>> +trace -x 63.110.242.66
This one doesn't, it seems that the server won't answer the request.
; <<>> DiG 9.2.4 <<>> +trace -x 208.252.226.196
I can get the A record fine, but it won't answer the PTR request. I'm thinking that bind just doesn't like the reverse zone file, but it doesn't toss up any errors about it.
# dig @mail.fontanawater.com -x 208.252.226.196
; <<>> DiG 9.3.4-P1 <<>> @mail.fontanawater.com -x 208.252.226.196 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8896 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION: ;196.226.252.208.in-addr.arpa. IN PTR
;; ANSWER SECTION: 196.226.252.208.in-addr.arpa. 18751 IN CNAME 196.192.226.252.208.in-addr.arpa. 196.192.226.252.208.in-addr.arpa. 43200 IN PTR mail.fontanawater.com.
;; AUTHORITY SECTION: 192.226.252.208.in-addr.arpa. 43200 IN NS mail.fontanawater.com. 192.226.252.208.in-addr.arpa. 43200 IN NS mail.sgvwater.com.
;; ADDITIONAL SECTION: mail.sgvwater.com. 43200 IN A 63.110.242.66 mail.fontanawater.com. 43200 IN A 208.252.226.196
;; Query time: 165 msec ;; SERVER: 208.252.226.196#53(208.252.226.196) ;; WHEN: Tue Jul 8 20:47:45 2008 ;; MSG SIZE rcvd: 177
I would look into your NS records on the effected server and also your PTR zone file for errors.
Brian.
on 7-8-2008 5:50 PM Brian spake the following:
On Tue, July 8, 2008 4:50 pm, Scott Silva wrote:
This is a server that seems to resolve ok. Done from my home server.
; <<>> DiG 9.2.4 <<>> +trace -x 63.110.242.66
This one doesn't, it seems that the server won't answer the request.
; <<>> DiG 9.2.4 <<>> +trace -x 208.252.226.196
I can get the A record fine, but it won't answer the PTR request. I'm thinking that bind just doesn't like the reverse zone file, but it doesn't toss up any errors about it.
# dig @mail.fontanawater.com -x 208.252.226.196
; <<>> DiG 9.3.4-P1 <<>> @mail.fontanawater.com -x 208.252.226.196 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8896 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION: ;196.226.252.208.in-addr.arpa. IN PTR
;; ANSWER SECTION: 196.226.252.208.in-addr.arpa. 18751 IN CNAME 196.192.226.252.208.in-addr.arpa. 196.192.226.252.208.in-addr.arpa. 43200 IN PTR mail.fontanawater.com.
;; AUTHORITY SECTION: 192.226.252.208.in-addr.arpa. 43200 IN NS mail.fontanawater.com. 192.226.252.208.in-addr.arpa. 43200 IN NS mail.sgvwater.com.
;; ADDITIONAL SECTION: mail.sgvwater.com. 43200 IN A 63.110.242.66 mail.fontanawater.com. 43200 IN A 208.252.226.196
;; Query time: 165 msec ;; SERVER: 208.252.226.196#53(208.252.226.196) ;; WHEN: Tue Jul 8 20:47:45 2008 ;; MSG SIZE rcvd: 177
I would look into your NS records on the effected server and also your PTR zone file for errors.
Brian.
I'm wondering if there is something wrong above me at MCI? I only have a /26 in that block. If I host 208.252.226.196 208.252.226.196 it seems to get a proper answer. But if I let the query go through the root servers, it fails.
host 208.252.226.196 Host 196.226.252.208.in-addr.arpa not found: 2(SERVFAIL)
host 208.252.226.196 208.252.226.196 Using domain server: Name: 208.252.226.196 Address: 208.252.226.196#53 Aliases:
196.226.252.208.in-addr.arpa is an alias for 196.192.226.252.208.in-addr.arpa. 196.192.226.252.208.in-addr.arpa domain name pointer mail.fontanawater.com.
After digging for a bit at arin
Near as I can tell, it appears the authoritative dns servers for that specific block are a lil messed up for the moment.
Not delegating something properly.
Tough to say without admin access to those machines.
If you check your netblock at ARIN whois, it says these two dns servers are authoritive
OrgName: MCI Communications Services, Inc. d/b/a Verizon Business OrgID: MCICS Address: 22001 Loudoun County Pkwy City: Ashburn StateProv: VA PostalCode: 20147 Country: US
NetRange: 208.192.0.0 - 208.255.255.255 CIDR: 208.192.0.0/10 NetName: UUNET1996B NetHandle: NET-208-192-0-0-1 Parent: NET-208-0-0-0-0 NetType: Direct Allocation NameServer: AUTH03.NS.UU.NET NameServer: AUTH00.NS.UU.NET Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE RegDate: 1996-05-08 Updated: 2006-12-14
dig -x 208.252.226.222 @AUTH00.NS.UU.NET
; <<>> DiG 9.2.4 <<>> -x 208.252.226.222 @AUTH00.NS.UU.NET ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47733 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION: ;222.226.252.208.in-addr.arpa. IN PTR
;; AUTHORITY SECTION: 226.252.208.in-addr.arpa. 21600 IN NS auth02.ns.uu.net. 226.252.208.in-addr.arpa. 21600 IN NS auth20.ns.wcom.com.
;; ADDITIONAL SECTION: auth02.ns.uu.net. 3600 IN A 198.6.1.82
When you do a reverse dig at them, one of them will tell you that this ip is authoritive
198.6.1.82 aka That ip is auth02.ns.uu.net
Auto03 returns squat...
dig -x 208.252.226.222 @AUTH03.NS.UU.NET
; <<>> DiG 9.2.4 <<>> -x 208.252.226.222 @AUTH03.NS.UU.NET ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32548 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION: ;222.226.252.208.in-addr.arpa. IN PTR
;; AUTHORITY SECTION: 226.252.208.in-addr.arpa. 21600 IN NS auth02.ns.uu.net. 226.252.208.in-addr.arpa. 21600 IN NS auth20.ns.wcom.com.
So, maybe something is a lil broken in their in-addr.arpa land
Could be wrong though...
If you dig stuff at the IP address, it seems to at least try to work though
Something is not right imho
dig -x 208.252.226.222 @198.6.1.82
; <<>> DiG 9.2.4 <<>> -x 208.252.226.222 @198.6.1.82 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62935 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION: ;222.226.252.208.in-addr.arpa. IN PTR
;; ANSWER SECTION: 222.226.252.208.in-addr.arpa. 21600 IN CNAME 222.192.226.252.208.in-addr.arpa.
;; AUTHORITY SECTION: 192.226.252.208.in-addr.arpa. 21600 IN NS mail.sgvwater.com.
Best wishes...
- rh
on 7-8-2008 11:15 PM Robert - elists spake the following:
After digging for a bit at arin
Near as I can tell, it appears the authoritative dns servers for that specific block are a lil messed up for the moment.
Not delegating something properly.
Tough to say without admin access to those machines.
If you check your netblock at ARIN whois, it says these two dns servers are authoritive
OrgName: MCI Communications Services, Inc. d/b/a Verizon Business OrgID: MCICS Address: 22001 Loudoun County Pkwy City: Ashburn StateProv: VA PostalCode: 20147 Country: US
NetRange: 208.192.0.0 - 208.255.255.255 CIDR: 208.192.0.0/10 NetName: UUNET1996B NetHandle: NET-208-192-0-0-1 Parent: NET-208-0-0-0-0 NetType: Direct Allocation NameServer: AUTH03.NS.UU.NET NameServer: AUTH00.NS.UU.NET Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE RegDate: 1996-05-08 Updated: 2006-12-14
dig -x 208.252.226.222 @AUTH00.NS.UU.NET
; <<>> DiG 9.2.4 <<>> -x 208.252.226.222 @AUTH00.NS.UU.NET ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47733 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION: ;222.226.252.208.in-addr.arpa. IN PTR
;; AUTHORITY SECTION: 226.252.208.in-addr.arpa. 21600 IN NS auth02.ns.uu.net. 226.252.208.in-addr.arpa. 21600 IN NS auth20.ns.wcom.com.
;; ADDITIONAL SECTION: auth02.ns.uu.net. 3600 IN A 198.6.1.82
When you do a reverse dig at them, one of them will tell you that this ip is authoritive
198.6.1.82 aka That ip is auth02.ns.uu.net
Auto03 returns squat...
dig -x 208.252.226.222 @AUTH03.NS.UU.NET
; <<>> DiG 9.2.4 <<>> -x 208.252.226.222 @AUTH03.NS.UU.NET ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32548 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION: ;222.226.252.208.in-addr.arpa. IN PTR
;; AUTHORITY SECTION: 226.252.208.in-addr.arpa. 21600 IN NS auth02.ns.uu.net. 226.252.208.in-addr.arpa. 21600 IN NS auth20.ns.wcom.com.
So, maybe something is a lil broken in their in-addr.arpa land
Could be wrong though...
If you dig stuff at the IP address, it seems to at least try to work though
Something is not right imho
dig -x 208.252.226.222 @198.6.1.82
; <<>> DiG 9.2.4 <<>> -x 208.252.226.222 @198.6.1.82 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62935 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION: ;222.226.252.208.in-addr.arpa. IN PTR
;; ANSWER SECTION: 222.226.252.208.in-addr.arpa. 21600 IN CNAME 222.192.226.252.208.in-addr.arpa.
;; AUTHORITY SECTION: 192.226.252.208.in-addr.arpa. 21600 IN NS mail.sgvwater.com.
Best wishes...
- rh
Verizon had some automatic script that comments out your reverse DNS entries if it finds your server offline. I guess when the T1 line was out last weekend it hit and killed the entries in the main ip block.
Case closed... But I think I should have been notified of this change, as I already get a notice everytime the T1 goes offline.
Thanks for everyones help, as it is a lot easier to look at DNS from several locations.
-
Brian -
Robert - elists -
Scott Silva