dynamic dns update?

[Kevin Darcy]

Dynamically updating the DNS is the easy part. What's harder is dealing with
the fact that servers all over the 'Net still have the old record cached.
Here's my mini-treatise on the subject:


> To do this with DNS, there's no really *good* way until all clients know
> about
> "SRV" records. These relatively-new resource records add a layer of
> indirection
> to the resource-location process, and have "preference" values associated
> with
> them, so clients using them know exactly in what order servers should be
> tried. Unfortunately,
> SRV-aware web clients are probably years away.
>
> The simple-minded DNS-based approach is to just change the A record for the
>
> website when the main box goes down (possibly using some sort of automated
> script, possibly making the change via Dynamic Update). The main problem
> with
> the simple-minded approach is caching: anyone who has the old record cached
> in
> some intermediate nameserver will still go to the "dead" server even if the
> A
> record has been changed on the master and the change has been propagated to
> all
> of the slaves. Unlike NOTIFY in the master/slave context, there's no
> practical
> way to tell every caching nameserver on the 'Net that a particular A record
> has
> changed, and that they should all come and fetch the new value.
>
> A refinement of the simple-minded approach is to have the name of the
> website
> resolve to *both* addresses, and arrange for them to always be given out in
> the
> appropriate order, i.e. main website first, backup second. This can be
> achieved
> by specifying a "fixed" rrset-order on the master and all slaves for the
> zone
> (you need at least BIND 8.2 for this, and for security reasons that means
> you'd
> be wanting to run BIND 8.2.2 patchlevel 5). Some applications are smart
> enough to
> automatically failover, so for those clients this means more availability
> (after a short failover delay) during a failure of the main box, even if
> they
> get a "stale" RRset. Then again, some clients are *not* smart enough to do
> this
> failover, so it's a partial solution at best. Moreover, caching complicates
>
> things here as well: for multi-valued A records, intermediate caching
> servers
> will tend to randomize/round-robin the order of the answers they give out.
> This
> re-ordering effect actually *helps* you in failure mode -- it means that
> approximately 50% of the clients getting a stale RRset will still be able
> to
> connect without any failover delay -- but the flip side is that under
> normal
> circumstances, when the main box is up, it means that there will be a
> certain
> amount of "leakage" to the backup webserver. If you don't want to
> continually
> mirror the website contents, you can of course deal with this leakage
> traffic
> straightforwardly via a web redirect on the backup webserver, but that will
> add
> latency. When the main website fails, then remove its A record from the
> RRset
> and turn off the redirect (if any).
>
> Note that with either approach, you can mitigate -- but not completely
> eliminate -- the effects of intermediate caching servers by making the
> address
> records volatile (by reducing their TTL values). But this will greatly
> increase
> the traffic to your nameservers for that name, not to mention the extra
> work
> you'll cause for all other nameservers on the 'Net to constantly re-query
> the
> name. Overall, it's a Bad Thing, but many folks resort to it nonetheless.
>
> There are non-DNS solutions to this problem, of course. The obvious one is
> to
> just have lots of redundant network paths so that access is "never" (never
> say
> never) lost to the main webserver, and of course the webserver itself
> should be
> clustered or high-availability so that it "never" goes down, but this
> "brute
> force" approach can get expensive. And then there are specialized
> hardware/software failover
> solutions, which also tend to be expensive. Some of these make *both*
> servers look like the same IP address, and the failover
> happens transparently. Some of them also integrate dynamic load-balancing
> between webservers, which is probably something you want if you outgrow
> your
> current webserver capacity.
>
>
>
> - Kevin



Adam KOSA wrote:
Hello everyone

I'm looking for a solution for my problem: we have two web servers with
different names and ip numbers.  I'm looking for sime kind of dynamic dns,
so if the main www server fails, the backup www acts like the main, but i
also need to update the DNS record. is there some kind of rfc, that
describes this? is this even possible?

thanks
adam

=====================================================================
| Adam Kosa                               | Experience is something |
| E-mail: ka at ka.wox.org ka286 at hszk.bme.hu | you get right after you |
| HP    : http://home.sch.bme.hu/~bufi    | need it.                |
=====================================================================