[Pdns-users] truncated udp query and odd tcp behaviour (patch included)
Augie Schwer
augie.schwer at gmail.com
Fri Dec 29 00:59:02 UTC 2006
Is your patch based off of the 2.9.20 tree? I ask because it does not
apply cleanly to the tar ball I grabbed:
_[/root/augie/pdns-2.9.20]_(root at admin2.noc)_
# patch -p0 < ../tcpreceiver.cc.patch
patching file ./pdns/tcpreceiver.cc
Hunk #1 FAILED at 172.
Hunk #2 FAILED at 221.
Hunk #3 FAILED at 232.
3 out of 3 hunks FAILED -- saving rejects to file ./pdns/tcpreceiver.cc.rej
It might be better to grab the latest SVN release, modify and send the
output from svn diff to pdns-dev.
On 12/12/06, REIBENSCHUH Alfred <alfred.reibenschuh at it-austria.com> wrote:
>
>
>
> 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.
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users
>
>
>
--
Augie Schwer - Augie at Schwer.us - http://schwer.us
Key fingerprint = 9815 AE19 AFD1 1FE7 5DEE 2AC3 CB99 2784 27B0 C072
More information about the Pdns-users
mailing list