Dynamic IP & cache DNS

[Kevin Darcy]

Brad Knowles wrote:

> At 5:12 PM -0400 9/10/01, Kevin Darcy wrote:
>
> >  I recently proposed a protocol extension that would implement a "callback" to
> >  nameservers when a particular piece of data changes (using a generalized form
> >  of NOTIFY). This would, I think, provide the best of both worlds -- being
> >  able to set a reasonably-long TTL in the general case but at the same time
> >  being able to make sudden changes visible rapidly. Unfortunately, the
> >  proposal was shot down as requiring the maintenance of too much state
> >  information in nameservers.
>
>         As well as being simply unnecessary.  Domain managers can reduce
> their TTLs before making a change that they know needs to propagate
> quickly, and then re-instate more realistic TTLs once the change has
> been made.

That works fine for changes scheduled way in advance. It doesn't work so well when
you've been using long TTLs and suddenly discover you need to make a change NOW,
but the old value is cached all over the 'Net. Nor does it work so well with the
DNS-based dynamic load-balancing and/or failover systems that I know you love so
much.

>         There's simply no need to have your "callback" mechanism, and it
> is way too much work to expect nameservers to be able to deal with.
> They're having a hard enough time just keeping up with the number of
> queries per second they can have aimed at them during times of
> stress, running out of memory, etc....

And why are they having such a hard time? Largely it's *because* of those short
TTLs, and the excessive query traffic associated with them. I think "generalized
NOTIFY" (or "callback" or whatever you want to call it) would more than pay for
itself in terms of conserving resources, because it would allow the domain owners
to go back to reasonable TTLs while still providing the dynamism they want/need.
This should reduce overall query volume at the expense of requiring participating
nameservers to save some state information instead. The memory-usage versus
query-volume tradeoff would no doubt be very attractive to many sites.

Plus, it would be a totally *optional* extension, which a server could honor or
dishonor any time it feels like. A server which is having resource-exhaustion
problems would always have the option of declining clients' callback requests
temporarily, thus reverting to the "old-fashioned" way of doing things (using a
smaller TTL than if callback were in effect, to provide the needed dynamism). So
servers and clients would optimize when and where they *can*, and if they can't,
things are no worse than they are today.


- Kevin