OIT Networking & Monitoring Services

Scheduling a Host Database Change For a Specific Time

In rare cases, there is a need for a customer to request that a change to a Host Database entry (or set of related changes to a set of Host Database entries) be scheduled to happen at a specific time.

This may be desirable when the change will alter the mapping between a DNS name and IP address, if the DNS name is one that belongs to a production server, and some constraint exists which requires that the DNS alteration happen at a particular time.

There is usually no need for a "scheduled change" when the change will not affect DNS, or when the name or IP address being changed does not belong to a production server. Most Host Database changes are for entries belonging to clients (not servers), and do not need their Host Database changes to be scheduled to happen at a specific time. And even for servers, scheduled changes are often unecessary when the server is a test or development server, or serves a very limited population; only production servers upon which clients rely typically justify "scheduled" Host Database changes. As scheduled changes are labor intensive, please limit your use of them to situations that truly require such handling.

Contents

  1. How to Request a Change For a Specific Time
  2. Typical Handling
  3. Detailed Timeline

How to Request a Change For a Specific Time

To request a scheduled change to a Host Database entry, send email to hostmaster@princeton.edu at least six full business days in advance of the desired change date, with a description of exactly what should be changed and the date/time of the change.

For example: "At 5:00 am Wednesday March 2, change entry foo.princeton.edu to remove alias bar.princeton.edu; then change entry baz.princeton.edu to add alias bar.princeton.edu." If the exact time of the change is unimportant to you, you may specify the date without a specific time; in that case, hostmaster may commit to a day with no specific time commitment.

Keep in mind that the effects of a Host Database change are not truly instantaneous. Any change, even a scheduled change, takes time to reach all possible consumers of the Host Database. A detailed timeline appears below.

When selecting a date and time for the change, note that:

Sending your request to hostmaster@princeton.edu at least six full business days in advance of the desired change date is an absolute minimum. Contacting hostmaster further in advance increases the likelihood that we will be able to accommodate your request, or advise you sooner if we cannot accommodate the request.

Advance notice is needed for several reasons:

If you are requesting a change to any Host Database entry for which you are not among the Technical Contacts or Host Database Departmental Contacts, hostmaster will need to obtain authorization from one of those authorized contacts before committing to making your requested Host Database change. To avoid that situation, have someone who is among the Technical Contacts or Host Database Departmental Contacts request the change. Otherwise, hostmaster will need to contact those authorized parties on your behalf to seek approval from one of them. As this adds additional delay (days, sometimes weeks), it is to your advantage to submit such requests even further in advance, and to encourage any authorized party to respond promptly to hostmaster to approve your request.


Typical Handling

The sequence below is typical for a scheduled Host Database change.

Within three business days after receiving your mail requesting the change, hostmaster will begin handling your request:

Once all items above have been completed, within three business days hostmaster will send email to you committing to make your scheduled change. No further action on your part is needed from this point forward.

It is your responsibility to not alter the affected Host Database entry or entries in any way that would make your requested change impossible. Hostmaster reviews your requested change at the outset of the process above to ensure it is feasible. If the relevant Host Database changes are changed by you or some other authorized party before the time of scheduled change, and that change makes your request impossible or problematic, hostmaster is unlikely to discover this until the time of the scheduled change, if at all.

Assuming you placed your request with hostmaster early enough, Hostmaster will reduce the DNS Time to Live (TTL) for the entries involved from their normal 12 hour Time To Live (TTL) to a 10 minute TTL. This is done at least 16 hours before the time of the scheduled change so that it will be fully effective by the time of the scheduled change. You may not see email showing this DNS TTL change happen.

You may be surprised to see email showing your requested change being performed as early as the day before you specified. For example, if you requested the change to happen 5:00 am March 2, you may see email showing the change being processed during the late afternoon of March 1. This is normal; it means that hostmaster has staged the change, and scheduled the change to begin flowing to consumers of the Host Database on the following morning. (In fact, during the interval from the time your change is staged until it is scheduled to take effect, no other Host Database changes can happen University-wide; all incoming requests are queued but not processed.)


Detailed Timeline

No change to the Host Database is truly instantaneous. There are many consumers of the information in the Host Database; these include Domain Name Service, OIT DHCP and OIT BootP Services, OIT Mobile IP Service, OIT Wireless Service, and OIT NIS maps, to name a few. It takes time for the results of the change to reach those consumers. There is a period while some consumers will use the old information, yet others will use the new information; there is a period of flux.

If you specify that a change should happen "at 5:00 am", what will really happen is described below.

Note that throughout this document, references to OIT DNS Service mean the specific service described in that document; they do not mean "any DNS service OIT may provide."

References to "DNS clients" should be understood to mean "DNS clients which respect DNS TTLs." Clients which fail to respect DNS TTLs may continue using old DNS information for periods which OIT can neither predict nor control.

  1. The new information will begin flowing out of the Host Database at the time you specified (for example, 5:00 am), plus or minus fifteen minutes. We cannot arrange for the data to begin flowing more precisely than that.

  2. The earliest any consumer might begin using the new information is the time you specified less fifteen minutes (4:45 am). This doesn't mean that this is when any clients will start using the new information, only that no consumer will use the new information before this time.

    For example, it's possible some DNS client might start using the new information at this time (4:45 am).

  3. By 15 minutes after the information begins flowing out of the Host Database, it will finish reaching all on-campus DNS servers which provide OIT DNS Service. This assumes normal operation of the campus network and the servers involved. In the example above, the latest the change would begin flowing is 5:15 am, so this means it will finish reaching all on-campus DNS servers operated by OIT by 5:30 am.

  4. By 10 minutes later (by 5:40 am in this example), those on-campus DNS clients which use OIT DNS Service all will be using the new information; they will no longer use the old information. This is a result of the 10-minute DNS TTL hostmaster temporarily set for the affected names earlier. (Normally it would be 12 hours, not 10 minutes.)

    This implies that there is a 55-minute window (4:45 am - 5:40 am) during which time the information may be in flux for these clients, transitioning from the old to the new data.

    (If you placed your request so late that hostmaster could not effectively reduce the DNS TTL (from 12 hours to 10 minutes) at least 16 hours prior to the time of the scheduled change, on-campus DNS clients of OIT DNS servers will take up to 12 hours to stop using the old information; there would be a 12 hour and 45 minute window (4:45 am - 5:30 pm) during which time the information may be in flux for these clients.)

    It is important to remember that these timeframes are true only for those on-campus clients which DNS as their naming system, respect DNS Time To Live (TTL) values, and are using OIT DNS Service. An on-campus client which does not use DNS as its naming system, or does not respect DNS TTLs, or is not using OIT DNS Service might continue to use the old data for an unspecified, perhaps unlimited, period.

  5. Various OIT services other than DNS also rely on the Host Database. These include, for example, OIT DHCP and OIT BootP Services, OIT Mobile IP Service, OIT Wireless Service, and OIT NIS maps, to name a few. These are not governed by DNS TTLs. As a rule, the earliest any of these services will see the change is when the new information begins flowing out of the Host Database (4:45 am). The data used by these services will be in flux for up to an hour after the time of the scheduled change; by the end of that hour (6:00 am), the new data will have reached all OIT services that rely on the Host Database.

  6. By 3 hours after the information begins flowing out of the Host Database (as late as 8:15 am in this example), it will finish reaching all off-campus secondary DNS servers.

  7. By 10 minutes later (as late as 8:25 am in this example), off-campus DNS clients will be using the new information; they will no longer be using the old information. This is a result of the 10-minute DNS TTL hostmaster temporarily set for the affected names earlier. (Normally it would be 12 hours, not 10 minutes.)

    These values assume the clients use DNS as their naming system, respect DNS Time To Live values, and are using DNS servers that operate properly.

    On-campus DNS clients that do not use OIT DNS Service may behave like off-campus DNS clients in this respect. (This assumes the client uses DNS as its naming system, respects DNS Time to Live (TTL) values, and relies on DNS server(s) which function properly and respect DNS TTLs. If any of those assumptions does not apply, then the client may continue to use old data for an unspecified, perhaps unbounded, time period.)

    This implies that there is a 3 hour and 40 minute window (4:45 am - 8:25 am) during which time these DNS clients will be in flux, transitioning from the old to the new data.

    (If you placed your request so late that hostmaster could not effectively reduce the DNS TTL (from 12 hours to 10 minutes) at least 16 hours prior to the time of the scheduled change, the DNS clients will take up to 12 hours (as late as 8:15 pm) to stop using the old information. There would be a 15 hour and 30 minute window (4:45 am - 8:15 pm) during which time the information will be in flux for these clients.)

To summarize these timeframes, for a change scheduled to happen at 5:00 am:

Assuming DNS TTLs were reduced to 10 minutes at least 16 hours in advance:

   4:45 am    earliest time any client will begin using the new information; data is in flux
   5:40 am    on-campus DNS clients of OIT DNS Service are all using new information
   6:00 am    OIT services other than DNS (e.g. DHCP, BootP, Mobile IP, Wireless, NIS) are all using new information
   8:25 am    other DNS clients (of properly-functioning DNS servers) are all using new information

If DNS TTLs were not reduced to 10 minutes at least 16 hours in advance:

   4:45 am    earliest time any client will begin using the new information; data is in flux
   6:00 am    OIT services other than DNS (e.g. DHCP, BootP, Mobile IP, Wireless, NIS) are all using new information
   5:30 pm    on-campus DNS clients of OIT DNS Service are all using new information
   8:15 pm    other DNS clients (of properly-functioning DNS servers) are all using new information

The timeline above assumes normal operation of the campus network and the servers involved. If some unforseen server failure or network disruption were to happen, the change might not happen as scheduled, or might not adhere to the timeline above.

A day or two after the change is over, hostmaster will change the affected DNS TTLs back to normal (from 10 minutes to 12 hours). You may not see email showing this DNS TTL change happen.


A service of OIT Networking & Monitoring Services
The Office of Information Technology,
Princeton University
Last Updated: July 11 2017