BIND 10 Team Call

Original minutes take on the Etherpad at


  • Shane
  • Mukund
  • Jelte
  • Aharen
  • Michal
  • Jinmei
  • Kambe
  • Jeff (briefly)
  • Paul

Daily Call Time (10 minutes)

Starting tomorrow at 15:00 UTC
Shane to update calendar with daily call

Sprint Progress (10 minutes)

New Scrum-master... Mukund (please be kind)

"Carsten Sprint"? (5 minutes)

Jinmei: Many issues related to bindctl, trigger question whether we want to do it, and also the next generation configuration stuff.
Jelte: Maybe we can do some collaboration getting requirements for next generation bindctl with Carsten.

Reporting Errors from system to users (15 minutes)
Jelte: Perhaps something like "these errors have occurred since you last checked", but this would also be added to a redesign of UI

Change from List to Names in Configuration (10 minutes)
Jinmei: 2 problems, the interface and whether the list the best representation of the specific parameters
Jinmei: first need to clarify the real issue

Jinmei: Unless we can completely get rid of lists, we may need to improve the list user interface; this may solve some of the issues

Shane: Could we separate the issues without having an example for him to work with? Okay, we can ask...

Jelte: we have places where we could use lists, we did not have named sets when we started; for example where we enumerate zones and stuff like that

Working without IPv6? (10 minutes)

  • Maybe build test-related code separately (could solve first one)
  • Off-line configuration interface

Off-line configuration has been on our "wish list" for a while. Non-trivial. :)

Other option is to introduce workaround type fix in our code.

Possible way forward: Allow skipping test-related code building. Just document the rest of the issue somewhere.

Generated Docs in Tarball / "make distclean" (10 minutes)
May need to forgo if Jeremy not present...

Shared Memory Architecture / Design (15 minutes)

Do we need discussion other than on the list?

Michal: Stuck on need to clarify how msgq works. Reliability of delivery.

Jinmei: Unless there are fundamental issues with original proposal, we are not stuck. :) Other points are relatively detailed.

Jinmei: Do we also want to do some of the msgq-related tasks so we can implement the design on an improved version of msgq? Or do it with the current version of it?
Michal: The proposal on wiki page is too complicated to be implemented reasonably.

Michal: No issue with data structure, only with synchronization with msgq. Probably everyone agreed. :)
Shane: I think improving the guarantees of the msgq is reasonable, if it makes sense.
Jinmei: I think it makes sense. (Ignore point about whether it is more efficient.) Main question is whether we can afford to do this.
Shane: This is the kind of change that should be able to fit in the time allocated for the shared memory work.

Jinmei: So you're okay even if this means deferring work like hooks?
Shane: Yes.

Resolver Architecture / Design (5 minutes)

Blocked on more tickets from Shane. :(
Michal asked for some experiments for how to differentiate between models.
Michal: we could implement mini-versions of each model, but that would take quite some time...
Maybe we could do 3 to 5 point tickets using a simulated model
Jinmei: Introduce a higher level abstraction that can work on any of the models?
Shane: okay... simulation may point out extremely bad performers... also may give some indication as to complexity

See the light at the end of the tunnel with resolver design! Start an outline of the overall approach?

Receptionist Model?

Jinmei: how to handle TCP in this model? when (if) to pass file descriptors to other processes? how we handle TSIG with the receptionist model?
Jinmei: basically have no problem with optional operation mode of auth + recursive, but would like to know details

Michal: don't forward open TCP connection - can send 1 query to resolver, 1 query to auth over same connection! query gets open on receptionist side, only query gets forwarded, receptionist sends back over TCP connection (forwarded query will have identifier)
Michal: I hope the server will do the parsing/verification of TSIG
Shane: can you send multiple messages for a single TSIG? (not 100% sure, but need to check)
Jelte: I don't see how you could send multiple messages with 1 TSIG...

Jinmei: forward file descriptor?
Michal: no
Shane: even in the case of zone transfers?
Michal: yes

Jinmei: so receiptionist needs to maintain some kind of state
Michal: needs to know about open connections
Jinmei: will need to be something smart. I do not necessarily object, but it seems to be different from keeping it light.

Jinmei: would like to see some more complete proposal of the design
Michal: if we have code that handles many file descriptors with timeouts, would that be enough (I've written this recently)
Jinmei: not just about file descriptors, but basically encoding the DNS queries and response and the exchanges over TCP and which state needs to be maintained and which we don't have to... I'd like to see a complete picture
Jinmei: Not very formal, but I'd like to see the conceptual data structure or something, and set of state that need to be maintained in the receptionist, and how we handle TCP, DDNS, NOTIFY, recursive queries, authoritative queries, zone transfers, ...
Michal: okay I think I can write something down

Recent user feedback

Related to managing zones.
Is it okay to keep ignoring user feedback?
For example, NOTIFY is incomplete, we cannot handle large number of zones reasonably (configuring this is mostly impossible due to the user interface)
Once someone tries to do that we will have other issues with XFRs

Shane: I think we're going to have to make a separate project for scaling up into lots of zones
Jinmei: okay for lots of zones, but more fundamental parts of system still has issues

Shane: bind10-users?
Jinmei: users or dev lists

Shane: certainly we can't ignore user questions

I think the right approach is to make tickets and implement this stuff.

Jinmei: prioritize before more advanced things?
Shane: I have call with the sponsors on Thursday, will discuss this with them then

Shane: will reply to Jeffery's e-mail about public roadmap, maybe it is a good idea to have some more formal way to interact with community? Way to get community weightings and things like that.

Mukund notes that we actually can configure notify. :)
Jinmei: it's not about whether we support NOTIFY in any way, but whether it is supported in a way that a user expects... we currently don't!

Mukund: also-notify is implemented... to close #1992 we need unit tests
Michal: we need to set notify, and have also-notify. Plus our implementation is kind of hackish.
Jinmei: still many missing features in this area

Shane's 2 questions to the team:

  1. What would you want us to work on based on your own preferences?
  2. What would you wnat us to work on based on your understanding of the users' needs?

Need to discuss from red/black to AVL?

Shane: Many more important tasks to do.

Last modified 5 years ago Last modified on Mar 13, 2013, 2:59:21 PM