[bind10-dev] BIND 9 compatibility, was BIND 10 face to face meeting Y2-2 agenda

[Michael Graff]

Please don't discuss topics on this thread. Or better yet wait 2 days.  :)

--Michael (from an iPhone)


On Aug 27, 2010, at 15:38, Evan Hunt <each at isc.org> wrote:

>> We prefer separate tasks, like you describe, but need to see if it is
>> efficient to do that. This is the main point of Stephen's recent
>> research, which he will be presenting & discussing with us on Tuesday
>> morning. It looks like we may be able to have separate tasks.
> 
> I think Fujiwara-san's concern is about a single server sharing both
> recursive and authoritative functionality, listening on port 53 and
> handling both sorts of queries.
> 
> AIUI, relatively few DNS implementaitons allow you to do both of these
> things with a single server.  BIND and dnsmasq are the only ones I can
> think of offhand (but I'm probably forgetting something).  I'm also not
> sure how much demand there really is for it in the real world:  My home
> server handles both recursive and authoritative queries, but I don't think
> it's very common setup for serious production name servers.  But, it's
> something all previous versions of BIND have done, and we do want to be
> compatible.
> 
> We've had a bunch of conversations about how handle it (even in the
> informal discussions between Joao, Michael and myself, back before the
> BIND 10 project had properly gotten started).  It's going to be tricky to
> do it if we also stick with our vague plans to separate "auth" and
> "recurse" into separate processes.  Because doing that means the two of
> them will have to be sharing the socket somehow, and working out between
> themselves which process answers which queries.
> 
> Now, having a "receptionist" process that receives all the packets and
> distributes them to the right processes doesn't seem too hard,
> conceptually, if it's dividing them into broad categories (updates go
> to an update process, notifies to go xfrin, ixfr/axfr goes to xfrout...).
> But the receptionist can't be expected to know whether a query should
> go to auth or recurse; to do so it would have to know in advance whether
> we're authoritative for the name or not, and that's something even auth
> doesn't know at first.
> 
> So we decided the receptionist would have to send the queries to one or the
> other, and if it turns out to be the wrong choice, it can pass the query
> along to the other one.  One of the ideas that came up was that we could
> usually configure a server to *prefer* authoritative or recursive,
> depending on the kind of traffic that was expected.  A server might, for
> instance, be handling recursive traffic most of the time but get an
> occasional authoritative query; in that case we'd configure it so that
> "recurse" gets all the queries, but if one of them turns out to be for a
> name for which the server is authoritative, then the query gets handed off
> to "auth" instead.  A server whose traffic pattern was the reverse would
> have "auth" handle all the queries, but pass them off to "recurse" if
> it couldn't answer.
> 
> Having spent some time looking into the recursive algorithm in more detail,
> I no longer think we can take that flexible approach.  Recursion boils down
> to this:
> 
>  1) check authoritative data sources for an answer
>  2) if the answer isn't complete, check the cache for anything missing
>  3) if the answer still isn't complete, recurse for anything still
>     missing, and cache the response
> 
> Step one isn't optional.  If we're answering recursive queries on a server
> that's authoritative for anything, then *every* query is going to have to
> check the authoritative data sources first.  So I see two options:
> 
>  1) we separate b10-auth and b10-recurse as planned; all queries go to
>     b10-auth; failures or partial successes are handed off to b10-recurse
>     for additional work.  (Sometimes a query might ping-pong back and forth
>     between the two several times.)
>  2) we don't separate b10-auth and b10-recurse, but have a single process
>     that handles all queries.
> 
> I regret to say it, but I like option 2 better.  I thought separate
> processes would simplify the design, but I now think it does the reverse.
> 
>                                                eh
> 
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev