summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLaurent Bercot <ska-skaware@skarnet.org>2014-12-14 10:10:40 +0000
committerLaurent Bercot <ska-skaware@skarnet.org>2014-12-14 10:10:40 +0000
commit52545ad7f5752160277cc1645340e863fd8bb3a2 (patch)
tree566a9d50e78dde27a21748cd5f9a54267b2ae4dd
parentb3b6928811134680804c01b70dc67d170023625f (diff)
downloads6-dns-52545ad7f5752160277cc1645340e863fd8bb3a2.tar.xz
skadnsd doc update
-rw-r--r--doc/skadns/skadnsd.html13
1 files changed, 8 insertions, 5 deletions
diff --git a/doc/skadns/skadnsd.html b/doc/skadns/skadnsd.html
index e8316b8..16e1c38 100644
--- a/doc/skadns/skadnsd.html
+++ b/doc/skadns/skadnsd.html
@@ -18,9 +18,9 @@
<p>
<tt>skadnsd</tt> is the skadns daemon. It reads a series of
-queries from the client on stdin, resolves them asynchronously,
-and writes
-the answers to the client as soon as it gets them. It exits 0
+queries from the client its stdin socket, resolves them asynchronously,
+and sends
+the answers back to the client as soon as it gets them. It exits 0
when its stdin closes. It exits 111 on any serious error,
writing the error message to stderr.
</p>
@@ -80,7 +80,7 @@ that it requires support from the system administrator.
skadnsd has no "standalone" mode: it is designed to work with a Unix
domain superserver, like
<a href="http://skarnet.org/software/s6-networking/s6-ipcserver.html">s6-ipcserver</a>.
-skadnsd follows the <a href="http://cr.yp.to/proto/ucspi.txt">UCSPI"</a>
+skadnsd follows the <a href="http://cr.yp.to/proto/ucspi.txt">UCSPI</a>
interface, it can be directly executed from the superserver.
</p>
@@ -96,7 +96,10 @@ to run it under a specific account.
<ul>
<li> Users should never invoke <tt>skadnsd</tt> directly. It's an
-internal program designed to be spawned by the skadns library. </li>
+internal program designed to be spawned by the skadns library.
+It follows <a href="http://skarnet.org/software/skalibs/">skalibs</a>'
+"skaclient" protocol and is unusable unless spawned by the right client
+library also using that protocol. </li>
<li> If a poorly designed client sends a lot of queries and never reads the
answers, those will indefinitely queue up in the daemon, eating up
memory. You should run your process (or your Unix superserver, if you're