From owner-freebsd-questions@FreeBSD.ORG Tue Oct 27 04:11:03 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 765B5106566C for ; Tue, 27 Oct 2009 04:11:03 +0000 (UTC) (envelope-from rstill74@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 477E58FC15 for ; Tue, 27 Oct 2009 04:11:03 +0000 (UTC) Received: by pwj8 with SMTP id 8so1830823pwj.3 for ; Mon, 26 Oct 2009 21:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=vaouuRqdxazeKJgbTTt3IjlN71DSq93LeRPliFATqaA=; b=wjAx4meYicqkEfceCVb07kTWzNzjVtAN2Q5KMRyHXcbxikha+dc2Cz5oBoRMq3OJl5 GN0SMn3AnjiW6w9/zOTb9IILDqXwgxJ3rNu6f7lFo+BfgauHoF7h9KUPcPpTDBCzJdJV h5U86vLbwZbmbcqV9XV3OM55y/Q5QTvCj3438= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=JOXUrE1bnUy7td78u3WoIcf1XkBAHmzOyYcAhUb1hpW9du556UWpuY5tQE2q/g0a3U MemkVPuqZZfM+eZQXi07me1vdJ5bAS3jYRRXGg2L9Qf2k032b9p17aeA0DReLqNbBWkN PXZInarMrQYS4llqGS7WpHjcENIp/o1JxdssQ= MIME-Version: 1.0 Received: by 10.143.20.41 with SMTP id x41mr1248129wfi.148.1256616662964; Mon, 26 Oct 2009 21:11:02 -0700 (PDT) In-Reply-To: <4AE641EA.2070003@ibctech.ca> References: <19358_1256579715_4AE5E283_19358_105_1_70C0964126D66F458E688618E1CD008A08CCEE70@WADPEXV0.waddell.com> <5e09dc040910261155t641ae7bbu79bc08d735d69db6@mail.gmail.com> <21272_1256584114_4AE5F345_21272_1_1_70C0964126D66F458E688618E1CD008A08CCEE7C@WADPEXV0.waddell.com> <22794_1256588088_4AE60338_22794_16_1_70C0964126D66F458E688618E1CD008A08CCEE85@WADPEXV0.waddell.com> <5e09dc040910261613x4d91116epf397bfc35955f65d@mail.gmail.com> <4AE641EA.2070003@ibctech.ca> Date: Mon, 26 Oct 2009 22:11:02 -0600 Message-ID: <5e09dc040910262111x5e848ce8j63c5ee0a568d99ef@mail.gmail.com> From: Ray Still To: freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: bind configuration issues X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 04:11:03 -0000 On Mon, Oct 26, 2009 at 6:42 PM, Steve Bertrand wrote: > Ray Still wrote: >> Ok, >> tell me just how nuts this idea is. > > imho, your thought-process is not nuts. I can see what you are trying to > do, so kudos given for trying to work it out with what you have. > >> To recap, two pipes, one destination. > >> I set up second DNS server. >> ns1.example.com at 70.65..... (provider 1) >> ns2.example.com at 206.75....(provider 2) >> A records for example.org on ns1 will give =A070.65..... >> on ns2 206.75.... >> if provider one goes down, ns1 is gone, ns2 is still available, and so >> is the route to the sites. > > Note: I haven't followed the entire thread... > > Remember that no matter where your name servers are located, they both > will hold the same information (if they don't, then shame on you, as you > just broke scalability). > > This means that other caching servers all over the 'net may have either > entry. Some ISP's name servers will cache records even longer than what > your TTL is set to without trying to re-check (shame on them). Hence, > you can never count on using DNS naming as a tactic for redundancy. > >> It's not the best solution, but it's better than what I have. > > If I understand your conundrum properly (one server with an internal IP, > with NAT in front of it, port-forwarded back aliased from two separate > ISP public IPs), then, at minimum, here's how you can essentially > 'halve' the damage: > > - set up your DNS servers in a proper master/slave configuration > - configure your 'A' records in a round-robin setup. I'll assume your > zone is ibctech.ca, and that your $TTL is 360: > > www =A0 IN A 208.70.104.210 > www =A0 IN A 208.70.104.211 > > (yes, I know 360 puts pressure on everyone else, but this is for example > purposes). > > If I know I will need to make DNS changes in advance for a domain, I'll > set the TTL to 360 (secs) long before the changes need to be made. Then, > I can make the changes, and if caching resolvers are Doing The Right > Thing, they will pick up these changes after five minutes. > > If you have a domain that is high-traffic, don't do this. I'd like to > emphasize that a low ttl puts pressure on every DNS caching server on > the Internet that must look up information on your domain. > > With that said, with a 5 min ttl, in the event of an outage, you can hop > onto your authoritative DNS server, switch BOTH A records to point to > the working IP, and the rest of the 'net 'should' be able to see those > changes within five minutes (again, if they obey your ttl). > > Steve > OK, after reading and re-reading and experimenting I think I get it. Thanks for your comments and patience. I will probably end up using something based on Gary's round robin suggestion. It may not provide 100% reliable failover, but it will help, and worst case, it will provide some bandwidth sharing. Thanks, Ray