<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body ><div>Since it's all myisam, you may be running into a concurrence problem where a select has a table locked for a split second and a new request comes in at the same time. Innodb gets you row level locking. It's probably nothing to worry about if it doesn't happen that often. If you turn on query logging in mysql, you could probably see what's going on.</div><div><br></div><div><br></div><div><div style="font-size:10px;color:#575757">Sent on a Sprint Samsung Galaxy S® III</div></div><br><br><div>-------- Original message --------</div><div>From: Willem de Groot <willem@byte.nl> </div><div>Date:06/30/2014 11:15 AM (GMT-05:00) </div><div>To: pdns-users@mailman.powerdns.com </div><div>Subject: [Pdns-users] Debugging bogus NXDOMAIN replies </div><div><br></div><div dir="ltr"><div>Hi pdns people! The following issue has kept me busy for many days to no avail. Suggestions are much appreciated.</div><div><br></div><div>My pdns auth server answers 2M queries per day. At random times, but about once or twice per day, an unexpected NXDOMAIN reply is sent out. The auth log (loglevel 9) dutifully but sparingly reports:</div>
<div> </div><div><div>Jun 30 14:31:49 dns2.c1.internal pdns[2100]: Authoritative NXDOMAIN to 10.1.2.222 for 'database25.c1.internal' (A)</div></div><div><br></div><div>This record certainly exists in the gmysql backend, as is demonstrated by the thousands of successful lookups [1]. How would I debug this issue? Is there perhaps a way to crank up logging for the gmysql module (queries and replies)? I couldn't find any references to this record in the mysql-slow.log, while other queries >1sec are logged there.</div>
<div><br></div><div>NB, there some suspects:</div><div><br></div><div>* pdns auth version is 2.9.22-8+squeeze1 (standard Debian)</div><div>* mysql db schema is still myisam, with 1M+ rows in the "records" table (very infrequent updates though)</div>
<div><br></div><div>Because updating is quite a hassle, I'd like to do that as a last resort. Plus, I can't stand not knowing where the failure is coming from ;)</div><div><br></div><div>TIA!</div><div>Willem</div>
<div><br></div><div>[1] As witnessed by tcpdump:</div><div><br></div><div>A good reply:</div><div><div> 10.1.2.222.53 > 10.1.2.222.9617: 62526*- q: A? dbint029896.c1.internal. 2/0/0 dbint029896.c1.internal. CNAME database25.c1.internal., database25.c1.internal. A 10.1.2.126 (82)</div>
</div><div><br></div><div>A bad reply (cname yes, a record no)</div><div><div> 10.1.2.222.53 > 10.1.2.222.12384: 28255 NXDomain*- q: A? dbint029896.c1.internal. 1/1/0 dbint029896.c1.internal. CNAME database25.c1.internal. ns: internal. SOA <a href="http://nsa.company.nl">nsa.company.nl</a>. <a href="http://hostmaster.company.nl">hostmaster.company.nl</a>. 2009121500 10800 3600 604800 3600 (124)</div>
</div><div><br></div><div><br></div></div>
</body>