[Pdns-users] Fwd: SPF records - Parsing Exceptions / STL Errors

Tom tom at t0mb.net
Fri Nov 25 07:56:01 UTC 2011

Thank you for your help in my previous mail (Peter Van Dijk, Nils
Breunese) (entitled: specifying more complex sql queries with gmysql

It looks like I don't need to do that any more.  Basically, I was having
problems with a massive qsize-q, and despite my hugely beefy sql servers
not breaking a sweat in terms of CPU/Memory/Disk IO, I was thinking that
InnoDB might be struggling after seeing the InnoDB status showing loads
and loads of unstarted transactions.  Anyway, it turns out that the
problem was actually down to us recently allowing customers to start
setting up SPF records.  We weren't validating them properly, and we
were seeing a lot of exceptions like the following:

Exception: Parsing record content: Data field in DNS should start with
quote (") at position 0 of 'v=spf1 include:_spf.google.com ~all'

and even more worryingly, like this:

TCP Connection Thread died because of STL error: Parsing record content:
Data field in DNS should start with quote (") at position 0 of 'v=spf1
a:randomdomain.com ~all'

Basically, after starting to validate these records, and retrospectively
fixing the records already in the database, my performance has returned
to normal.

We are running a custom version of, with a custom written MSSQL
back-end which we have as second in priority to the gmysql backend.
I've looked in to trying to use OpenDBX in order to upgrade to a later
version of PDNS (v3+) without having to rewrite portions of the custom
back-end, but I think it would be too much work to try and re-design our
database and control panel to work with the database format that OpenDBX
requires.  I don't think it's practical.  I think upgrading to 2.9.22
wouldn't be too much work, but I'm wondering whether the issues I've
raised above would have been fixed if we did that.  I know that there
are some bugs fixed which cause the TCP thread to recycle when there are
timeouts, but I don't know about these parsing exceptions.  We do suffer
with the TCP back-end recycling because of time-out errors, so it'd be
good to fix them anyway!

Any ideas if I should ask one of our developers to try and get our
patches to apply cleanly to 2.9.22?

If only they had contributed the patches to the project all those years

Thanks for your help so far!


nb. Re-sending this email again, as I was getting these maillog entries yesterday:

/Nov 24 14:33:24 mail postfix/smtp[28988]: B373F2EECC:
to=<pdns-users at mailman.powerdns.com>, relay=none, delay=3213,
delays=3191/0.03/21/0, dsn=4.4.1, status=deferred (connect to
mailman.powerdns.com[]: Connection timed out)/

...which meant the list wasn't receiving my mail.  In fact, I didn't
receive any mail from the list after 7AM GMT yesterday, so I think it
might have been down?

The mails I sent did go eventually though:

/Nov 24 15:39:43 mail postfix/smtp[30639]: E19652EEB9:
to=<pdns-users at mailman.powerdns.com>,
relay=mailman.powerdns.com[]:25, delay=21734,
delays=21733/0.02/0.23/0.08, dsn=2.0.0, status=sent (250 2.0.0 Ok:
queued as A1551740DA)/

/Nov 24 15:39:48 mail postfix/smtp[30638]: B373F2EECC:
to=<pdns-users at mailman.powerdns.com>,
relay=mailman.powerdns.com[]:25, delay=7197,
delays=7191/0.03/5.3/0.07, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued
as B949A740DA)/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20111125/6a8ac628/attachment.html>

More information about the Pdns-users mailing list