[Pdns-users] Why prefer recursor answers over auth Authoritative answers?

[David Sparks]

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 <dave at 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