Nsupdate and TTL

Tony Finch dot at dotat.at
Thu Apr 23 10:51:08 UTC 2020

Mark Andrews <marka at isc.org> wrote:
> > On 23 Apr 2020, at 07:20, Evan Hunt <each at isc.org> wrote:
> >
> > As far as I can recall, the only way to change a TTL in nsupdate is to
> > delete the whole RRset and then add it back in the same transaction:

There's actually a standard shortcut for TTL changes which is a
consequence of the slightly unexpected UPDATE semantics that we
discussed at the start of the month

If an update message contains a new record with the same RDATA as an
existing record, then the new record replaces the existing record. This is
usually a no-op, because all the other fields in the record necessarily
match - except if you are changing the TTL!

So you can simply re-write an existing RRSet with a new TTL, without
deleting anything. This has the great advantage of avoiding the
contradictory ordering requirements that you get from apex NS records
and CNAME records: to change a CNAME you must delete then add, but to
(completely) change an apex NS RRset you must add then delete.

nsdiff always does a delete then add so that it doesn't need special case
code for one weird RRset. The apex NS RRset case is very rare - the only
time I encounter it is when bootstrapping a zone from scratch, in which
case I need a second run of nsdiff to get rid of my "empty" zone `NS
localhost` record :-)

> Also don’t forget to add a prerequisite section to ensure you are removing
> the records you think you are.

nsdiff takes another shortcut here: it only uses the SOA serial number as
a prerequisite check, because if the serial number matches, then the zone
hasn't changed from the source zone file that nsdiff was working from.
nspatch includes an automatic retry loop in case the zone changes
unexpectedly, which is safe so long as conflicting changes only happen
from DNSSEC signing activity.


f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Forth, Tyne, Dogger: Northeast backing north later, 3 or 4. Slight. Fog
patches later. Good, becoming poor or very poor later.

More information about the bind-users mailing list