[bind10-dev] Forwarding from auth, was ddns
Michal 'vorner' Vaner
michal.vaner at nic.cz
Tue Nov 29 09:22:24 UTC 2011
Hello
On Mon, Nov 28, 2011 at 07:06:22PM -0800, JINMEI Tatuya / 神明達哉 wrote:
> At Mon, 28 Nov 2011 14:14:55 +0100,
> Shane Kerr <shane at isc.org> wrote:
>
> > It seems like what you're asking for is the receptionist.
>
> I'm not so sure about this. A receptionist would be the most
> obvious solution (if not the only one) for the resolver+auth problem,
> but (for example) "hardcoded" can be a problem for any solution. I
> also suspect even if we have a receptionist we may still want to use
> FD passing for xfrout. Generally the issues seem to be a bit broad
> and I guess we should clarify the problem/solution spaces a bit.
Well, the FD passing would still need to happen. But there could be one place
where it happens and each component/recipient could connect to the receptionist
and tell it (somehow) „I can handle this kind of requests“. It would allow
adding/removing the components at runtime, without complicated rebinding of
ports, etc. But I'm not sure how to balance the requests between same kind so it
is fair.
That provided only if we want the receptionist.
> Among the above problems I personally think the second one is crucial
> (including cases where the recipient hangs and the write operation on
> the UNIX domain socket would block) to be "production ready" and
> should be solved sooner anyway. Maybe we can handle this particular
> issue in a bit larger context that would cover some of the other
> topics (but right now I don't have any concrete idea).
Well, we should probably have it non-blocking and some finite queue. If the
queue is full, drop the requests, the other end and try again? Or would that be
prone to DOS attacks?
Thanks
With regards
--
Security warning: Do not expose this email to direct sunlight.
It may lead to undefined behaviour, including possible data or life loses.
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/20111129/e97ae0d7/attachment.bin>
More information about the bind10-dev
mailing list