[bind10-dev] Thinking aloud: Receptionist

[Michal 'vorner' Vaner]

Hello

On Mon, Dec 20, 2010 at 11:20:05AM +0000, Stephen Morris wrote:
> > • 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?

Not really a problem. But it is uncomfortable. We either need to teach msq how
to send sockets or we need to create another connections between the boss and
the component. That is like fifth different protocol between components we have.

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

Well, you could do that. But then, the authoritative server plays the role of
the receptionist and it is not clean design, because it does something else than
what is its task.

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

Maybe, probably. And the customers who need that will probably have the
hardware. But I was just trying to point out it _could_ be done, point out the
flexibility, not that it would be a major need.

> > • Some pre-parsing could be done there and taken to a common place.
> 
> See above for the drawback of putting functionality in the receptionist.

Yes, sure. But then we end up having the functionality at multiple places, which
reduces maintainability (when first having n copies of the same code, we would
end up having n different but similar copies of the same code).

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

That would be the minimal auth support inside the recursor.

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

Yes, that might be a solution too. And I think this solution is better than
combined auth+recursive binary as well as the one with receptionist.

Thanks for reading the mail.

Have a nice day

-- 
This message is encrypted by double rot-13

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/20101220/2a16313c/attachment.bin>