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]_([EMAIL PROTECTED])_
# 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
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
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-users
--
Augie Schwer - [EMAIL PROTECTED] - http://schwer.us
Key fingerprint = 9815 AE19 AFD1 1FE7 5DEE 2AC3 CB99 2784 27B0 C072
_______________________________________________
Pdns-users mailing list
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-users
