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

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/16/2011 08:12 AM, JINMEI Tatuya / 神明達哉 wrote:
> 
> 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()
> 

Ack.

> - 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.
> 

So that would be a reason to move the implementation details (getting
the various changes in the right order, if so required by the backend)
down to the actual datasource implementation, and make it a mandatory
feature of any ZoneUpdater implementation to be order-agnostic between
start and commit. More freedom for datasource implementors, less
restrictions on datasource users.

The reason to consider automatic serial updating would not be to support
DDNS per se. It is a requirement of DDNS by specification, but the real
reason IMO would be the same reason that it is a requirement there in
the first place; DNS zone changes don't get propagated if the serial
isn't incremented. One could certainly come up with use-cases where the
serial should not be updated. The question is whether those are real
enough, and whether they would support updates like this.

> - 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.
> 

If the use of such a class is essentially mandatory to work with every
datasource, it becomes the real API, and we might as well implement that
directly. Otherwise, you risk the chance that you get some modules that
only work with some datasources (and I am not thinking of NotImplemented
cases).

>> - - 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.
> 

Oh cool :) Yes please.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7uYtkACgkQ4nZCKsdOncVIFgCgttR4DTGzvP+EvuKdwHQdnnz7
jRIAn0PgBZ0aS68alu7Z/CNkILg7FJvk
=7gvP
-----END PGP SIGNATURE-----