bind configuration issues
rstill74 at gmail.com
Tue Oct 27 04:11:03 UTC 2009
On Mon, Oct 26, 2009 at 6:42 PM, Steve Bertrand <steve at ibctech.ca> wrote:
> Ray Still wrote:
>> 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 188.8.131.52
> www IN A 184.108.40.206
> (yes, I know 360 puts pressure on everyone else, but this is for example
> 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).
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.
More information about the freebsd-questions