[Pdns-users] truncated udp query and odd tcp behaviour (patch included)

REIBENSCHUH Alfred alfred.reibenschuh at it-austria.com
Tue Dec 12 19:29:43 UTC 2006


hi!

after implementing the ldap backend, doing some testing and 
pulling my hair out because of pdns tcp query behavior i have 
created a patch that solves those issues.


setup:

	pdns_server-2.9.20 running on *:53
		configured to use ldap (strict)
		configured to use recurser

	pdns_recurser-3.1.4 running on 127.0.0.1:5353

	openldap with dnsdomain2 schema

symtom 1)

	"host [ip address]" works and returns [name]
	"dig -x [ip address]" works and returns [name]

symtom 2)

	"host [name]" returns:
		Host [name] not found: 3(NXDOMAIN)
	"dig [name]" returns:	
		; <<>> DiG 9.2.4 <<>> [name]
		; (1 server found)
		;; global options:  printcmd
		;; Got answer:
		;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5070
		;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 0
	
		;; QUESTION SECTION:
		;[name].                    IN      A

		;; AUTHORITY SECTION:
		.                       1995    IN      SOA     [my upstream
server soa record]

change 1)
	i have enabled the following:
		allow-recursion-override=on
		allow-recursion=yes
		lazy-recursion=yes

symtom 3)

	"host [name]" returns:
		;; Warning: Message parser reports malformed message packet.
		;; Truncated, retrying in TCP mode.
		Host [name] not found: 3(NXDOMAIN)
	"dig [name]" returns:	
		;; Warning: Message parser reports malformed message packet.
		;; Truncated, retrying in TCP mode.
		; <<>> DiG 9.2.4 <<>> [name]
		; (1 server found)
		;; global options:  printcmd
		;; Got answer:
		;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5070
		;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 0
	
		;; QUESTION SECTION:
		;[name].                    IN      A

		;; AUTHORITY SECTION:
		.                       1995    IN      SOA     [my upstream
server soa record]

	tcpdump on the client reports truncated dns-udp packets with many A
records 
		(ok the host in question has ~200 of them)
		and a failed dns-tcp query

	tcpdump on the server yields that the udp query results in a ldap
query
		the tcp query results in a dns query to the recurser

fact)
	all of my unix boxen (linux, solaris, aix) set the 
	recursion bit in their libc implementation.


looking at the code of "tcpreceiver.cc" the processing sequence of the query
seams odd
and the config-statements i thought should influence the behaviour are not
even checked.

so this is the patch:

****************************************************************************
************
--- ./pdns/tcpreceiver.cc.old   2006-12-12 18:01:09.000000000 +0100
+++ ./pdns/tcpreceiver.cc       2006-12-12 18:22:38.000000000 +0100
@@ -172,8 +172,41 @@
        continue;
       }

+      /* first we look into the cache */
+      DNSPacket* cached=new DNSPacket;
+      if((!packet->d.rd || arg().mustDo("allow-recursion-override")) &&
(PC.get(packet, cached)))
+      { // short circuit - does the PacketCache recognize this question?
+        cached->setRemote((struct sockaddr *)(packet->remote),
sizeof(struct sockaddr_in));
+        cached->spoofID(packet->d.id);
+       delete packet;
+        if(sendDelPacket(cached, fd)<0)
+          goto out;
+
+        S.inc("tcp-answers");
+        continue;
+      }
+      else
+        delete cached;
+
+      /* now we look into the backends */
+      DNSPacket *reply;
+      if(!packet->d.rd || arg().mustDo("allow-recursion-override"))
+      {
+        Lock l(&s_plock);
+        reply=s_P->question(packet); // we really need to ask the backend
:-)
+        if(reply)  // able to write an answer?
+        {
+          delete packet;
+          if(sendDelPacket(reply, fd)<0)
+            goto out;
+
+          S.inc("tcp-answers");
+          continue;
+       }
+      }

-      if(packet->d.rd && arg().mustDo("recursor")) {
+      /* now we recurse upstream */
+      if(arg().mustDo("recursor")) {
        // now what
        // this is a pretty rare event all in all, so we can afford to be
slow

@@ -188,6 +221,7 @@

        char
*buffer=res.sendReceive(st.host,st.port,packet->getRaw(),packet->len,&len);
         DLOG(L<<"got an answer from recursor: "<<len<<" bytes,
"<<(int)buffer<<endl);
+       delete packet;
        if(buffer) {
          sendData(buffer,len,fd);
          DLOG(L<<"sent out to customer: "<<len<<" bytes"<<endl);
@@ -198,32 +232,7 @@
        continue;
       }

-      DNSPacket* cached=new DNSPacket;
-      if(!packet->d.rd && (PC.get(packet, cached))) { // short circuit -
does the PacketCache recognize this question?
-       cached->setRemote((struct sockaddr *)(packet->remote), sizeof(struct
sockaddr_in));
-       cached->spoofID(packet->d.id);
-       if(sendDelPacket(cached, fd)<0)
-         goto out;
-
-       S.inc("tcp-answers");
-       continue;
-      }
-      else
-       delete cached;
-
-      DNSPacket *reply;
-      {
-       Lock l(&s_plock);
-       reply=s_P->question(packet); // we really need to ask the backend
:-)
-      }
-
       delete packet;
-
-      if(!reply)  // unable to write an answer?
-       break;
-
-      S.inc("tcp-answers");
-      sendDelPacket(reply, fd);
     }

   out:;
****************************************************************************
************


i also added some "delete packet;" to avoid leaks.


cheers,
--
Alfred Reibenschuh
INFORMATIONS-TECHNOLOGIE AUSTRIA GMBH
Netzwerk-Management
A-1020 Wien, Lassallestrasse 5
T: ++43-1-21717-58947
F: ++43-1-21717-58979
E: alfred.reibenschuh at it-austria.com
W: http://www.it-austria.com
--
Diese Nachricht und allfällige angehängte Dokumente sind vertraulich und nur
für den/die Adressaten bestimmt. Sollten Sie nicht der beabsichtigte
Adressat sein, ist jede Offenlegung, Weiterleitung oder sonstige Verwendung
dieser Information nicht gestattet. In diesem Fall bitten wir, den Absender
zu verständigen und die Information zu vernichten. Für Übermittlungsfehler
oder sonstige Irrtümer bei Übermittlung besteht keine Haftung. 
This message and any attached files are confidential and intended solely for
the addressee(s). Any publication, transmission or other use of the
information by a person or entity other than the intended addressee is
prohibited. If you receive this in error please contact the sender and
delete the material. The sender does not accept liability for any errors or
omissions as a result of the transmission. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20061212/ba53fa25/attachment.html>


More information about the Pdns-users mailing list