Augie Schwer wrote: > We have many machines that have both the PowerDNS authoritative server > and the PowerDNS recursor; we don't have this problem. What version of > the auth. and recursive server are you running? --Augie
I'm running: pdns-2.9.21.2.tar.gz pdns-recursor-3.1.6.tar.bz2 Are you sure you haven't set allow-recursion-override=yes? Now that I know what to search for there are many people who have a similar problem with the auth server passing queries to the recursor when it should answer them itself. ds > > On Thu, Feb 5, 2009 at 1:22 PM, David Sparks <d...@ca.sophos.com> wrote: >> David Sparks wrote: >>> Why does PowerDNS auth server not answer queries that it is both >>> authoritative >>> for, and has an answer for in its auth server when recursion is available >>> and >>> requested? >> I've found a Debian bug report that suggests this is a long standing problem >> with Powerdns: >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357432 >> >> Unfortunately that bug report is 3 years old and unanswered. >> >> Out of curiosity can someone fill me in on why Powerdns does a recursive >> resolve of a query and only falls back to its own auth server if the >> recursive >> query fails? This seems incredibly bizarre ... and has tripped up others in >> the past. There seems to be a design decision here that is solving a problem >> I don't know about (and the solution is causing me problems). >> >> Thanks! >> >> ds >> >> >> >>> Background: >>> >>> I have setup a PowerDNS installation to replace a BIND installation. We >>> have >>> run a split-horizon setup in BIND that has worked for many years. Since >>> PowerDNS does not support this I intend to continue to run BIND to answer >>> the >>> Internet queries, and PowerDNS will answer the internal for both auth and >>> recursive. >>> >>> PowerDNS auth server when queried for a record that it is both authoritative >>> for and exists will pass the query to the recursor if the recursion desired >>> flag is set (without doing any kind of lookup). What this means is queries >>> that could and should be answered by PowerDNS are passed onto the Internet >>> auth server. The answer from Internet auth server is from the wrong zone. >>> >>> This behavior can be worked around by setting "allow-recursion-override=yes" >>> but then delegated subdomains no longer work. Why does the auth server pass >>> queries to the recursor instead of doing a first attempt to answer them? >>> >>> >>> Below is the output of 4 queries: >>> >>> A plain query to PowerDNS is wrong. (2006 SOA comes from Internet auth >>> server) >>> A query to PowerDNS with +norec is right. (2007 SOA from PowerDNS) >>> PowerDNS with allow-recursion-override=yes is right. (2007 SOA from >>> PowerDNS) >>> BIND9 is right. (2007 SOA from BIND internal view) >>> >>> >>> ------------------------------------------ >>> allow-recursion-override=no - wrong answer >>> ~ # dig -t soa ahost.example.com @10.0.0.12 >>> >>> ; <<>> DiG 9.4.1-P1 <<>> -t soa ahost.example.com @10.0.0.12 >>> ; (1 server found) >>> ;; global options: printcmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3198 >>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 >>> >>> ;; QUESTION SECTION: >>> ;ahost.example.com. IN SOA >>> >>> ;; AUTHORITY SECTION: >>> example.com. 0 IN SOA ns1.example.com. >>> postmaster.example.com. 2006030201 3600 900 2419200 900 >>> >>> >>> ----------------------------------------------------------- >>> allow-recursion-override=no but +norec on dig: right answer >>> ~ # dig +norec -t soa ahost.example.com @10.0.0.12 >>> >>> ; <<>> DiG 9.4.1-P1 <<>> +norec -t soa ahost.example.com @10.0.0.12 >>> ; (1 server found) >>> ;; global options: printcmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64492 >>> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 >>> >>> ;; QUESTION SECTION: >>> ;ahost.example.com. IN SOA >>> >>> ;; AUTHORITY SECTION: >>> example.com. 60 IN SOA ns1.example.com. >>> hostmaster.example.com. 2007041200 60 60 60 60 >>> >>> ------------------------------------------- >>> allow-recursion-override=yes - right answer >>> ~ # dig -t soa ahost.example.com @10.0.0.11 >>> >>> ; <<>> DiG 9.4.1-P1 <<>> -t soa ahost.example.com @10.0.0.11 >>> ; (1 server found) >>> ;; global options: printcmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40863 >>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 >>> ;; WARNING: recursion requested but not available >>> >>> ;; QUESTION SECTION: >>> ;ahost.example.com. IN SOA >>> >>> ;; AUTHORITY SECTION: >>> example.com. 60 IN SOA ns1.example.com. >>> hostmaster.example.com. 2007041200 60 60 60 60 >>> >>> -------------------- >>> BIND9 - right answer >>> ~ # dig -t soa ahost.example.com @10.0.0.19 >>> >>> ; <<>> DiG 9.4.1-P1 <<>> -t soa ahost.example.com @10.0.0.19 >>> ; (1 server found) >>> ;; global options: printcmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63338 >>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 >>> >>> ;; QUESTION SECTION: >>> ;ahost.example.com. IN SOA >>> >>> ;; AUTHORITY SECTION: >>> example.com. 60 IN SOA ns1.example.com. >>> postmaster.example.com. 2007041200 60 60 60 60 >>> >>> >>> DNS server legend: >>> >>> allow-recursion-override=yes 10.0.0.11 >>> allow-recursion-override=no 10.0.0.12 >>> bind9 10.0.0.19 _______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users
