[bind10-dev] ddns

[Shane Kerr]

Jelte,

Thanks for kicking this off.

On Fri, 2011-11-25 at 17:57 +0100, Jelte Jansen wrote:
> 
> - the one thing i gathered from early discussions with users is that
> they would want the option not to run any ddns code at all if they do
> not use it, so it would make sense to me to make a separately running
> module for handling ddns packets.

Agreed. In fact, this is important for resilience too.

> - I think we should pass off DDNS messages from auth to ddns
> module similarly to how we do it for xfrin

Agreed. A question though, is it possible to do a DDNS update via UDP?

> - Naturally it should only work on zones for which we are master, and
> the datasource should be writable
> - Also naturally, we will need ACL checks done here

IIRC, the RFC describes exactly where ACL checks should be done in the
processing. I believe that the RFC is bogus, because it requires extra
checking beyond what should normally be done.

I think this caused an information leakage bug in BIND 9, which revealed
presence or not of zones, regardless of the status of the ACL. I think
the answer to this was to remember that a zone does not exist, and then
fail later after the ACL checks have completed - with the appropriate
ACL errors if necessary.

> - The module should handle the updates, and form (one or more) DDNS
> commands into a form so that ixfr-out would still work (see adddiff
> docs)
> - I think we could quite easily support multiple updates
> rolled into one change (by waiting for a bit for additional update
> commands before committing), but it does depend on how good
> transactions work on the backend (idling around if you have one giant
> lock on the db does not seem like a good idea).
> - I think the biggest difference between ixfr and ddns is that we have
> prerequisites. So we need to make sure our finder can retrieve all
> necessary information.
> - Another difference is that, unless updated by the ddns command, we
> need to increase the serial, and we can choose several approaches for
> that. This is something i think should be completely done by the ddns
> module (and not the datasource).

Okay that makes sense. A minor border case is what to do if the DDNS
command sends the same SOA as the zone already has. I tend to think we
should respect that, so we can't just look for a difference in SOA
between the old and new zones, but rather if we got any SOA update at
all.

> So an initial task breakdown could be:
> 1) Create a module that handles ddns packets, with skeleton functions
> for 2, 3, and 4, and which initially responds with either NOTIMPL or
> REFUSED
> (the rest will certainly depend on 1)

Makes sense.

> 2) Add ACL checking

Is this a single ticket, or multiple tickets? So, perhaps:

2a) Add DDNS ACL configuration.
2b) Use DDNS ACL configuration to do checking.

> 3) Implement prerequisite checking (this can probably be
> broken down into several smaller ones)

Like...

3a) DDNS prereq nxdomain
3b) DDNS prereq yxdomain
3c) DDNS prereq nxrrset
3d) DDNS prereq yxrrset

Perhaps? Or...?

> 4) Assuming that the prerequisites are checked, take the update part
> and feed it in the correct form to the datasource.
> 5) We can probably initially get away with doing 4 without any
> consistency checks, but we should really do those as well. This would,
> I think, depend on 4 being done though (or it should be done in 4).

Perhaps 4 and 5 can be done in parallel at least.

--
Shane