[bind10-dev] Receptionist experiment

[Michal 'vorner' Vaner]

Hello

On Mon, Mar 04, 2013 at 11:25:33AM -0800, JINMEI Tatuya / 神明達哉 wrote:
> As a tool for generalization, I see the point, but at the same time 
> I'm not so sure about it.  A common user of auth would also use xfrout
> (and also incoming notify) normally, and they may not like the
> complexity and overhead of the additional layer.  Views are even
> trickier, especially if we want to fill the gap with BIND 9, because
> it would require more detailed inspection of incoming messages such as
> TSIG key name, and it doesn't look obvious to me that different views
> should be served by different processes.

I know most users of xfrout would use auth, it just seems wrong to require it.
And I'm ok with auth taking the place of receptionist in that usual scenario
(like it does now), either by doing the same thing as now, or by doing the same
thing as the future receptionist (so we could have some kind of library-ish
thing that we would put into auth and the xfrout would act the same each time).

With views, I'm not sure either, because I don't see the usecase myself at all.
I see the use case of views to have resolver for internal addresses and auth for
everything. I do see reason to show some zone to internal addresses only (but
that can be done with ACLs). Anyway, as I understand bind9 views, it more or
less means completely different configuration to be used for different queries
(by a match on some criteria). For that, splitting it into different process
with different configuration looks like the least violent way to add that to
current bind 10.

I do agree that for the views, we would need to inspect the messages more
thoroughly, even fully parsing the messages. But I believe we can do that
optionally, only when such kind of filtering is needed.

This is technical detail, but I even see a possible way to implement:
 • We get the ACL system and let administrator set ACL with targets being types
   of server to send it to. So, it would be something like:
   [
     {
       "type": "opcode",
       "value": "DDNS",
       "TARGET": "DDNS"
     },
     {
       "type": "flag",
       "flag": "rd",
       "value": true,
       "TARGET": "Resolver"
     },
     {
       "TARGET": "Auth"
     }
   ]
 • A server starts up, connects to the receptionist (or asks the receptionist to
   connect to it, it doesn't matter). And it claims what type of module it is,
   so the receptionist can send the right packets to it.
 • If there's no server for the given kind, or if a query falls off the end of
   the ACL, it responds with NOTIMP or SERVFAIL (I'm not sure which one is
   better).
 • There would be a white-list of lightweight checks (opcode, flag) that don't
   need the message to be parsed. If there was something not in the whitelist,
   receptionist would let the message be parsed before putting it to the ACL.

We would then add a way to start auth with some different configuration and it
would claim to be different kind of server.

> Maybe we are talking about different things.  Aren't you talking about
> the Linux specific double-m extension of sendmsg?  What I meant by the
> additional buffering is actually the overall communication overhead
> between auth and the receptionist (and the implicit internal buffering
> of TCP).

Ah, I see.

Actually, I was talking about the buffering I do manually before submitting the
messages to the auth.

In my understanding, TCP does some internal buffering only if it can't send
right away (the send queue of card is not empty or it sent too much data and
didn't get ACK yet) or you specified MSG_MORE. If it's TCP over unix domain
socket, it should be as fast as a pipe and the other side gets the data
immediately after they were written.

The immediately is the time needed to do a context switch, if there's an idle
core on the system. So these times should not be that large. I believe the times
of manual buffering I talked about are significantly larger.

Anyway, I believe the measurements showed the added RTTs are not very large.

With regards

-- 
This message is encrypted by double rot-13

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130305/3b18798a/attachment.bin>