On Mon, Oct 26, 2009 at 6:42 PM, Steve Bertrand <st...@ibctech.ca> 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 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 >
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 _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
