You know the Spiel: you’re looking at a logfile containing BIND’s querylog output, and you think: what do those flags really mean? Here are two sample logfile entries, the first from a BIND version in 2011 (when I originally wrote this piece), and the second from a BIND version 9.11.2 server.

client 192.168.117.234#53311: view authoritative: query: example.org IN NS -EDC (192.168.36.217)
client @0x7fa0d607f200 192.168.1.130#63565 (example.org): view internal: query: query: example.org IN NS +E(0)K (192.168.1.130)

Note how the format of the log lines has changed. I pity you if you’re using regular expressions to handle these entries … :)

As usual, the best documentation is the source code. I extracted this snippet from bin/named/query.c for your pleasure. (This is from named 9.11.2.)

ns_client_log(client, NS_LOGCATEGORY_QUERIES, NS_LOGMODULE_QUERY,
              level, "query: %s %s %s %s%s%s%s%s%s%s (%s)", namebuf,
              classname, typename, WANTRECURSION(client) ? "+" : "-",
              (client->signer != NULL) ? "S" : "", ednsbuf,
              TCP(client) ? "T" : "",
              ((extflags & DNS_MESSAGEEXTFLAG_DO) != 0) ? "D" : "",
              ((flags & DNS_MESSAGEFLAG_CD) != 0) ? "C" : "",
              HAVECOOKIE(client) ? "V" : WANTCOOKIE(client) ? "K" : "",
              onbuf);

It starts off with a pointer address followed by the client’s IP and port and the name. The view used is shown here ("internal") followed by the string "query". Then come the name that was queried, the class (IN) and type (NS), and some flags which indicate whether recursion was requested (+) or not (-), if the request was signed (S), whether EDNS0 was enabled (E) with its flags, and whether the connection was over TCP (T) or UDP (the default which is not specified).

If DNSSEC was requested we see a (D), and if the CD (checking disabled) flag was in use a (C).

[Flags missing means they weren’t set.] And last, in parenthesis, the client’s destination address (i.e. the address of the name server).

DNS, BIND, and named :: 22 Feb 2011 :: e-mail

Comments

blog comments powered by Disqus