From owner-freebsd-questions Mon Aug 27 4:44:23 2001 Delivered-To: freebsd-questions@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id 801A337B403 for ; Mon, 27 Aug 2001 04:44:16 -0700 (PDT) (envelope-from paul@freebsd-services.com) Received: from lobster.originative.co.uk (lobster [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id 609B91D146; Mon, 27 Aug 2001 12:44:13 +0100 (BST) Date: Mon, 27 Aug 2001 12:44:13 +0100 From: Paul Richards To: Ted Mittelstaedt , Len Conrad , freebsd-questions@FreeBSD.ORG Subject: RE: Secondary DNS Transfers Message-ID: <442150000.998912653@lobster.originative.co.uk> In-Reply-To: <005901c12eb7$bcb8b900$1401a8c0@tedm.placo.com> References: <005901c12eb7$bcb8b900$1401a8c0@tedm.placo.com> X-Mailer: Mulberry/2.1.0b3 (Linux/x86 Demo) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --On Sunday, August 26, 2001 22:18:42 -0700 Ted Mittelstaedt wrote: > And you can't then switch it back on? We ARE talking about a NEW > installation here, not testing every time that he updates a record in his > DNS. Ok, with a new installation I agree that testing in that way is a sensible step but if you're just changing zone data it's not. Even if the slave works, there'd be significant degradation of service if the master was taken offline because the resolver will round robin the connections to the nameservers and will have to timeout connecting to the master. BIND resolvers favour the most resonsive nameserver, typically the master so that compounds the problem. > But your suggestion simply won't do that. All it will do is answer that > the secondary is indeed ansdering queries - to the person on the > secondary that is issuing nslookup or dig or whatever he's issuing, at > the particular moment he's issuing it. It simply does NOT answer the > question of will anybody ELSE on the Internet indeed be able to use the > secondary like they are supposed to do - to provide resolution for the > domain should the primary go offline. but I thought that's what the original question asked, "how do you check that the slave has done the zone transfer successfully?" If you can query the slave with dig and you can see the changes then it's done the zone transfer and your setup is working. You really don't need to switch the master off to do that. DNS doesn't have a failover mechanism. They're not really primary and secondary, they're master and slave. The distinction is that the master holds the master copies of the data and the slave doesn't. In answering queries they are round-robined so you don't need to switch off the master to see if the slave suddenly starts answering queries because it has to be answering queries all the time. When you add/change a zone you want to be able to check that you've configured all the nameservers properly to pick up the changes and it *is* sufficient to query each nameserver in turn to see if they have the new zone data. Switching off the master doesn't do anything more to prove that zone transfers are working over using nslookup/dig. You're point above argues that switching off the master is the only way to ensure that connectivity from all around the internet is working to your slave. That wasn't the original point of the dicussion but nevertheless, I still can't see what switching off the master will do over testing the nameservers using nslookup from several different points on the internet. You can't test from everywhere, no tool can do that, but if you do some tests from different points you can be pretty sure there's no fundamental misconfiguration on your side of things. Switching off the master doesn't prove anything beyond that. > Your also deliberately ignoring that the original poster indicated that he > wasn't willing to pick up the phone and call the admin of the primary (or > even e-mail the admin of the primary) to do it the right way. I made it > clear in the original posting and subsequently that any kind of testing or > instrumentation was inferior to actually verifying by voice with the other > nameserver admin. That's not always practical. If you know the sysadmin who's running your nameserver then yes you can do that, though again, you won't find out anything that nslookup can't tell you. In a lot of cases though getting to speak to the admin is impossible. If your nameserver is with an ISP then invariably you can't get through to the people who actually run the systems. > You would probably continue to argue that once he's verified that things > "work" through the inferior method of attempting to query the nameserver, > that he should STILL not switch off the primary for a few days to make > absolutely sure that things really do work. All I can say is that backup > systems are NEVER properly tested if you don't actually cut over to them > to make the test. Slave's are not backup systems, you're implying this is a failover test and that's not how DNS works. > It's like testing a UPS. APC makes a great line of UPS's that have all > sorts of fancy "test" modes that claim to test the UPS - but if your > going to put that UPS into a hospital and have it control some surgical > equipment, you test it by pulling the plug. You don't trust someone's > life to what some dumb $5.00 computer says in a UPS. but you don't test it by pulling the plug when it's already got equipment plugged into it that's in use, in case it doesn't work :-) Paul Richards FreeBSD Services Ltd http://www.freebsd-services.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message