Date: Mon, 27 Aug 2001 15:42:58 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Paul Richards" <paul@freebsd-services.com>, "Len Conrad" <LConrad@Go2France.com>, <freebsd-questions@FreeBSD.ORG> Subject: RE: Secondary DNS Transfers Message-ID: <009901c12f49$9ecc6d00$1401a8c0@tedm.placo.com> In-Reply-To: <442150000.998912653@lobster.originative.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: Paul Richards [mailto:paul@freebsd-services.com] >Sent: Monday, August 27, 2001 4:44 AM > >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 OK - so I extended the answer a bit. He did say it was a new setup, and it seemed quite obvious that you need to test new setups before bringing them online. >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. > No, because as I said even if you query with dig you not 100% sure that the secondary has actually written the zone file out to disk. Not everybody runs _normal_ DNS software. >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. > Only for queries from other nameservers, most definitely NOT from client queries. And if the slave is not answering queries for your zone from other servers due to misconfiguration or some such your never going to know that as long as the master is online because there is no other way to force other nameservers on the Internet to only query the secondary then stop if it doesen't answer. >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. > It proves that you CAN switch off the master with no ill effects. There's a difference by proof from direct observation and proof by inference. >> 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. > Since when is total lack of customer service an excuse for anything? You can use e-mail or you simply use a different ISP. Your arguing that a person should stay with a doctor who is so busy that every time they go into the office they get seen by a nurse. Remember in most of these relationships you are PAYING for services rendered. >> 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. > No, but that IS the reason that multiple nameservers are supposed to exist for a zone. They didn't put multiple DNS servers into the spec just to reduce the load on the primary. The round-robin effect is there mainly to keep the roots from being overloaded. >> 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 :-) > True. You don't court disaster. But, if the equipment was in use during a taining exercise on a subject that was already dead you might do it. And I'd certainly expect someone to at least have pulled the plug while all the surgical equipment was powered on and ready to go at least sometime BEFORE the operation commences. Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?009901c12f49$9ecc6d00$1401a8c0>