We used tinydns for many years. After migration to nsd3 we miss only one feature present in tinydns only:
tinydns may switch addresses by decreasing the ttl for old data and serve new data
starting from a fixed timestamp.
http://cr.yp.to/djbdns/tinydns-data.html:
You may include a timestamp on each line. If ttl is nonzero (or omitted),
the timestamp is a starting time for the information in the line; the line will be ignored before that time.
If ttl is zero, the timestamp is an ending time (``time to die'') for the information in the line;
tinydns dynamically adjusts ttl so that the line's DNS records are not cached for more than a few
seconds past the ending time. A timestamp is an external TAI64 timestamp,
printed as 16 lowercase hexadecimal characters. For example, the lines
We used tinydns for many years. After migration to nsd3 we miss
only one feature present in tinydns only:
tinydns may switch addresses by decreasing the ttl for old data and
serve new data starting from a fixed timestamp.
http://cr.yp.to/djbdns/tinydns-data.html: You may include a
timestamp on each line. If ttl is nonzero (or omitted), the
timestamp is a starting time for the information in the line; the
line will be ignored before that time. If ttl is zero, the
timestamp is an ending time (``time to die'') for the information
in the line; tinydns dynamically adjusts ttl so that the line's DNS
records are not cached for more than a few seconds past the ending
time. A timestamp is an external TAI64 timestamp, printed as 16
lowercase hexadecimal characters. For example, the lines
This is a fairly substantial feature request, and cannot be in NSD 4.0
(which is now in beta and such large features are no longer accepted).
For 4.x, I am ambivalent, the question is how many people must have
this option versus its implementation complexity.
TTL=10 seconds instead of this feature, would that not have almost the
same semantics, except for higher server load before the timestamp is
reached? Is it about server load, and I think not, because the
timestamp creates a high server load peak, where a normal changeover
with a fixed TTL spreads out the query volume.
Or in any DNSSEC signed zone, as the TTL is covered by the RRSIG. You
would have to invent some new syntax. If you want something like this,
it is probably best to use dynamic updates and cron.
With a short TTL, you are guaranteed a high load for an extended time (basically as long as it takes to expire the previous longer TTL). The whole point of this feature is to decrement the TTL gradually up until the old record expires, then immediately switch over to the new record (with a more reasonable TTL). In practice, this means you only have a higher load for a relatively brief interval. Essentially, the server always serves up the appropriate TTL so that this records information will expire at the same time, no matter when the client requested the records.
I have to say I loved this feature when I used tinydns (years ago) because it meant I could switch over DNS records at night (when load was low) without interruption and without having to be awake...
