DNS Query Logging

Software SW help
1

I was hoping to try doing some query logging with kresd. Looking at the documents:

policy.REQTRACE

Pretty-print DNS requests from clients into the verbose log. It’s useful for debugging weird DNS clients. Verbose logging must be enabled using verbose() for this policy to be effective. It makes most sense together with Views and ACLs.

So, I tried adding it to my custom.conf file and restarting.

policy.add(policy.suffix(policy.REQTRACE))

but ended up with a lot of

kresd[10492]: [system] error while loading config: /usr/lib/kres_modules/policy.lua:346: bad argument #1 to 'create' (table expected, got nil) (workdir '/tmp/kresd')

lines, so I’m not doing something right.

Has anyone tried doing this?

I can just turn on verbose logging and probably get what I need, but I was hoping not to have to wade through a lot of extra stuff and get a more concise output.

2

policy.suffix takes two parameters.

3

Once upon a time (about a year ago), I’ve used resolver-debug to log what kresd is doing:

https://wiki.turris.cz/doc/en/howto/dnsdebug

4

Note that even your previous quote from docs says that what you tried also needs verbose logging.

5

Perhaps you rather want something like command

tcpdump 'port 53'

(inside Turris ssh), and watch or save the output? Or you could use it to really save the traffic.

6

Yes. But I was assuming that I could put the option in and turn verbose logging on and off and have the option just work when it’s on. Perhaps I can turn this on in a similar way.

I’ve got a simple script that can turn on debugging with:

echo 'verbose(true)' | socat - /tmp/kresd/control/"$(pgrep kresd)"

and off by echoing false.

If I can similarly switch REQTRACE, that would be nice too.

But as with many things related to knot resolver, I am fairly clueless.

7

So, then it should be something like:

policy.add(policy.suffix( policy.REQTRACE, policy.todnames({'.'})))

I often find the knot resolver documentation to be pretty spare, so I end up guessing a lot.

8

Spare? I’d rather think it’s too long and detailed for most use cases, as you have multiple screen-fuls about policies: https://knot-resolver.readthedocs.io/en/v5.3.2/modules-policy.html

Apparently you want to trace all, so it’s easier:

policy.add(policy.all(policy.REQTRACE))

I see that even without verbose logs it gives you this for every client request:

[41438.00][dbg ] request packet:
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 41438
;; Flags: rd  QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 4096 B; ext-rcode: Unused

;; QUESTION SECTION
turris.cz.              A

;; ADDITIONAL SECTION
9

Using the socket is possible, but it might be practical to just restart the daemon. Cache is kept by default on restarts, so it should be pretty cheap.

10

Thank you very much.

Perhaps you’re right, that it’s not too spare. I’ve found it difficult to parse what I need out of it though.

11

If you have some more concrete suggestions about what needs improving in the docs, that would be appreciated. (generally, not just in this case)

12

So this line from documentation is wrong – at least in the current version of Knot Resolver I see these as two kinds of information logged and configured independently of each other. I’ll be looking into fixing it, most likely just by changing the docs.

13

I will give that some thought.

I have actually found myself moving away from tech in general, so it may entirely be my issue. I’ve lost a lot of patience for wading through technical documents in the past few years, especially for things I do infrequently.

I’m well versed with BIND, so I’m probably too impatient learning a different DNS system.

14

Sounds fine to me. I think policies are quite often configured even by people who are neither DNS nor tech experts.