recursive resolver.
We need a way to run both an authoritative and a recursive resolver on
-a single platform, listening on the same IP/port. But we need a way to
+the same machine and listening on the same IP/port. But we need a way to
run only one of them as well.
This is mostly the same problem as we have with DDNS packets and xfr-out
* Stand-alone resolver
* Compound module containing both
-The user then chooses either one stand alone module, or the compound one,
+The user then chooses either one stand-alone module, or the compound one,
depending on the requirements.
Advantages
* The code is not separated (one bugs takes down both, admin can't see which
one takes how much CPU).
- * Bind 9 does this and bind 9 code is a jungle. Maybe it's not just a
+ * BIND 9 does this and its code is a jungle. Maybe it's not just a
coincidence.
* Limits flexibility -- for example, we can't then decide to make the resolver
threaded (or we would have to make sure the auth processing doesn't break
Disadvantages
~~~~~~~~~~~~~
- * Counter-intuitive asymetric design
+ * Counter-intuitive asymmetric design
* Possible slowdown on the resolver side
* Resolver needs to know both modes (for running stand-alone too)
Advantages
~~~~~~~~~~
- * Probably a good performance
+ * Probably good performance
Disadvantages
~~~~~~~~~~~~~
* The queries are sent from the receptionist in batches, the answers are sent
back to the receptionist in batches too.
* It is possible to fine-tune and use OS-specific tricks (like epoll or
- sending multiple UDP messages by single call to sendmmsg).
+ sending multiple UDP messages by single call to sendmmsg()).
Proposal
--------