On Sun, 15 Aug 2010 07:55:58 +0200 Balazs Scheidler <bazsi@balabit.hu> wrote:
Now that I think of it, the DNS query portion is quite simple: it logs the contents of the DNS query and probably the same parameters would probably be present in all DNS server logs, thus I just have to decide the naming policy to be used on "transaction logs in general".
There are various types of logs a DNS server could generate depending on how granular you want your parser to be. The lame delegation logs for example are reasonably different than the query log and a zone transfer log message in turn would be different from each of those.
I guess "smtptxn" for SMTP transaction would be a good name, right? In that way your DNS transactions (= query logs) would need to be called "dnstxn", how does that sound to you?
Doesn't really matter to me. Some purists might not like referring to them as transactions, but I could care less. :-) If you want an alternative, I would suggest dnsquery.
Also, lame delegation is not a query, right? (I'd really need to
Correct, but the log message is only generated as a result of a query that probably didn't go so well.
refresh my memories about lame delegation, it's been a while since I last ran my own DNS server) If I understand the pattern/log message correctly, lame delegation would happen if my bind instance would try to resolve because recursion was requested, and the respond received from the upstream DNS server was bogus. Is this right?
Mostly right. Not bogus so much as the answer was either not marked authoritative (aa bit is not set) or you simply didn't get an answer at all from the nameserver you were following in a delegation chain, perhaps due to a DNS server configuration error, fault, packet filter, outage, etc.
One way to do that, I'd suggest to parse the whole field as text, put it in a database and filter on that at query time.
That's the current plan and is acceptable to me, thanks for looking it over. John