[bind10-dev] Thinking aloud: Receptionist

[Stephen Morris]

On 18 Dec 2010, at 10:57, Michal 'vorner' Vaner wrote:

> 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.

The only problem with putting functionality into the receptionist is that you end up having to run a receptionist even if you are just running a single component.  This adds overhead - even if it is small.


> • Would be the only one with need of privileged port, so nothing else would need
>  to talk to the socket creator.

Is this really a problem?


> • 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.

Is the idea that the receptionist filters the packet via a user filter and then passes it to the component in question?  If via a plugin, why not add the capability to accept plugins to the resolver and authoritative server?


> • Load balancing between processes and even machines.

Having multiple processes each take a query as they become ready would seem to be self-balancing (you covered that option in your previous email).  And multi-machine load-balancing is probably better done with specialist hardware. 


> • Routing from multiple machines (if we have many machines with auth, but just
>  one with xfrout, for example).

Again, if there are multiple machines, couldn't this be done with specialist hardware?



> • Some pre-parsing could be done there and taken to a common place.

See above for the drawback of putting functionality in the receptionist.


> 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?

My feeling is that if you are running both a resolver and authoritative server on your system it is unlikely that you will be running a really large zone.  So the following are also feasible:

a) Pre-load the resolver's cache with non-expiring authoritative records (and provide some way to update it should the authoritative data change). Providing that answers to queries for these records always contain the AA bit set, the presence of the resolver would be invisible.

b) Run the authoritative server on the same machine and configure the resolver to direct queries for the authoritative zones there (e.g. run it on a separate port or provide an inter-process communication mechanism). Essentially the resolver is acting as the receptionist.


Stephen