[bind10-dev] Datasource discussion

[Michael Graff]

Shane Kerr wrote:
> All,
> 
> On Wed, 2010-01-13 at 11:31 +0100, Jelte Jansen wrote:
>> We started out talking a bit about updates, and transactions for that.
>> Michael suggested earlier that we could look into using diffs; this
>> could take the form of dynamic dns updates, i.e. a set of prerequisites,
>> and a set of changes. Then we wouldn't need a full transaction
>> interface, as the update methods can take care of that.
> 
> DNS is very "fuzzy" in general, so maybe not using transactions is
> indeed the way to go. It might allow us to do faster processing on
> updates, if we can lock only part of the tree based on knowing what all
> operations in a set are. OTOH, techies are familiar with transactions,
> and understand their benefits and limitations.

I think you misunderstand what was meant.

One way to do this would be to have the upper-layer call:

   lock()
   update(this_record)
   update(that_record)
   unlock()

Another would be to do this:

   record_change_set.add_change(this_record)
   record_change_set.add_change(that_record)
   update_atomically(record_change_set)

and let the lower level API decide how it manages its locking, if any.

> One specific problem with this approach is that it doesn't work so good
> with queries, unless you introduce a basic query which says something
> like "give me the NS RRSET for foo.example, plus also any A or AAAA
> RRSET that you have for the name server names we're authoritative for".
> Otherwise your server can end up replying with an NS RRSET that has
> non-existent A/AAAA records even if the administrator never configured
> it in such a way. Not a *huge* problem I suppose, but we need to at
> least recognize and document the possibility.

This is an argument to mean a good DS would also know a bit about DNS 
protocols.  I don't think this is a bad idea, and I also don't really 
mind if the data changes from under the client IF there is a way to, for 
DS drivers which support it, maintain version consistency.

> Maybe we need to ask the question "how important is always giving a
> completely consistent answer?" to users? Or rather, "how much
> performance would you be willing to give up to get a completely
> consistent answer?"

How does PowerDNS ensure sanity here?  I somehow doubt it bothers. 
After all, if we don't respond with data the client can usually ask for 
it.  If we provide old data, it's also ok so long as it's not "too" old. 
  We're talking about sub-millisecond differences in data where a query 
may come in and get something strange.  Note that my change-sets will 
mitigate a lot of this as an IXFR will contain both updates and apply 
them atomically.

--Michael