Date: Mon, 26 Oct 2009 20:42:18 -0400 From: Steve Bertrand <steve@ibctech.ca> To: Ray Still <rstill74@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: bind configuration issues Message-ID: <4AE641EA.2070003@ibctech.ca> In-Reply-To: <5e09dc040910261613x4d91116epf397bfc35955f65d@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 70.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 IN A 208.70.104.210 www 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AE641EA.2070003>