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

[Evan Hunt]

> 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