<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
<div class="moz-text-html" lang="x-western"> We have a record set up
with the BIND backend as follows:<br>
<br>
<font face="Courier New, Courier, monospace">testing
IN CNAME
gci-prod-lb-000000000.us-east-1.elb.amazonaws.com.</font><br>
<br>
When you query it right after a service restart, you get:<br>
<br>
<font face="Courier New, Courier, monospace">[root@gibson ~]# dig
@varick.datagram.com testing.domain.com<br>
<b>;; Warning: Message parser reports malformed message packet.</b><br>
;; Truncated, retrying in TCP mode.<br>
<br>
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2
<<>> @varick.datagram.com testing.domain.com<br>
; (1 server found)<br>
;; global options: printcmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id:
264<br>
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL:
0<br>
<br>
;; QUESTION SECTION:<br>
;testing.domain.com. IN A<br>
<br>
;; ANSWER SECTION:<br>
testing.domain.com. 300 IN CNAME
gci-prod-lb-000000000.us-east-1.elb.amazonaws.com.<br>
<br>
;; Query time: 2 msec<br>
;; SERVER: 209.131.118.33#53(209.131.118.33)<br>
;; WHEN: Fri Mar 4 17:41:38 2011<br>
;; MSG SIZE rcvd: 99<br>
<br>
</font>Queries directly after this first query are OK, leading me
to believe that once it's in the cache it's able to serve properly
which seems strange. Previously we had been serving root
referrals with our answers, which had been padding long answers
like this to out over the 512 byte UDP limit. I thought that
might be the problem, so I turned root referrals off in hopes that
it would take care of this but no such luck.<br>
<br>
I've tested with the upcoming 3.0 release and the problem seems to
be fixed (related to <a
href="http://wiki.powerdns.com/trac/changeset/1830">this</a> I
think), but I need to try and work around this until 3.0 has been
officially released. I've turned our query-cache up to 60 in
hopes that I'm right about the record being served properly once
it's in the cache and that should reduce its occurrence. Are
there any other ways to work around this at the moment? And more
importantly, do I have the issue identified correctly? I don't
want to just be waiting for 3.0 hoping that will fix the problem
when really it's something silly I've missed.<br>
<br>
Thanks!<br>
</div>
</body>
</html>