On Tue, Apr 21, 2009 at 5:13 PM, Chyka, Robert <bch...@medaille.edu> wrote: > We are moving to Time Warner Business and they basically gave me the power > to create my own MX, A, PTR etc in their DNS ...
It's generally easier if you separate your DNS hosting from ISPs providing the feeds. Changing feeds is complicated enough without changing DNS hosting at the same time. Most of the domain name registrars throw in free DNS hosting these days, so this shouldn't even cost a lot. (If yours doesn't, find a better registrar.) The procedure for a change in nameservers is: A1. Configure DNS zone with records to match existing DNS records at old ISP A2. Change NS records at the registrar to point to the new nameservers A3. Wait for any propagation delays (72 hours minimum is the usual recommendation) A4. Tell the old ISP you've switched to third-party DNS hosting and to delete the zone from their nameservers A5. Confirm previously-delegated nameservers at old ISP no longer claim authority Once that's done, the procedure for a feed change is: B1. Get new feed installed, tested, and up and running B2. Change DNS records (A, MX, etc.) to specify new feed IP addresses B3. Wait for propagation delays B4. Confirm mail is coming in through new feed B5. Unplug old feed B6. Confirm everything still works B7. Notify old ISP to terminate service Alternatively, if you want to keep DNS hosting with the feed providers: C1. Configure DNS records at new ISP DNS to match your existing DNS records at old ISP DNS C2. Get new feed installed, tested, and up and running C3. Notify registrar to change delegation to new ISP C4. Wait for any propagation delays (72 hours minimum is the usual recommendation) C5. Change DNS records at both old ISP DNS and new ISP DNS to specify new ISP feed C6. Wait for propagation delays C7. Confirm mail is coming in through new feed C8. Unplug old feed C9. Confirm everything still works C10. Notify old ISP to terminate service You technically don't have to do step C2 until you do step C5, but by getting it ready sooner you have more options in case things go wrong. The delay for B3 (or C6) is directly proportional to how important mail flow is. The more important mail flow is, the longer you should wait. In theory, this delay should just be the TTL on your DNS records, but it seems there are always some mail hosts that are ignoring TTL for whatever reason. Especially short TTLs. You can reduce propagation delays in the feed change step by reducing the DNS TTL (Time To Live) values in advance of step B2 (or C5). TTL controls how long other DNS resolvers cache records for your zone. This is often a day or a week. Reduce it to one day a week in advance, then reduce it to an hour a day in advance. Once the dust settles, turn TTL back up. > Do I have to first call our current > provider and tell them that we are discontinuing our service so they take > our records out of DNS so I can add the new ones? If you do that *first*, you'll prolly interrupt mail flow. The old ISP will remove the DNS records from their nameservers before the delegation from the registrar has changed. If you're not familiar with how DNS works: There are registrars (Network Solutions, GoDaddy, Registrar.Com, etc.). Registrars process your domain name registration and publish a delegation (NS records) for your domain. The delegation tells the rest of the world what nameservers to ask for information on your domain. Nameservers answer queries from the rest of the world. Nameservers can be hosted anywhere by anyone. You can host them yourself, or the ISP providing the feed can do it, or the registrar can do it, or a third-party company can. So when the rest of the world wants to look up, say, <microsoft.com>, they first ask the authoritative nameservers for the <.com> top-level domain, "What's the IP address for <microsoft.com>?" The TLD nameservers says, "I don't know -- ask <ns1.msft.net>." The rest of the world then find <ns1.msft.net> and asks, "What's the IP address for <microsoft.com>?" (This is an oversimplification, but it will do.) -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
