 |  |
At 11:48 AM -0500 2/10/01, Mitch Kahn wrote:
Re: (OT) Changing IP Numbers and ISP''s
From: Men & Mice Support
Date: Monday, February 12, 2001
Time: 12:44:28 am
>Chris,
>
>Thanks. You are correct I was and still am very confused about the
>different values.
>
>In the scenario that I outlined, I will not really have a secondary
>initially (and apparently don't have one now thanks to my ISP), but
>the DNS server registered as a secondary won't work until my new ISP
>has their circuit installed to me, at which point all of my network
>numbers will change since I am disconnecting my current provider at
>that time.
>
>What values do you suggest that I use for "Expire" - "Minimum" and
>"Time-To-Live" on my primary in order to accomplish my goals?
Expire: 604800 (the default)
Minimum, during the switch: 3600
Minimum, normally: 86400 (the default)
TTL (for the SOA record): 86400
I'd suggest blank for the TTL, but unfortunately QuickDNS has a habit
of filling that in with the Minimum value if it's left blank.
>Since the rest of the zone is unaffected by the TTL Minimum field,
>what am I missing concerning the rest of the zone?
The rest of the zone is unaffected by the TTL field. Not true of the
Minimum field, which is the default TTL for any record that doesn't
have an explicit TTL.
>What settings should I use for Refresh and Retry on the primary?
The defaults.
>Am I even asking the right questions?
Yes.
____________________________________________________________________
Chris Buxton Men & Mice
cbuxton@menandmice.com We Make DNS Easy!
>At 6:31 PM -0500 2/9/01, Men & Mice Support wrote:
>>Your plan sounds like it will work just fine, but I think you're
>>probably confused about the roles of the various values of the SOA
>>record (the Refresh, Retry, Expire, Minimum, and TTL values).
>>
>>The only thing other people's DNS servers will ever pay attention
>>to is the TTL of whatever record they retrieve from your servers.
>>The TTL of any given record is determined as follows:
>>
>>- If the record has an explicit TTL (as part of the record), use that.
>>- Otherwise, use the value from the Minimum field.
>>
>>The TTL you see next to the Minimum field is the TTL for the SOA
>>record. It doesn't affect the rest of the zone in any way.
>>
>>The Expire field is used by your secondary server. If the primary
>>server stops responding to requests from the secondary server,
>>after [expire] seconds, the secondary server will stop serving the
>>domain. This is generally not what you want to happen, though if a
>>secondary server is not reconfigured when the primary server is
>>moved, you do want it to stop serving the domain in a reasonable
>>amount of time. To balance the two, it is common to set the Expire
>>field to a value between 1 and 4 weeks.
>>____________________________________________________________________
>>Chris Buxton Men & Mice
>>cbuxton@menandmice.com We Make DNS Easy!
>>
>>At 1:45 PM -0500 2/9/01, Mitch Kahn wrote:
>>>Please excuse the cross post (WebSTAR and QDNS), but I know there
>>>are number of experienced pros on both lists and I am looking for a
>>>weakness in my game plan.
>>>
>>>________________
>>>
>>>Background
>>>
>>>A. We plan on moving to a new up line ISP soon. Since our clients
>>>get hit by a lot of dial ups many of whom come from AOL we are
>>>concerned about the amount of time that it takes for information to
>>>propagate through AOL's DNS servers.
>>>
>>>B. Since our ISP was supposed to have a secondary DNS server that
>>>automatically picked up the settings from our primary we thought we
>>>were covered. I have discovered that no setting changes have been
>>>picked up by the secondary in months and many domains that we have
>>>listed on our primary are not on the secondary at all. Several calls
>>>to our ISP have gotten us nowhere.
>>>
>>>C. In preparation for the move and change in IP addresses we have
>>>developed the following strategy to minimize down time and
>>>inaccessibility from the net. Any comments pro or con on our game
>>>plan are welcome.
>>>
>>>
>>>DNS Move Strategy
>>>
>>>1. We have already changed the "Expire" settings to 86400 on each
>>>domain and the "Minimum" and "Time-To-Live" to 3600. Two days before
>>>the change over we will reduce "Expire" settings to 43200 on each
>>>domain and the "Minimum" and "Time-To-Live" to 300. The night before
>>>the move the "Expire" settings will be further shortened (amount to
>>>be determined).
>>>
>>>2. We really don't have a secondary DNS server so we believe that we
>>>have nothing to lose by the following strategy: we plan to register
>>>a new secondary DNS on the new IP addresses assigned by our new
>>>provider. We will change the registration for the secondary on all
>>>of our domains to our new secondary.
>>>
>>>3. Our new secondary will be set up with the IP addresses that will
>>>be assigned to the sites when the service changes over. Since this
>>>secondary DNS server will not be accessible from the Internet until
>>>we change over, the new information will not be available until we
>>>go live.
>>>
>>>4. When our new T-1 line is installed we will reassign the numbers
>>>on our servers to the previously mapped out numbers on our new
>>>secondary DNS server. Our primary DNS will be changed to our new IP
>>>address range and a change of address will be filed with our
>>>registrar - Network Solutions.
>>>
>>>Our thinking is that since Ameritech (SBC) is painfully screwed up
>>>and will not install our new line for at least three or four weeks
>>>(and possibly as long as 60 days), the new secondary DNS server
>>>information should be fully propagated throughout the Internet by
>>>then. The primary will not be available when we move the router to
>>>the new line, so the secondary server will provide all information.
>>>The short "Expire" - "Minimum" and "Time-To-Live" settings should
>>>force servers to update off the secondary (which will have more
>>>standard settings so that it doesn't get pounded after the first
>>>go-around).
>>>
>>>5. After a week or so we will add a tertiary DNS server on someone
>>>else's subnet and update Network Solutions to cover us incase our
>>>connection goes down.
>>>
>>>Thanks for your comments,
>>>
>>>Mitch Kahn
>>>mitch@middlecoast.net
>>>616.241.5650 x10
Messages In This Thread:
Return to Digital Point Solutions' Home Page