RE: How to prevent slaves from contacting master for name resolution?
Are all the slaves authoritative for all the zones? If so, unless you're using forwarding, or some really odd delegation, queries shouldn't be going to the master servers. Todd. -Original Message- From: bind-users-bounces+tsnyder=rim@lists.isc.org [mailto:bind-users-bounces+tsnyder=rim@lists.isc.org] On Behalf Of Keith Christian Sent: Monday, May 17, 2010 5:59 PM To: bind-users@lists.isc.org Subject: How to prevent slaves from contacting master for name resolution? Our redundant DNS configuration is one master and three slaves, spread across two colo facilities. master and slave1 are in colo_ALPHA. slave2 and slave3 are in colo_BETA. During an extended maintenance window, the master DNS was offline. Slave2 was trying to contact the master, and lookups failed. Usually, slave2 resolves without contacting the master, but occasionally it does. The IP for the master does not appear in slave2's /etc/resolv.conf, and I'm not sure what else to check for on slave machines. Where else would I look? Would any settings in named.conf account for this behavior? Versions are Linux (CentOS 5) and BIND 9.5.x. Thanks. ==Keith ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to prevent slaves from contacting master for name resolution?
On May 17, 2010, at 7:24 PM, Kevin Darcy wrote: > On 5/17/2010 5:58 PM, Keith Christian wrote: >> Our redundant DNS configuration is one master and three slaves, spread >> across two colo facilities. >> >> master and slave1 are in colo_ALPHA. >> slave2 and slave3 are in colo_BETA. >> >> During an extended maintenance window, the master DNS was offline. >> Slave2 was trying to contact the master, and lookups failed. Usually, >> slave2 resolves without contacting the master, but occasionally it >> does. >> >> The IP for the master does not appear in slave2's /etc/resolv.conf, >> and I'm not sure what else to check for on slave machines. Where else >> would I look? Would any settings in named.conf account for this >> behavior? >> >> Versions are Linux (CentOS 5) and BIND 9.5.x. >> > > These queries that were failing, were they queries from external clients, > queries you were generating on the slave nameserver itself, or some other > queries entirely? > > If queries from external clients were failing while the master was down and > the slaves were up, then the most likely cause is that your NS records are > screwed up, such that your slaves aren't being found. Either you have the > wrong names in your delegation NS records, or those at the apex of the zone, > missing/incorrect glue in the parent zone, something like that. > > If queries you were generating *locally* were failing, the questions are: > a) are you quering the slave directly? > b) does the slave have recursion turned completely off? > > If you're querying the slave directly and recursion is off, and the queries > are failing, then this should have nothing whatsoever with the master being > down, since the data comes *only* from the slave. You should look at whether > the zone is being loaded correctly on the slave, a corrupted journal file, > expired zone, something like that. > > If you're querying the slave directly and recursion is *on* for the slave, > then you should check whether the slave is actually responding > authoritatively for the zone in question under normal circumstance. If not, > then something is misconfigured, the slave isn't really a slave at all, under > normal circumstances it's just recursing to get the information, and it makes > sense that when the master (and/or other slaves) are unavailable, queries > will fail. > > If you're querying some other box, then you'd need to look at that other box > into why the queries were failing. At that point, the fact that you're > generating queries from the slave itself has no bearing on the problem, since > the failed queries weren't going to the slave in the first place. > > Another possibility: were you using "nslookup" to test queries, and does the > master for your forward zone(s) also happen to be authoritative for the > *reverse* zone which contains the address of your resolver? If so, then be > aware that "nslookup" has the annoying feature of trying to reverse-resolve > the name of the resolver it's using. So, maybe the queries you're seeing > going from slave to master are *reverse* DNS queries, and if they're failing > because the master is down, "nslookup", in its quaint, eccentric way, may be > misreporting this as a general lookup failure, thus making you think that the > forward name is unresolvable. One other possibility: Have you configured the slaves to forward to the master, using a 'forwarders' statement, anywhere in named.conf? Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to prevent slaves from contacting master for name resolution?
On 5/17/2010 5:58 PM, Keith Christian wrote: Our redundant DNS configuration is one master and three slaves, spread across two colo facilities. master and slave1 are in colo_ALPHA. slave2 and slave3 are in colo_BETA. During an extended maintenance window, the master DNS was offline. Slave2 was trying to contact the master, and lookups failed. Usually, slave2 resolves without contacting the master, but occasionally it does. The IP for the master does not appear in slave2's /etc/resolv.conf, and I'm not sure what else to check for on slave machines. Where else would I look? Would any settings in named.conf account for this behavior? Versions are Linux (CentOS 5) and BIND 9.5.x. These queries that were failing, were they queries from external clients, queries you were generating on the slave nameserver itself, or some other queries entirely? If queries from external clients were failing while the master was down and the slaves were up, then the most likely cause is that your NS records are screwed up, such that your slaves aren't being found. Either you have the wrong names in your delegation NS records, or those at the apex of the zone, missing/incorrect glue in the parent zone, something like that. If queries you were generating *locally* were failing, the questions are: a) are you quering the slave directly? b) does the slave have recursion turned completely off? If you're querying the slave directly and recursion is off, and the queries are failing, then this should have nothing whatsoever with the master being down, since the data comes *only* from the slave. You should look at whether the zone is being loaded correctly on the slave, a corrupted journal file, expired zone, something like that. If you're querying the slave directly and recursion is *on* for the slave, then you should check whether the slave is actually responding authoritatively for the zone in question under normal circumstance. If not, then something is misconfigured, the slave isn't really a slave at all, under normal circumstances it's just recursing to get the information, and it makes sense that when the master (and/or other slaves) are unavailable, queries will fail. If you're querying some other box, then you'd need to look at that other box into why the queries were failing. At that point, the fact that you're generating queries from the slave itself has no bearing on the problem, since the failed queries weren't going to the slave in the first place. Another possibility: were you using "nslookup" to test queries, and does the master for your forward zone(s) also happen to be authoritative for the *reverse* zone which contains the address of your resolver? If so, then be aware that "nslookup" has the annoying feature of trying to reverse-resolve the name of the resolver it's using. So, maybe the queries you're seeing going from slave to master are *reverse* DNS queries, and if they're failing because the master is down, "nslookup", in its quaint, eccentric way, may be misreporting this as a general lookup failure, thus making you think that the forward name is unresolvable. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
