RE: Odd query issue
Kevin, Thanks for the good ideas. Here is what I am seeing based on your recommendations: 1. Zone has expired (to confirm: check logs) No errors or notices regarding the zone being expired. 2. Corrupted/truncated journal file (to confirm: check logs, or, shut down gracefully, delete journal and start up again) I've shut down BIND, removed all files under the slave directory, and restarted BIND - no help. Other zones that are delegated from the same server are populated. 3. www.blah.com is a delegation in your slave copy of the zone, and the delegated nameservers are all returning SERVFAIL, are lame, give bogus answers, some combination of the above, etc. (to confirm: do the lookup non-recursively, or a zone transfer of blah.com; if www.blah.com shows as a delegation, query the delegated nameservers directly and see what they return) I am able to query the master directly, without issue as well as perform a zone transfer (though I get an error, ;; communications error to 10.x.x.x#53: connection reset). I'm assuming that this is due to the fact that the response is greater than 512 bytes perhaps. Brian ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Odd query issue
On 8/3/2010 7:50 AM, Atkins, Brian (GD/VA-NSOC) wrote: Kevin, Thanks for the good ideas. Here is what I am seeing based on your recommendations: 1. Zone has expired (to confirm: check logs) No errors or notices regarding the zone being expired. 2. Corrupted/truncated journal file (to confirm: check logs, or, shut down gracefully, delete journal and start up again) I've shut down BIND, removed all files under the slave directory, and restarted BIND - no help. Other zones that are delegated from the same server are populated. 3. www.blah.com is a delegation in your slave copy of the zone, and the delegated nameservers are all returning SERVFAIL, are lame, give bogus answers, some combination of the above, etc. (to confirm: do the lookup non-recursively, or a zone transfer of blah.com; if www.blah.com shows as a delegation, query the delegated nameservers directly and see what they return) So, just to be clear: is www.blah.com delegated to another nameserver or set of nameservers? Or is it contained within the blah.com zone itself? My option #3 above referred to a relatively-unlikely scenario where a www.blah.com delegation was (temporarily) present in your slave copy, even though you indicated that on the master server, www.blah.com was contained in the blah.com zone. I am able to query the master directly, without issue as well as perform a zone transfer (though I get an error, ;; communications error to 10.x.x.x#53: connection reset). I'm assuming that this is due to the fact that the response is greater than 512 bytes perhaps. The 512-byte restriction only applies to UDP. Sounds like you may have a problem with performing TCP transactions with the master, most likely because of naively-implemented firewall rules. You can confirm or deny this via the +vc (virtual circuit = TCP) option to dig. If TCP between you and the master is completely broken, your zone transfers aren't going to work and the zone will expire, if it hasn't already. I'd double-check whether the zone is expired, maybe by restarting named with a high debug level. It's a little troubling that other slave zones -- I assume that's what you meant when you said that are delegated -- from the same master are working. But, are all the EXPIRE settings the same? Maybe this is just the _first_ zone that expired. Again, the logs should help here. Are zone transfers succeeding or failing for blah.com and for other zones. If there are failures, what are the error messages in the logs? - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Odd query issue
In message 4c58668d.2010...@chrysler.com, Kevin Darcy writes: On 8/3/2010 7:50 AM, Atkins, Brian (GD/VA-NSOC) wrote: Kevin, Thanks for the good ideas. Here is what I am seeing based on your recommendations: 1. Zone has expired (to confirm: check logs) No errors or notices regarding the zone being expired. 2. Corrupted/truncated journal file (to confirm: check logs, or, shut down gracefully, delete journal and start up again) I've shut down BIND, removed all files under the slave directory, and restarted BIND - no help. Other zones that are delegated from the same server are populated. 3. www.blah.com is a delegation in your slave copy of the zone, and the delegated nameservers are all returning SERVFAIL, are lame, give bogus answers, some combination of the above, etc. (to confirm: do the lookup non-recursively, or a zone transfer of blah.com; if www.blah.com shows as a delegation, query the delegated nameservers directly and see what they return) So, just to be clear: is www.blah.com delegated to another nameserver or set of nameservers? Or is it contained within the blah.com zone itself? My option #3 above referred to a relatively-unlikely scenario where a www.blah.com delegation was (temporarily) present in your slave copy, even though you indicated that on the master server, www.blah.com was contained in the blah.com zone. I am able to query the master directly, without issue as well as perform a zone transfer (though I get an error, ;; communications error to 10.x.x.x#53: connection reset). I'm assuming that this is due to the fact that the response is greater than 512 bytes perhaps. The 512-byte restriction only applies to UDP. Sounds like you may have a problem with performing TCP transactions with the master, most likely because of naively-implemented firewall rules. You can confirm or deny this via the +vc (virtual circuit = TCP) option to dig. If TCP between you and the master is completely broken, your zone transfers aren't going to work and the zone will expire, if it hasn't already. I'd double-check whether the zone is expired, maybe by restarting named with a high debug level. It's a little troubling that other slave zones -- I assume that's what you meant when you said that are delegated -- from the same master are working. But, are all the EXPIRE settings the same? Maybe this is just the _first_ zone that expired. Or that the other zones are smaller and this one is big enough that PMTUD kicks in. Again, the logs should help here. Are zone transfers succeeding or failing for blah.com and for other zones. If there are failures, what are the error messages in the logs? - Kevin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Odd query issue
On 8/2/2010 10:17 AM, Atkins, Brian (GD/VA-NSOC) wrote: Any ideas to point me in the right direction? What do the log files show surrounding the query? AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Odd query issue
1. Zone has expired (to confirm: check logs)
2. Corrupted/truncated journal file (to confirm: check logs, or, shut
down gracefully, delete journal and start up again)
3. www.blah.com is a delegation in your slave copy of the zone, and the
delegated nameservers are all returning SERVFAIL, are lame, give bogus
answers, some combination of the above, etc. (to confirm: do the lookup
non-recursively, or a zone transfer of blah.com; if www.blah.com shows
as a delegation, query the delegated nameservers directly and see what
they return)
- Kevin
On 8/2/2010 10:17 AM, Atkins, Brian (GD/VA-NSOC) wrote:
I'm troubleshooting an issue with internal resolution of a domain. I
have 2 identical slave servers that resolve for domains that have been
delegated to our group. However, while one of the servers can
successfully provide the responses, the other cannot. I've checked with
the network gurus to verify there is not a possibility of a firewall or
IPS rule causing the issue, but came back empty-handed.
Here's the breakdown (please don't laugh at the antiques...):
Sun V210's running Solaris 5.8
BIND 9.5.1-P3
...
zone blah.com {
type slave;
file /slave/db.blah.com;
masters { 10.xxx.xxx.xxx; };
allow-transfer { none; };
allow-query { all-clients; };
};
...
# Query local server (one with issues) fails
$ dig www.blah.com.
; DiG 9.5.1-P3 www.blah.com.
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 1735
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
; www.blah.com. IN A
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 2 14:12:48 2010
;; MSG SIZE rcvd: 29
# Query master directly or twin server from problem server succeeds
$ dig @10.xxx.xxx.xxx www.blah.com.
; DiG 9.5.1-P3 @10.xxx.xxx.xxx www.blah.com.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 341
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
; www.blah.com. IN A
;; ANSWER SECTION:
www.blah.com.300 IN A 10.xxx.xxx.xxx
;; Query time: 34 msec
;; SERVER: 10.xxx.xxx.xxx #53(10.xxx.xxx.xxx)
;; WHEN: Mon Aug 2 14:14:16 2010
;; MSG SIZE rcvd: 45
Any ideas to point me in the right direction?
Thanks,
Brian
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
