Re: Deathrow Cluster down again
- From: "Richard B. Gilbert" <rgilbert88@xxxxxxxxxxx>
- Date: Fri, 24 Jul 2009 10:55:47 -0400
John Santos wrote:
In article <slrnh6hva9.4gq.BRAD@xxxxxxxxxxxxxxxxxxxxxxxxx>, BRAD@xxxxxxxxxxxxxxxxxxxxxxxxx says...>In article <c6ccf3ae-6867-4d6b-a028-cf10cd78e2b8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Mike K. wrote:
It's still down for me. I get a "No route to host" error when I try toThanks for the follow-up; I was reporting from Central MA., using Comcast. Just got to it a few minutes ago (2010 US Eastern)
connect. If it's working for other people, then it might just be a
problem with Verizon (or even Verizon in Boston)
I've been thinking of switching to Verizon FIOS, recently available in my area;
perhaps I'll wait...
I'm on Verizon FIOS just outside Boston and it's working fine for me.
But I'm using my DNS from work (TCPware), piped over a VPN. Verizon's
DNS servers have a reputation for going out to lunch frequently. I don't know why, and have never seen any actual confirmation of this,
but just today on the internal Verizon news groups (0.verizon.adsl
and 0.verizon.fios - you need to be on the Verizon NNTP server to see
these), there were several complaints about DNS being broken in the
Boston area. (I think they have a bunch of regional DNS servers and
pass the addresses of the closest ones to the routers (FIOS) or client
(DSL) via DHCP when they connect.) The conventional recommendation is
to run your own DNS server, or to use OpenDNS (which I think is a 3rd
party DNS service.)
Configuring a DNS server is not terribly difficult these days. The documentation is much improved and, last time I looked, the documentation plus HELP were enough to configure a server and make it work. Go thou and RTFM and RTRFC (read the RFC). You can get a caching server running fairly quickly. If you need to get your own machines listed, you will have to build some data files and configure
your server to use them.
It has been years since I last needed to do this. It is most helpful to have some familiarity with both the TCP/IP services documentation and the relevant RFCs (1032, 1033, 1034, 1035, 1183). A text called "DNS & BIND" published by O'Reilly & Associates may also be helpful.
Set a SHORT TTL (Time To Live) until you are certain that everything is working properly. Once you are satisfied that everything is working correctly, you should increase the TTL to at least twenty-four hours.
A TTL of two to seven days is not unreasonable if you will not be making any changes. When you must make changes, set your TTL in stages, to some REALLY small value; ten or fifteen minutes. Be sure to RESET your TTL when you have finished making changes.
Suppose you plan to make changes to your DNS database. Set your TTL to the time remaining before the change. As you begin each new day, reduce your TTL by one day. When you get down to 24 hours reduce your TTL hourly. During the last hour set your TTL to 3-5 minutes.
If you've done everything right, when the change takes effect the disruption should be minimal. Your DNS server will be busy for a while but nobody should be getting, or using, obsolete data!
OTOH, if your provider employed anyone with a brain, you wouldn't need to!
.
- References:
- Deathrow Cluster down again
- From: Mike K.
- Re: Deathrow Cluster down again
- From: Richard Maher
- Re: Deathrow Cluster down again
- From:
- Re: Deathrow Cluster down again
- From: Richard Maher
- Re: Deathrow Cluster down again
- From: Mike K.
- Re: Deathrow Cluster down again
- From:
- Re: Deathrow Cluster down again
- From: John Santos
- Deathrow Cluster down again
- Prev by Date: Re: London Stock Exchange to move away from Windows
- Next by Date: Re: London Stock Exchange to move away from Windows
- Previous by thread: Re: Deathrow Cluster down again
- Next by thread: Re: Deathrow Cluster down again
- Index(es):
Relevant Pages
|
