[Pdns-users] Malformed messages when not in cache

[Kevin O'Connor]

We have a record set up with the BIND backend as follows:

testing                 IN      CNAME   
gci-prod-lb-000000000.us-east-1.elb.amazonaws.com.

When you query it right after a service restart, you get:

[root at gibson ~]# dig @varick.datagram.com testing.domain.com
*;; Warning: Message parser reports malformed message packet.*
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> @varick.datagram.com 
testing.domain.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 264
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;testing.domain.com.         IN      A

;; ANSWER SECTION:
testing.domain.com.  300     IN      CNAME   
gci-prod-lb-000000000.us-east-1.elb.amazonaws.com.

;; Query time: 2 msec
;; SERVER: 209.131.118.33#53(209.131.118.33)
;; WHEN: Fri Mar  4 17:41:38 2011
;; MSG SIZE  rcvd: 99

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.

I've tested with the upcoming 3.0 release and the problem seems to be 
fixed (related to this <http://wiki.powerdns.com/trac/changeset/1830> 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.

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