[bind10-dev] Ruminations on difference normalization (#1456)

JINMEI Tatuya / 神明達哉 jinmei at isc.org
Fri Dec 16 07:12:56 UTC 2011


At Wed, 14 Dec 2011 17:18:10 +0100,
Jelte Jansen <jelte at isc.org> wrote:

> I was just jotting down some notes on how to implement #1456 (Create
> diff-normalizer utility functions, as needed for DDNS). I had some
> ideas, and we had a bit of discussion on Jabber, but so far the results
> are inconclusive.

> Separate Structure:

> Extending ZoneUpdater:

> There is, of course, another alternative. We could also add a second
> type of Updater to DataSourceClient;

The difference between these is subtle, so it may be ultimately a
matter of taste.  With noting that, here are some random thoughts of
mine.

- In any case, it wouldn't make sense if normal applications have to
  be aware that the diffs have to be stored in an IXFR-style stream
  (except, implicitly, for xfrin, which needs to check the received
  IXFR response anyway, and as a result it happens to meet the
  requirement of the updater).  So the top level interface to these
  apps should work as follows:
    updater = TopLevelUpdater(Name('example.com'), RRClass('IN'))
    updater.addRRset(aaaa_rrset)
    updater.deleteRRset(mx_rrset)
    ...(any order of adding/deleting RRset)
    updater.commit()

- In my personal gut feeling, advanced features such as automatic SOA
  increment or sorting diffs are too advanced for the base updater.
  I'd keep that class as dumb as possible so that it can be used for
  many different (including yet unknown) types of data sources; in
  general if the class has richer functionality, it will be more
  likely that one of them is incompatible with some specific type of
  data source, resulting in introducing more and more "NotImplemented"
  cases.

- The current xfrin implementation actually uses a separate 'Diff'
  class, as a top level wrapper of the bare updater class.  To me,
  a similar approach seems to make most sense.

> - - any tool or module that uses the updater API can do it whilst
> supporting IXFR-out, without any requirements whatsoever (on the
> 'user's' side that is, naturally the datasource would need to support
> it, etc.). Immediate thoughts would be b10-ddns (and with the
> from-differences approach, AXFR-in and b10-loadzone as well). But also
> whatever we will build for auto-dnssec later, and dhcp-updates, and any
> other cool module someone comes up with later.

I can also think of a "zone editor", e.g., via the bindctl interface.

---
JINMEI, Tatuya



More information about the bind10-dev mailing list