Brian Utterback wrote: > Danny Mayer wrote: > >> Harlan Stenn wrote: >> >>> This is becoming more and more common - people assign 1 IP per >>> 'service' so >>> the service can be easily put on an arbitrary machine, or they use >>> several >>> IPs for the service on different subnets/vlans for network >>> architecture and >>> security reasons. >> >> >> This sounds like laziness. Instead of updating the DNS to change the IP >> address of a name, they add move the IP address to a different machine. >> It doesn't make much sense to me. >> > > Really? Consider: > > The service is administered locally to a system and although the > IP address may be administered by someone else, it will usually > be fairly close (i.e. the local sub-net) and doesn't require any > further administration once assigned. The DNS may be administered > non-locally or even globally, with potentially two separate > organizations required to change it (one for forward lookups and > one for reverse lookups). Once the DNS is changed, it takes some > time to propagate the change due to caching, and already running > applications may never see the change unless they re-resolve. > Having one service per IP address also makes the job of > load-balancing software much simpler. > > Brian Utterback
I believe that there is a solution to the DNS caching problem. Each DNS record can be given a "Time To Live" or TTL. If you are planning to change the record, set the TTL to seven days, then six, five, four, three, two, one. . . . All of those cached records should expire at more or less the same time. It's not perfect but it works. If you time it just right, you can minimize the amount of disruption. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
