bind configuration issues
steve at ibctech.ca
Tue Oct 27 00:42:22 UTC 2009
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 184.108.40.206
www IN A 220.127.116.11
(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).
More information about the freebsd-questions