[bind10-dev] Thinking aloud: Receptionist

[Michal 'vorner' Vaner]

Hello

We didn't yet decide, if we want the receptionist or not (for those who don't
remember, a process for deciding, where a request would go). There are people
who think we will need recursive+auth binary, but some (like me) still find
receptionist nicely flexible.

There are many things the receptionist could be used for:
• Deciding between recursive/auth, of course.
• Getting rid of the problematic link between auth←→xfrout.
• Shielding the components of badly formated headers, long-living idle TCP
  connections, etc.
• Would be the only one with need of privileged port, so nothing else would need
  to talk to the socket creator.
• Adding new/custom components with just providing some filter rule or plugin
  (shared library), or, if there's no need for speed, by embedded python code.
• Load balancing between processes and even machines.
• Routing from multiple machines (if we have many machines with auth, but just
  one with xfrout, for example).
• Some pre-parsing could be done there and taken to a common place.


Now, the problem is performance, of course. But not just the overhead (I think
it was showed on the last F2F that it is quite small and we don't need to do
full parsing there), the problem is going back and forth between recursor and
auth, if there are both. Now, how many people who need the performance, need
both auth and recursive? And how many requests would go back and forth? Would it
matter that much?

Yes, I heard that when running recursive, you probably end up needing few
authoritative zones for the internal parts of your network. But would that be
solved by some kind of minimal auth support inside the recursor? Do we really
need all the performance, flexibility of multiple data sources, ability to
update it on-the-fly and so on?

Thanks

Have a nice day

-- 
You can fool some of the people all of the time,
and all of the people some of the time,
but you can make a fool of yourself anytime.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20101218/2c7913a8/attachment.bin>