[bind10-dev] DDNS acl then prereqs or vice versa

[JINMEI Tatuya / 神明達哉]

At Tue, 05 Jun 2012 18:02:55 +0200,
Jelte Jansen <jelte at isc.org> wrote:

> as we all know, the DDNS RFC defines a slightly strange order of

"slightly"?  Maybe you're trying to be polite, but my understanding is
that no one thinks the RFC's behavior on this point makes sense at
all:-)

> processing the update request; if one follows the spec, than it would
> perform prerequisite checking first, then go ahead and see if the
> requestor is allowed to do an update in the first place.
> 
> I *thought* we had already agreed not to do this (but rather check ACL
> first), but I can't really find any proof of that right now.
> 
> Reasons to follow spec: we are supposed to be a reference implementation.
> Reasons not to follow spec: it makes no sense and leaks data. It also
> causes unnecessary transactions (which must have been started to do
> the prereq checking), but that is a relatively minor point.

We discussed this about half a year ago.  See this and some of the
followup messages.
https://lists.isc.org/pipermail/bind10-dev/2011-November/002827.html

Re-reading the thread, I can see the sense of supporting the change of
the processing order so the ACL check takes place before prerequisite
checks.  I just don't see a clear conclusion at that time though.

We also discussed this matter at the IETF dnsext ML:
http://www.ietf.org/mail-archive/web/namedroppers/current/msg04535.html

As we all know (and you can see from the 20+ responses), nothing can
be ever obvious in the IETF:-) But this discussion also seems to
support the idea of doing ACL check before prerequisite checks, and
there seem to be a bit more varied opinions about whether this is a
matter of protocol change (subject to rfc2136-bis) or it can be an
implementation choice, although my impression is that the former
opinion was more supported.

Revisiting these, my suggestion is:

- We do ACL check first (against the literal description of the RFC)
- With a clear comment about that and why we do this.
- Also describe it in the guide.
- Maybe also write a blog about it.
- Also maybe write a short internet draft proposing this "protocol
  change"

---
JINMEI, Tatuya