[syslog-ng] logic and duplicate suppression

John Kristoff jtk at cymru.com
Fri Aug 20 01:17:17 CEST 2010


On Sun, 15 Aug 2010 07:55:58 +0200
Balazs Scheidler <bazsi at 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


More information about the syslog-ng mailing list